OOPがわからない

オブジェクト指向言語でプログラミングする方法がわかりません。 学ばない。 5年間の工業用Javaプログラミングの後、オブジェクト指向スタイルで優れたシステムを作成する方法はまだわかりません。 わかりません。



正直に学ぼうとしました。 私はパターンを研究し、オープンソースプロジェクトのコードを読み、頭の中で調和のとれた概念を構築しようとしましたが、高品質のオブジェクト指向プログラムを作成する原則をまだ理解していませんでした。 他の誰かがそれらを理解したかもしれませんが、私はそうではありません。



そして、ここに私が誤解されているいくつかの事柄があります。

OOPとは何かわかりません

真剣に。 OOPの主要なアイデアを策定するのは難しいと思います。 関数型プログラミングの主なアイデアの1つは、状態の欠如です。 構造-分解。 モジュール式-機能を完成したブロックに分離します。 これらのパラダイムのいずれにおいても、支配的な原則はコードの95％にまで及び、言語はそれらの使用を促進するように設計されています。 OOPの場合、このような規則はわかりません。



オブジェクト指向プログラミングは4つの基本原則に基づいていることは一般に受け入れられています（私が小さい頃は3つしかありませんでしたが、ツリーも大きくなりました）。 これらの原則：

• 抽象化
• カプセル化
• 継承
• 多型

ルールのセットのように見えますよね？ それで、95％のケースで従わなければならないまさにそのルールはここにあるのでしょうか？ うーん、詳しく見てみましょう。



抽象化



抽象化は強力なプログラミングツールです。 まさに私たちが大規模なシステムを構築し、それらの制御を維持できるようにするもの。 そのような機器を装備していなければ、少なくとも今日のレベルのプログラムに近づくことはないでしょう。 ただし、抽象化はOOPとどのように関連していますか？



まず、抽象化はOOPだけの属性ではなく、実際にプログラミングの属性ではありません。 抽象化のレベルを作成するプロセスは、人間の知識のほぼすべての分野に及びます。 したがって、材料の分子構造の詳細に入らずに、材料について判断することができます。 または、作成元の材料に言及せずにオブジェクトについて話します。 または、これらのエンティティの個々の詳細を思い出さずに、コンピューター、飛行機のタービン、人体などの複雑なメカニズムについて話します。



第二に、プログラミングの抽象化は、歴史の最初のプログラマーと考えられているAda Lovelaceの記録から始まっています。 それ以来、人々はプログラムで抽象化を絶えず作成してきましたが、そのための最も単純な手段しか持っていません。 そのため、AbelsonとSassmanは、悪名高い本で、手続きとリンクリストのみを使用して、複素数や多項式さえもサポートする方程式を解くシステムを作成する方法を説明しています。 それでは、OOPにはどのような抽象化の追加手段がありますか？ わからない。 ルーチンへのコードの分離？ どんな高級言語でもこれを行うことができます。 ルーチンを1つの場所に結合しますか？ これには十分なモジュールがあります。 入力しますか？ 彼女はOOPのずっと前にいた。 方程式を解くためのシステムの例は、抽象化レベルの構築が言語の手段にそれほど依存せず、プログラマーの能力に依存することを示しています。



カプセル化



カプセル化の切り札は、実装を隠しています。 インターフェースのみがクライアントコードを認識し、それだけを信頼できます。 これにより、実装の変更を決定する可能性のある開発者の手が解放されます。 そしてそれは本当にクールです。 しかし、質問は、OOPがそれとどう関係するのかということです。 上記のすべてのパラダイムには、実装の非表示が含まれます。 Cでプログラミングするときは、インターフェイスをヘッダーファイルに割り当てます。Oberonでは、フィールドとメソッドをモジュールに対してローカルにすることができます。最後に、多くの言語での抽象化は、実装もカプセル化するルーチンによって簡単に構築されます。 さらに、オブジェクト指向言語自体は、特別なメソッド（Javaのゲッターとセッター、C＃のプロパティなど）を介してデータへのアクセスを提供することで、カプセル化ルールに違反することがよくあります 。 （コメントでは、プログラミング言語の一部のオブジェクトはOOPの観点からはオブジェクトではないことがわかりました。データ転送オブジェクトはデータ転送を単独で担当するため、OOPの本格的なエンティティではないため、カプセル化を保存する必要はありません。アクセス方法は、アーキテクチャの柔軟性を維持するために最適に保持されます。これはそれほど単純ではありません。）さらに、Pythonなどの一部のオブジェクト指向言語は、何も隠そうとせず、合理性のみに依存します。 このコードを使用してazrabotchikov。



継承



継承は、OOPのおかげで実際に登場した数少ない新しいものの1つです。 いいえ、オブジェクト指向言語は新しいアイデアを生み出しませんでした-継承は他のパラダイムで実装できます-しかし、OOPは最初にこの概念を言語自体のレベルにもたらしました。 継承の利点も明らかです。あるクラスにほぼ満足したら、子孫を作成してその機能の一部を再定義できます。 C ++やScalaなどの多重継承をサポートする言語（後者では、特性による）には、別のユースケースがあります。ミックスイン、コードをコピーせずに新しいクラスと機能を「ミックス」できる小さなクラスです。



だから、ここにある-PLOを他のパラダイムとして区別するのは何ですか？ うーん...もしそうなら、なぜ私たちは実際のコードでそれをあまり使用しないのですか？ 支配的なパラダイムの規則に従うコードの95％について話していたことを覚えていますか？ 冗談じゃない 関数型プログラミングでは、コードの少なくとも95％が副作用のない不変のデータと関数を使用します。 モジュラーでは、ほとんどすべてのコードが論理的にモジュールにパッケージ化されます。 ダイクストラの教訓に従って、構造プログラミングの支持者は、プログラムのすべての部分を小さな部分に分割しようとします。 継承はあまり頻繁に使用されません。 コードの10％、おそらく50％、場合によっては（たとえば、フレームワーククラスから継承する場合）-70％で、それ以上ではありません。 ほとんどの場合、これは単に必要ではないためです。



さらに、優れた設計には継承は危険です。 彼らの本の中でギャングオブフォー（PLOの説教者のように思われる）は、可能であればそれを委任に置き換えることを推奨するほど危険です。 継承は、一般的な言語で存在する形式であるため、脆弱なデザインにつながります。 ある祖先から継承すると、クラスは他の祖先から継承できなくなります。 先祖の変更も危険になります。 もちろん、private / protected修飾子がありますが、クラスがどのように変化し、クライアントコードがそれをどのように使用できるかを推測するための強力な精神能力も必要です。 継承は非常に危険で不便なので、大きなフレームワーク（JavaのSpringやEJBなど）はそれらを拒否し、他の非オブジェクト指向ツール（メタプログラミングなど）に切り替えます。 結果は予測できないため、一部のライブラリ（グアバなど）はクラスへの継承を禁止する修飾子を規定しており、新しいGo言語では、継承階層を完全に放棄することが決定されました。



多型



多態性は、おそらくオブジェクト指向プログラミングの最も優れた点です。 ポリモーフィズムにより、出力時のPerson型のオブジェクトは「Adam Impolitovich Shandorkin」のようになり、Point型のオブジェクトは「[84.23 12.61]」のようになります。 「Mat1 * Mat2」を記述し、通常の数の積に似た行列の積を取得できるようにするのは彼です。 これがないと、ネットワーク、ファイル、またはメモリ内の行からデータが送られてくるかどうかを心配せずに、入力ストリームからデータを読み取ることはできません。 インターフェイスがあるところはどこでも、ポリモーフィズムも暗示されます。



ポリモーフィズムが大好きです。 したがって、私は主流言語での彼の問題についても話しません。 また、タイプのみによるディスパッチングアプローチの狭さ、およびこれをどのように行うことができるかについても黙っています。 ほとんどの場合、正常に機能しますが、これはすでに悪くはありません。 問題は異なります。多型は、OOPを他のパラダイムと区別するのと同じ原理ですか？ このテキストを読んでいるので、あなたが私に尋ねた場合、あなたはあなたが尋ねたと仮定することができます）、私はノーと答えます。 そしてその理由は、コードでの使用の割合と同じです。 インターフェイスとポリモーフィックメソッドは、おそらく継承よりも一般的です。 しかし、それらが占めるコードの行数を通常の手続き型スタイルで書かれた行数と比較してください-それらの行は常にもっとあります。 このプログラミングスタイルを奨励する言語を見て、それらを多態性と呼ぶことはできません。 多態性をサポートする言語-はい、それで問題ありません。 しかし、多相言語ではありません。



（しかし、これは私の意見です。あなたはいつでも反対できます。）



したがって、抽象化、カプセル化、継承、およびポリモーフィズム-これらはすべてOOPにありますが、いずれもその不可欠な属性ではありません。 それでは、OOPとは何ですか？ オブジェクト指向プログラミングの本質は、実際にはオブジェクト（非常に論理的に聞こえる）とクラスにあると考えられています。 これは、コードとデータを組み合わせるという考え方であり、プログラム内のオブジェクトが実世界の本質を反映しているという考え方でもあります。 この意見に戻りますが、まずはiについていくつかの点を挙げます。

誰のOOPがクールですか？

前の部分からわかるように、プログラミング言語は、オブジェクト指向プログラミングの実装方法が大きく異なる場合があります。 すべての言語ですべてのOOP実装の全体を取り上げると、ほとんどの場合、すべてに共通する単一の機能は見つかりません。 この動物園を何らかの形で制限し、議論を明確にするために、1つのグループ、つまり純粋にオブジェクト指向言語、つまりJavaとC＃のみに焦点を当てます。 この場合の「純粋にオブジェクト指向」という用語は、言語が他のパラダイムをサポートしていないか、同じOOPを介してそれらを実装していないことを意味します。 たとえば、PythonやRubyはクリーンではありません。 単一のクラス宣言なしで、完全なプログラムを作成できます。



JavaとC＃でのOOPの本質をよりよく理解するために、このパラダイムが他の言語でどのように実装されているかの例を見ていきましょう。



Smalltalk 最近の言語とは異なり、この言語には動的型付けがあり、OOPを実装するためにメッセージ受け渡しスタイルを使用していました。 メソッドを呼び出す代わりに、オブジェクトは互いにメッセージを送信し、受信者が到着したものを処理できない場合、彼は単にメッセージを他の誰かに転送しました。



Common Lisp 当初、CLは同じパラダイムに準拠していました。 次に、開発者は、「（send obj 'some-message）」の記述が長すぎると判断し、表記法をメソッド呼び出し-「（some-method obj）」に変換しました。 現在、Common Lispには、多重継承、マルチメソッド、メタクラスをサポートするオブジェクト指向プログラミング（CLOS）のシステムが開発されています。 特徴的な機能は、CLのOOPがオブジェクトではなく一般化された関数を中心に展開することです。



クロージュア。 Clojureには最大2つのオブジェクト指向プログラミングシステムがあります。1つはJavaから継承され、もう1つはマルチメソッドに基づいており、CLOSに似ています。



R.この統計データ分析用の言語には、S3とS4という2つのオブジェクト指向プログラミングシステムもあります。 どちらもS言語から継承されます（Rが商用Sのオープンソース実装であるため、これは驚くことではありません）。 S4の大部分は、現代の主流言語でのOOP実装に対応しています。 S3は、言語自体を使用して簡単に実装できる、より軽量なオプションです。受信したオブジェクトの「クラス」属性によってリクエストをディスパッチする1つの一般的な関数が作成されます。



Javascript イデオロギー的にはSmalltalkと似ていますが、異なる構文を使用します。 継承する代わりに、プロトタイプを使用します。目的のプロパティまたは呼び出されたメソッドがオブジェクト自体にない場合、リクエストはプロトタイプオブジェクト（すべてのJavaScriptオブジェクトのプロトタイププロパティ）に渡されます。 興味深い事実は、プロトタイプメソッドの1つを置き換えることで、クラスのすべてのオブジェクトの動作を変更できることです（たとえば、文字列クラスに `.toBASE64`メソッドを追加するなど、とても見栄えがします）。



Python 一般的に、彼は主流言語と同じ概念を順守していますが、JavaScriptやSmalltalkのように、属性検索の別のオブジェクトへの転送もサポートしています。



ハスケル。 Haskellには状態がまったくないため、通常の意味でのオブジェクトはありません。 それにもかかわらず、そこにはまだ一種のOOPがあります。データ型（型）は1つ以上の型クラスに属することができます。 たとえば、Haskellのほとんどすべての型はEqクラス（2つのオブジェクトの比較を担当）であり、すべての数値はさらにNum（数値の演算）とOrd（演算<、<=、> =、>）にあります。 月経言語では、クラスはタイプ（データ）に対応し、タイプはインターフェースに対応します。

ステートフルまたはステートレス？

しかし、オブジェクト指向プログラミングのより一般的なシステムに戻ります。 私が理解できなかったのは、オブジェクトと内部状態との関係です。 OOPを学習する前は、すべてがシンプルで透過的でした。いくつかの関連データを保存する構造があり、それらを処理する手順（関数）があります。 散歩（犬）、引き出し（口座、金額）。 その後、オブジェクトが来て、それも何もありませんでした（プログラムを読むのがずっと難しくなりました-私の犬は歩いた[誰？]、そして口座は[どこから]お金を引き出していました）。 その後、データの隠蔽について知りました。 私はまだ犬を散歩できましたが、彼女の食べ物の組成は見えませんでした。 食べ物は何のアクションも実行しませんでした（おそらく食べ物は食べる（犬）と書くことができますが、私は犬を食べ物を食べることを好みます。逆も同様です）。 食べ物は単なるデータであり、私（および私の犬）はそれらにアクセスする必要がありました。 すべてがシンプルです。 しかし、90年代後半の古いジーンズのように、パラダイムの枠組みに適合することはすでに不可能でした。



さて、データアクセス方法があります。 この小さな自己欺intoに行き、私たちが持っているデータが本当に隠されているふりをしましょう。 しかし今では、オブジェクトは主にデータであり、おそらくそれらを処理するメソッドであることを知っています。 プログラムの書き方、設計時に何を目指して努力するかを理解しました。



悟りを楽しむ前に、インターネット上でステートレスという言葉を目にしました（それは輝きに囲まれ、文字tとlの上にハローがかかっていると断言します）。 文献の簡単な研究により、オブジェクトの一貫性を追跡する必要なく、透明な制御フローと単純なマルチスレッドの素晴らしい世界が開かれました。 もちろん、私はすぐにこの素晴らしい世界に触れたいと思いました。 ただし、これはルールを完全に拒否することを意味します-犬が自分で歩くべきか、またはこのために特別なWalkManagerが必要かは不明でした。 アカウントが必要かどうか、または銀行がすべての作業を処理できるかどうか、必要な場合は、静的または動的にお金を償却する必要があります。 ユースケースの数は指数関数的に増加し、将来のすべてのオプションは深刻なリファクタリングの必要性につながる可能性があります。



オブジェクトをいつステートレスにするか、いつステートフルにするか、いつデータコンテナにするかはわかりません。 これは明らかな場合もありますが、よくあることです。

入力：静的または動的？

C＃やJavaのような言語で私が決定できないもう1つのことは、静的または動的に型付けされることです。 おそらくほとんどの人は、「なんてナンセンスだ！ もちろん静的に型付けされます！ コンパイル時に型がチェックされます！” しかし、本当に簡単なのでしょうか？ メソッドのパラメーターでタイプXを処方するプログラマーが、タイプXのオブジェクトが常にそれに転送されることを確信できるというのは本当ですか？ 本当-できない、なぜなら タイプX またはその子孫のパラメーターをメソッドXに渡すことができます。 ので、だから何？ クラスXの相続人はXと同じメソッドを保持します。メソッドごとのメソッドですが、作業のロジックは完全に異なることが判明する場合があります。 最も一般的なケースは、子クラスがX以外のニーズに最適化されており、この方法がその最適化に依存している場合です（このシナリオが現実的でない場合は、開発されたオープンソースライブラリにプラグインを書くか、ライブラリのアーキテクチャとアルゴリズムを分析するための数週間、または適切なシグネチャでメソッドをランダムに呼び出すだけです）。 その結果、プログラムは機能しますが、速度は1桁低下します。 コンパイラーの観点からは、すべてが正しいのですが。 Javaの後継と呼ばれるScalaは、デフォルトで多くの場所で指定された型の引数のみを渡すことができますが、この動作は変更できますが重要です。



もう1つの問題はnull値です。これは、Javaのほとんどすべてのオブジェクトの代わりに、C＃のNullableオブジェクトの代わりに渡すことができます。 nullは一度にすべてのタイプに属し、同時にどのタイプにも属しません。 nullにはフィールドまたはメソッドがないため、それを呼び出すと（nullのチェックを除く）エラーが発生します。 誰もが慣れているようですが、比較のために、Haskell（およびScala）は、他の言語でnullを返す可能性のある関数をラップするために特別な型（HaskellではMaybe、ScalaではOption）を使用する必要があります。 その結果、彼らはしばしばHaskellについて「プログラムをコンパイルするのは難しいが、それでもうまくいくなら、おそらく正しく動くだろう」と言う。



一方、主流の言語は明らかに動的に型付けされていないため、インターフェイスの単純さや手順の柔軟性などの特性はありません。 その結果、PythonまたはLispのスタイルでの記述も不可能になります。



すべてのルールがまだわかっている場合、違いは何ですか、そのようなタイピングの名前は何ですか？ 違いは、アーキテクチャの設計にアプローチする方法です。 システムの構築方法については長年の議論があります。多くのタイプと少数の機能、または少数のタイプと多数の機能を実行しますか？ 最初のアプローチはHaskellで積極的に使用され、2番目のアプローチはLispで使用されます。 現代のオブジェクト指向言語は、その間に何かを使用します。 これが悪いとは言いたくありません-おそらくその利点があるでしょう（最終的には、JavaとC＃には多言語プラットフォームがあることを忘れないでください）が、新しいプロジェクトを始めるたびに、どこからデザインを始めるべきかを考えますまたは機能付き。

その他...

タスクをモデル化する方法がわかりません。 OOPを使用すると、プログラムで実際のオブジェクトを表示できると考えられています。 しかし、実際には、犬（2本の耳、4本の足、首輪）と銀行口座（マネージャー、店員、昼休み）があり、プログラムではアカウントファクトリーのウォーキングマネージャーです... そして、ポイントは、プログラムが実際のオブジェクトを反映しない補助クラスを持っているということではありません。 事実は、 制御フローが変化しているということです。 , (, , ?).



, , , . , , .



, . Python C++, , . Java C# StringUtils. -- ad hoc ( ). . ( ) . 150 , — , , .



. — . - . HTTP URL, HttpConnection, Request… , . , . , — . .



, — . , , . , -, - . , .