私はOO学習を始めたばかりのバックグラウンドですFPパラダイム。出会いました quote Michael Feathersによる-"OOは、可動部分をカプセル化することでコードを理解できるようにします。FPは、可動部分を最小化することでコードを理解できるようにします "
「moving parts
"?パーツを動かすことで、彼は" state mutation
"FPはimmutability
を促進して状態の変化を最小限に抑えますが、OOは状態の変化を妨げず、データをカプセル化します(したがって、オブジェクトの状態)
FP不変性を促進し、副作用がないため、コードがより明確になり、そのため、命令よりもわかりやすく、宣言的になるため、純粋な関数がどれほど純粋であるかを感じることができます。同様の性質の利点は、 OOの状態で、変化する状態がカプセル化されている場合。
例以下のアダプタオブジェクトはパブリックインターフェイス経由でのみアクセスされますが、各ステップは前のステップでソート状態の遷移を想定しているため、その状態はカプセル化されていないと感じます。したがって、実行メソッドは本質的に必須に見えます。
void Execute(IdataAdapter adapter) {
adapter.ReadFromSource();
adapter.ProcessData();
adapter.WriteToDestination();
}
カプセル化に関するオブジェクト指向の定義は、主に、データの非表示と、クライアントを壊さずに内部データ構造を変更するようなアドバンテージについて話します。しかし、Michael Feathersによる上記のステートメントのコンテキストでそれをよりよく理解したいと思います。 私の質問は基本的に-変更状態をOOにカプセル化することにより、FPと同じようにコードを理解しやすくし、状態を最小化することによって突然変異?
はい、どちらも共通の問題へのアプローチです。
「猫の動画を共有するウェブサイトを持っている!」からアクセスするためには、ソフトウェアプログラムには必然的に多くの部分が含まれます。 (または何でも)「1と0でいくつかの操作を実行できます!」基本的に、すべてのプログラムは1と0のいくつかの基本的な演算として終了します。
抽象化を提供しない場合、プログラムに構造を提供しない場合、それらは巨大で不可解な大きな操作の束です。オブジェクト指向プログラミングは、オブジェクトを介して抽象化と構造を提供します。関数型プログラムは、関数を介して抽象化と構造を提供します。そしてもちろん、それぞれが他のものを少し持っている傾向があり、適切な測定のためにいくつかの命令型プログラミングがあります。
しかし、根本的な動機は同じです。
OOの場合)状態の変化がカプセル化されている場合、類似した性質の利点はどういうわけか私にはあまりわかりません。
上記のコメントを作成した後、状態が明らかにnotカプセル化されているコードを表示します。もちろん、その場合の利点はわかりません。
よく書かれたOOコードでは、クラスのメソッドは、オブジェクトに何をすべきかを伝えるよりも、何が起こったのかを伝えることに関するものであることがわかります。(viewDidLoad
、buttonTapped
、serverRespondedWith
など)
あなたが示す例では、関数はアダプタに何をすべきかを明示的に指示しており、重要なのは、アダプタを使用するクラスmust knowエラーなしでメソッドを呼び出すためのアダプタの状態(たとえ明示的に状態をチェックすることはありません。)