スイフト 関数型プログラミング

投稿者：Igor Litvinenko、シニアモバイル開発者。



この記事では、関数型プログラミングについて説明します。 より正確には、命令型およびオブジェクト指向プログラミングの問題を検討し、次に関数型プログラミングを検討し、その中のこれらの問題の解決策を見つけようとします。 また、関数型プログラミングを使用する場合と使用しない場合も確認します。

歴史ツアー

少し歴史。 たまたま、すべての開発方法論が学術的な情報源からもたらされました。 その後、この手法が普及するまでに約2〜数十年かかりました。 これは、私たち開発者がビジョンを変え、問題を解決する方法を変えるための時間が必要だからです。



「We Think Functionally」（または「Functional Thinking」）という本の例が本当に気に入りました。 あなたが木こりであり、森で最大のaを持っていると想像してください。これにより、あなたは最高で最も成功した木こりになることができます。 しかし、あなたは雑誌で、チェーンソーを使用して、伐採の新しい非常に効果的で現代的なコンセプトを考え出したというマーケティング担当者のメモを読みました。 その後、チェーンソーを自分で注文します。チェーンソーはあなたに配達し、開梱しますが、どのようにオンになるかわかりません。 しかし、あなたはwoodで木材を切る方法を非常によく知っています。 そして、あなたはチェーンソーを取り、通常withで切るのと同じように木でそれを切り刻もうとします。 そして、もちろん、あなたは成功しません-あなたは再びaに戻る以外に選択肢がありません。 しかし、その後、隣人があなたのところに来て、チェーンソーを始める方法を説明します-そして、最終的にあなたはチェーンソーで森林を効果的に切り始めます。



これは、関連する資料（たとえば、マニュアル、ベストプラクティス）で大きくなりすぎて、新しい方法論を使用して完全に解決できるタスクの層が明確に区別されるまで、アイデア、概念、または方法論が私たちから外れることはないと言います。



歴史を見ると、手続き型プログラミングがそのタスクの素晴らしい仕事をしたことがわかります-それは非常に高速でした。 そして、1967年に彼らが最初のオブジェクト指向言語（Simula 67）を思いついたとき、誰もこの言語が必要な理由を理解していませんでした-誰もがメソッドの正しい実装を見つける必要があるという事実に関連するパフォーマンスの損失にのみ注意を払いました、またはしかし、プログラムはより大きなタスク層を実行し始めました。より複雑になり、開発チームが大きくなり、オブジェクト指向のアプローチが正確に欠けていたことが判明しました。 その結果、1983年に導入されたC ++の導入により、ソフトウェア開発への命令型オブジェクト指向アプローチが一般的になりました。

同じ話は、Javaや.NETなどのクロスプラットフォーム言語にも当てはまります。 コンセプトは1980年に始まりました。この環境では、Apple 2とIBM PCの2台のマシンでPascalコードを実行できました。 しかし、その場合、バイトコードへの転送とその後のマシンコードへの変換のための容量はまったくありませんでした。 また、90年代に、SunはJavaを導入しました。 現在、クロスプラットフォームJavaおよび.NET言語の専門家は、さまざまな機械語の専門家よりもはるかに需要があります。 結局、すでに90年代には、より高価で強力なハードウェアをサーバーに配置し、必要なすべてのコードを実稼働中に実行すると同時に開発を節約する方が良いことが明らかになりました。 非常に優れたオブジェクト指向モデルとガベージコレクターを備えたJavaを検討した後、ほとんどの人はもちろん、手動のメモリ管理に移行することを望まなくなりました。

命令型（およびオブジェクト指向）アプローチの問題

ただし、命令型のオブジェクト指向アプローチには欠点があります。

• エントリーのしきい値 。 まず、用語を理解する必要があります。たとえば、継承とは何か、どのように使用するか、さらに重要なことには、それを使用せずに通常の構成を使用することを知る必要があります。 第二に、プロジェクトに入るための閾値があります。 たとえば、アクティブな開発の段階でプロジェクトにアクセスする場合、オブジェクトとその相互作用に対処する必要があります。
• 抽象化への非自明な内訳 。 物理オブジェクトをプログラミングオブジェクトに直接転送することは必ずしも意味がありません。これらのオブジェクトを何らかの方法で粉砕し、追加オブジェクトを導入し、さまざまなレベルの抽象化を作成する必要があります。 同時に、どの本からでもそれを正しく行うことを学ぶことはできません-とにかく経験がついてくるでしょう。 本から学ぶことができるのはデザインパターンだけですが、別の問題があります。
• 誤解パターン-アンチパターン 。 デザインパターンは、コードの一部を移動することを目的としており、可能な限り深く、つまり特定の実装まで可能な限り低く変更できますが、一般的なロジックは変更されません。 これはもちろん非常に便利ですが、人々は怠け者であり、自分が何をしているのかを常に理解しているわけではありません。 このため、デザインのアンチパターンが登場しました。 たとえば、すべての人のすべてを「認識」し、柔軟性のほとんどを奪う「神のオブジェクト」が登場しました。 ポルターガイストクラスも登場しました。このクラスが何をするのかはわかりますが、なぜここにあるのか理解できません。 したがって、命令型プログラミングでは、クラスが引き起こす可能性のあるこうした種類の副作用がたくさんあります。
• インターフェイスの副作用は明らかではありません 。

もちろん、リファクタリングを行うことができる経験豊富な人を引き付けることによって、いくつかの問題を解決できます。 しかし、マルチスレッドについて話すとき、命令型プログラミングの概念は機能しなくなります。 結局のところ、さまざまなフロー内のオブジェクトの状態の変化を監視し、それらを同期させるために、アトミックな操作を行うことは非常に困難です。 ボックスからプログラムを取り出して、複数のプロセッサに並列化することはできません。 さらに、プログラム内の比類のないコードが30％を超える場合、マルチプロセッサシステムから利点を得ることができません。同期とアトミックアクションに時間がかかりすぎます。 したがって、次の欠点があります。

• 状態変更の概念そのものが機能しなくなります。

コンセプトが機能しない場合、人々は他の人を探し始めます。 そして、いずれにせよ、関数型プログラミングがお気に入りの言語に忍び込み始めたことがわかります。 Objective-Cでブロックを取得し、Swiftでクロージャーを作成し、11番目の標準からC ++でラムダ関数をサポートし、Javaでもラムダ式を取得し始めました。 ClojureやScalaなどの言語が聞こえるようになりました。 したがって、関数型プログラミングとは何かを理解しましょう。

関数型プログラミング（FP）とその基本原則

関数型プログラミングが関数を使ったプログラミングであると考えているなら、あなたは正しいです。 この場合、より数学的なスタイルで記述します。 常に入力データと出力データがあり、それらからパイプを作成するかのように関数を記述します。



FPの主な柱：



FPの主な柱：

●変更されていない入力。

•副作用はありません。

•マルチスレッド。

●高階関数による抽象化レベルの変更

•より再利用可能なコード。

•コードの読みやすさの向上。

•コンテキストの保存。



入力の一貫性は、すべての副作用のカットオフを提供します。 つまり、マルチスレッドシステムについて心配する必要はもうありません。変更も同期も不要です。



高階関数を使用します。 これは、他の関数をパラメーターとして取る関数を作成できることを意味します。これにより、より一般的なロジックを記述するときに次の抽象化レベルに進むことができ、特定のアクションを特定の方法で実装する方法がパラメーターとして関数に渡されます。

変更されていない入力

次に、入力データの不変性について詳しく説明します。 あなたがプロジェクトに来て、同僚にそれを理解するのを手伝ってくれるよう頼むとき、あなたは常に図を描く必要があります：オブジェクト、メソッド、メッセージ、どの状態に入るべきかなど。 そして、関数を見るとき、次のものが必要です。

1. この関数が何をするかを理解してください。
2. 指定されたオブジェクトの内部または外部、またはタイマー、通知、または他の何かによって呼び出される方法を理解します。
3. オブジェクトのインターフェースを見ています。 このインターフェイスによって他にいくつのオブジェクトが傷つけられますか？

もちろん、この質問に答えることはできません。 特定のメソッドを呼び出した場合、グローバルな意味で何が起こるかさえ言えません。 これが主な問題です。



次に例を示します。







クラス「User」があり、この「User」を格納する「ViewController」があり、クラス「NetworkOperation」、つまり大まかに言ってリクエストがあるとします。 「ユーザー」タイプは参照タイプです。つまり、参照によって渡されるため、「ViewController」で何かを変更し、「NetworkOperation」で何かを変更してから、彼らが言うように、楽しいデバッグを行います。



それをどうしますか？ Swiftには、参照型と値型の2つのデータ型があります。 参照データ型は生きているものであり、何らかの形で反応し、その状態を変更できるものです。 重要なタイプは、死んでいて応答しないシンプルなデータです。 コンセプト自体は、アクティブなオブジェクトの使用、つまり参照型からの使用を放棄し、値のみの使用に進む必要があると述べています。 したがって、すでに言語レベルでは、副作用を取り除くことができます。内部でそれ自体を変更せず、追加のリンクを作成しない単純なデータのみがあります。 そして、それはすでにはるかに簡単です。



要素「1」、「2」、「3」を含む配列「a」があるとします。 配列「b」は「a」への参照です。







そして、配列「b」に何らかの要素を追加するとします。 次に、「b」がオブジェクトである場合、それは変更されます。 ここで、「a」は変更されないままです。つまり、値レベルで副作用はありません。







参照タイプとして機能する「View」で作業する場合、変数「beta」の「alpha」を変更するときに、変数「a」の「alpha」を変更します。







もちろん、意味のある型は、実際には少しカットされていると思うかもしれません-これは単純なデータであり、何もできないようです。 しかし、実際にはそうではありません。Swiftでは、列挙型（enum）と構造体（struct）は重要な型です。 そして、構造体はプロトコルを実装し、メソッドを保存し、いくつかの計算を行うことができます。実際、オブジェクトを使用して徐々に同じレベルに移行し始めています。 ただし、次の3つの主な利点があります。

1. まず、構造は常に一定であり、時間とともに変化することはありません。
2. 第二に、分離：意味のある型は常に分離されます。 たとえば、参照タイプ「ユーザー」を使用する場合、内部のコンポーネント間に依存関係を作成します。 構造、つまり重要な型を使用する場合、依存関係はなく、すべてのデータが分離されます。 ここでは、簡単に、重要なタイプについて説明します。
3. 第三に、それは互換性です。 オブジェクトの場合のように、「インスタンス構造」という概念はありません。つまり、IDがありません。 概して、重要なタイプは内部にあるデータによってのみ特徴付けられます-これは、それらが交換可能であることを意味します。 たとえば、a = [1、2、3]と言うとき、物理的にはこのオブジェクトがメモリ内にあるかどうかは関係ありません。 つまり、「a」に目を向けると、このデータを持つ配列が存在します。 彼らがどこから来たのかは別の質問です。

高階関数による抽象化レベルの変更

高階関数による抽象化のレベルを変更するということは、関数内の関数を引数として実行できることを意味します。 これはまた、Swiftでは関数がクラス1変数になったことを示唆しています-それらを通常の変数と同じように扱うことができます（キャッシュ、関数内で受け入れ、別の関数の結果として返す）。 Swift言語レベルでは、FPの「 map 」、「 filter 」、「 reduce 」などの基本機能を既に実装しています。 これらの機能の使用例：







Mapは、あるタイプのオブジェクトのコレクションを別のタイプのオブジェクトのコレクションに単純に抽出します。 人生からの例。 私の以前のプロジェクトでは、システム全体のモデルは重要なタイプで記述されていました。 ただし、一部の値はデータベースに保存する必要がありました。 データベースに保存すると、クラス「NSManagedObject」を使用してオブジェクトレベルで操作できます（これは参照データ型です）。 そして、ここで「マップ」関数は非常に役立ちました。たとえば、データベースに対して何らかのクエリを行うと、これらのオブジェクトが返されます。返されたコレクションは返されませんが、「マップ」（「translate重要な型に変換」）、重要な型のデータが返されます。



コードをさらに読みやすく、美しくするために、Swiftには簡略表記法が用意されており、変数に非常に迅速にアクセスできます。 「$ 0」、「$ 1」、「$ 2」と書くと、クロージャーの内部に入ったパラメーター番号を参照します。



そしてもう一つ追加。 クロージャーが何らかの値を返す場合、「return」と入力しなかった場合、最後の行の結果が操作の結果として返されます。 このため、この場合、マップ関数は単にこれらの数値の二乗を返します。



次の機能は「 フィルター 」です。 ここで、boolが返す必要のあるクロージャを渡すだけで、結果の選択にこの式またはその式を含めるかどうかを決定できます。



reduce関数は、コレクションを単一の値に圧縮します。 たとえば、上記では、ロミオとジュリエットの最初の行為で章の数を数える方法の例を示しています。



関数は何も変更せず、グローバル効果を持たないため、すでにこの段階でアプリケーションをコンパイルすると、「map」、「filter」、「reduce」などの関数がすべてのプロセッサで自動的に動作します。 つまり、外部に何も変更せず、個々の要素をどう処理するかを正確に知っています。これをすべてのプロセッサに分散し、結果を返しました。 すべてがうまく機能します！

オプションのデータ型とSwift sugar

ここで、Swiftに存在するが、関数型言語には必要ない他の機能を見てみましょう。

• ジェネリックは常にクールです。 より抽象的なコードを記述します。
• 静的型付けにより、記述されたコードを理解しやすくなり、テストが簡単になります。
• 演算子のオーバーロードにより、明確で直感的なコードを記述できます。
• オプションのタイプにより、SDK自体が提供するAPIが大幅に変更されました。 Objective-Cに「indexOfObject」があると仮定します-常に値を返しますが、結果の値を定数「NSNotFound」と比較する必要があり、等しくない場合、「（NSUInteger）indexOfObject :( ObjectType）anObject」。 Swiftではすべてが非常に簡単です。オプションの要素の「インデックス」が返されます。この要素がコレクション内にある場合は「インデックス」が返され、そうでない場合は「インデックス」は返されません： public func indexOf(element: Self.Generator.Element) -> Self.Index?





public func indexOf(element: Self.Generator.Element) -> Self.Index?


  
  
  
  

例がわかる

それでは、理論から実践に移りましょう。

例1.ローカルファイルの検証

まず、問題の必須の解決策を検討し、次に機能に移ります。



URLをローカルファイルに渡し、ファイルが廃止されているかどうかを判断する関数があるとします。







命令型のオブジェクト指向のアプローチを使用すると、ソリューションは次のようになります。ファイルへのリンクを取得し、ファイルが存在するかどうかを確認します。 次に、それが存在する場合、彼らはそこから属性を取得します。 属性が存在する場合、属性から日付を抽出し、ファイルが古いかどうかを確認しようとします。 つまり、明確な一連のアクションがあるため、答えを得ることができます。 オプションのタイプをデプロイできなかった場合、もちろん「false」が返されます。



FPは、小さな機能に分割することから始めます。







最初の関数は、単にファイルが存在するかどうかを判断します。文字列を受け入れ、オプションで文字列を返します（1つの操作を実行します-ファイルが存在する場合は返します）。 次は、属性を取得することです。ここでは、既存の正確なファイルへの入力行を取得し、取得できた可能性のある属性を返します。 次の関数は、以前に受け取った属性から日付を取得します-ここでは、略語（「$ 0」）を使用します。 パス全体、つまり関数で構成されるパイプは次のようになります。パスを取得し、ファイルの存在を確認し、属性を取得し、作成日を確認します。



ソリューションをさらに美しくするために、2つの関数を接続する関数「バインド」を定義し、この関数を単に参照する演算子を定義します。 バインド関数は、オプションの値とオプションの関数（つまり、この値で実行する必要があるもの）を受け入れ、オプションの値も返します。 値がある場合、関数が実行され、ない場合はnoが実行されます。







その結果、非常にわかりやすい方法が得られます。

return filePath >> = fileExists >> = retrieveFileAttributes >> = extractCreationDate >> = checkExpired ?? 偽



あなたのことは知りませんが、ソーシャルネットワークでの作業に非常に悩まされています。 たとえば、Facebookに投稿するには、以下を行う必要があります。ユーザーがログインしているかどうかを確認します（ログインしていない場合はログインします）。 ログインしている場合は、エントリを公開する権利があるかどうかを確認し、そうでない場合は、エントリを収集してください。 ここで、これらすべてが呼び出しの小さなチェーンにどのように変わるか想像してみてください。エラーが発生した場合、それが何をするかすぐにわかります。

例2

2番目の例は、関数型言語でプログラムを理解することがいかに簡単かを示しています。







ここに、ある種の名前の配列があります。 彼とは何をしているの？ まず、「フィルター」-1文字の名前をすべて切り取ります。 次に、最初の文字を大文字にし、これらすべてをコンマで区切って区切ります。 入力配列を取得し、1文字の名前を削除して、文字列に変換することがわかりました。 ここで、命令型言語でそのようなコードを書くのにどれくらい時間がかかるか、そして他の誰かのプロジェクトでそのようなコードを見た場合にどれくらい時間がかかるかを考えてください。

AFを使用する必要がない場合

しかし、常に機能的なソリューションが最適であるとは限りません。 入力文字列内の各単語の出現回数をカウントする必要があるとします。 これを行うには、次のようにします。







つまり、辞書である結果を作成します。 定期的に改行し、すべての一致について、この単語が口実かどうかを確認します。そうでない場合は、インデックスの値を増やします。



関数型言語では、次のようになります。







ここでは、入力文字列と正規表現を受け取る関数を個別に分割します-分割して結果を返します。 そして、楽しみが始まります。 私たちのメイン関数は、最初に入力を小文字に変換する「マップ」を作成します。 次のステップ：この単語が独立しているか、単なる言い訳かを確認します。 次に、「forEach」を開始します。これは、この要素に対してこのピースが作成されることを示しています。



はい、「map」、「filter」、「forEach」などの機能は最適化されています。 しかし、ちょうど何回の反復が行われるかを考えてください！ 結局のところ、最初にすべての要素の「マップ」を作成し、次に余分な単語をフィルターで除外してから、これをすべての要素に適用します。 最初のケースでは、これらすべてが1つのサイクルで決定されました。



これは、機能スタイルの失敗した転送の例です。

おわりに

私たち全員が愛するオブジェクト指向プログラミングから関数型に切り替える必要があるとは言いたくありません。 正直に言ってください-関数型プログラミングの普及の時代は過ぎました。 必要な場合はオブジェクト指向のアプローチを使用する必要があると言います：UIコンポーネントがある場合、継承を持つことが重要な場合、先祖でいくつかのメソッドを定義することが重要な場合、このすべてを定義する場合ロジック。 しかし、タスクの巨大なレイヤー（データ処理、リストのフィルター処理など）もあり、これらはFPを使用して非常によく解決されます。



したがって、オブジェクト指向のメソッドでUIを記述し、意味のある型でモデルを作成することをお勧めします。 その後、パフォーマンスと読みやすさを向上させ、不要な効果を取り除きます。 さらに、コードはテスト可能になります。



結局のところ、テストは命令型言語でどのように書かれているのでしょうか？ ユニバースを作成し、いくつかのアクションを実行し、ユニバースで何が変更されたかを調べます。



深いものをテストする場合は、テストで呼び出しのチェーンを作成する必要があります。 FPのすべては単純です。関数は、同じ入力データに対して常に同じ値を返すため、テスト用の短いデータを書き込むことができます。