私はおそらくOOPを知っています。 オブジェクト指向プログラミングおよび設計の経験。 答えは「OOPを知らない」です。

「 OOPがわからない 」などの記事が掲載された後、「表紙を引き裂く」、「真実の底にたどり着く」という明確な願望があります。

オブジェクトの向きの原則

通常、4つの「オブジェクト指向プログラミングの原則」は区別されます（インタビュー：インタビュー中）：抽象化、カプセル化、継承、およびポリモーフィズム。



私の意見では（抽象化とポリモーフィズムは継承のサブセクションに簡単に起因する可能性があることは言うまでもありません）、 ここでの原則は一般に、データベースを設計するときと同じです： オブジェクトの形ですべてを表現します-プロパティを持つ何か 。 通常、セットは固定され、オブジェクトのクラスについて話します。クラスの概念がなくても、特定の名前のプロパティの存在はプログラムロジックによって暗示されます。 特定の最小限のプロパティセットの形式のクラスのようなものがまだ存在しています。 一般に、ビューは長年のC-shnoy / Pascalデータ型struct / recordに戻ります。 次に、（関数型プログラミングの意味での）少しの「機能」を追加しました。プロパティの値は、さらに、構造/レコード自体へのアクセス権を持つ関数、プロパティの値のいずれかです。 この現象は、ドイツ語のラテン語を話すネーミングの最良の伝統（オプションが「オプション」と呼ばれ、数の程度が「効力」と呼ばれる場合）で、「 方法 」と呼ばれていました。 Pascalの「レコード」のような各サブジェクトの表示と組み合わせて、コードを再利用したいという願望は、「 継承 」の概念につながりました。



「メソッド」の出現により、機能の編成に関して別の楽しい瞬間が浮かび上がりました。名前の前半と後半が重複する900個の関数を作成する代わりに（WordBasicを思い出してください）、それぞれに30個のメソッドを持つ30個のクラスを作成できます。



また、 厳密な静的型付けを使用して言語を作成できるようになりました。これにより、多くのエラーを検出する時間をプログラム実行段階からコンパイル段階に移すことができました。 また、 厳密な静的型付けの場合、子孫でのみ実装されているという事実にもかかわらず、メソッドが宣言されているクラスを作成することが必要になる場合がありました。 そのため、 純粋に仮想的なメソッドと抽象クラスの概念が登場しました 。



また、カプセル化、継承、抽象化、およびポリモーフィズムは、「原則」ではなく、オブジェクト指向プログラミングの「ガイドライン」です。 特に、カプセル化により、プロキシが可能になります。 ガイドラインは、「プログラミング」のプロセスであり、「設計」や「アプローチ」ではなく、多くの場合誤解を招く可能性があることに注意してください。

批判。 継承 インターフェースの誕生

継承の概念が開発されたことで、オブジェクトを複数のクラスに同時に属することができるようになりました。これらのクラスは、相互に関連する親および子孫ではありません。 これは、多重継承の可能性を導入することで実行できます。 しかし、判明したように、真の多重継承は通常「 菱形継承 」の問題を引き起こします。同じクラスの2つの子孫から継承する場合、同じメンバー（フィールド、プロパティ、メソッド）の多重継承を解決する方法は明確ではありません。



この問題は、「 インターフェース 」の発明によって完全に解決されました。つまり、純粋に仮想的なクラスのみがメンバーとして許可される完全に抽象的なクラスです。 抽象メソッド。 「静的実装を挿入する場所」（一般的に、厳密に型指定された言語のクラスメソッドは、何かの値と考えると静的です。この「値」-メソッドの定義-はクラスのすべてのインスタンスで同じです）-唯一のものこれらのメソッドで許可されていたものは、定義上、「菱形継承」の問題を引き起こすことはできませんでした。 さらに、カプセル化の普及により、メソッドのみが「突き出ている」場合、これは異常なものとして認識されません。



別のインターフェイスは、非機能言語の機能パラダイムをほぼ実装し、実際に一連のアルゴリズムを引数として渡すことができるという点で優れています。

批判。 「実際の」クラスがそれほど少ないのはなぜですか。 複数のディスパッチ。 「マネージャー」の誕生とドメインオブジェクトからの分離。 シングルトン

クラスは一連のプロパティと「動作」であると考えられています。 1998年にVisualBasic 5のヘルプから読んだ言葉を思い出します。次のようなものです。 イベントはオブジェクトがあなたにそれが行われたと伝えるものです 。 " それで、「振る舞い」についてはまだ疑問があります-方法か何かです。



設計上の問題は、「動作」に2つ以上のクラスが含まれるときに始まります。 解説のとおり-「身長、体重、年齢-プロパティ。 歩くには、cn（p）が行動です。「ここでは、文字「p」で行動をモデル化する場合、More ThanとWhere（および「walk」も-Whereもあります）があります。 一般に、複数の非プリミティブクラスがアクションに関与している場合、オブジェクトモデルを開発するときに、2、3、4などのどれかという疑問が生じます。 クラス—この場合、「who」、「by」、または「where」-このアクションをモデル化するメソッドは属しますか？ いずれにせよ、これはおそらく密結合であり、システムをさらに構築する過程で（そして、絶え間ない完了、拡張、改善は、例外的な状況ではなく、定期的なものと見なされるべきです）



この問題は、特別なエンティティ「 マネージャー 」を強調表示することで解決されます。 その結果、「銀行口座」タイプのオブジェクトにはtransfer_on（account、amount）のメソッドがありませんが、代わりに「account manager」タイプのオブジェクトにはtransfer_s_na（s_account、to_account、amount）のメソッドがあります。



「マネージャー」ではないが、実世界のオブジェクト（ ドメインオブジェクトクラス）を反映するクラス自体は、この傾向を続けており、通常、カプセル化の原則を保証するために必要なメソッド（最も原始的なアクセサーとミューテーター）以外はありません。 そして、それは典型的です。複数のディスパッチ問題が即座に根本的に解決されるオブジェクトシステムでは-CLOSでは-そのようなメソッドはありませんが、システム全体に属する異なるタイプの引数を持つ同じ名前の特別な関数があります。



興味深いことに、一般的なケースでは、 transfer_s_on（s_account、to_account、amount）のメソッドがあることを除いて、「アカウントマネージャー」のタイプについて何も知る必要はありません。 つまり これは典型的な実装イ​​ンターフェースです。 データの整合性を確保するためのメカニズムを変更する必要がある場合（トランザクションから手動ロック、またはその逆）、「アカウント」などのコードを書き換える必要はありません。また、何も書き換える必要はありません（それぞれ古いものを再テストする必要はありません）インターフェイスの新しい実装を作成します。



そのような方法が参加者の一人に残されることになった同じ場所で、ビジターの「デザインパターン」タイプのugさを使用する必要があります。機能が実際に「外側」に引き出され、「内側」が「内側」のままであるかのように引っ張られる場合



問題は、クラスに現実のオブジェクトモデルの観点から不可欠なプロパティがない場合、物理オブジェクトをモデル化しない場合、そのコピーがいくつ存在する必要があるかということです。 十分ではないでしょうか？ 一般に、インスタンスの数が少ないほど効果的であり、その数は技術的な理由（たとえば、プールからの接続ごとに1つ）によって決まります。 特に縮退した場合、1つのインスタンスで十分です。特にその作成が非常にリソースを消費する場合は。 これは、デザインパターン「 シングルトン 」-「ロンナー」と呼ばれます。 このクラスは、静的メソッドを介して取得できるインスタンスが1つだけになるように記述されています。



今日の時代では、サービスクラスのインスタンス化の問題がさまざまな依存関係インジェクターに委ねられているため、インスタンスの厳密な手動制御の例としてのシングルトンパターンの実装は、一種の密結合であり、したがって設計原則の違反であり、非常に非コミットです。

批判。 「再定義されたコンストラクタが必要です。」 工場

複雑な動作を伴うコンストラクターの使用、および継承の集中的な使用は、一般に、密結合（フィールドとインターフェース、hehe）の例であり、これに関連して、悪いマナーです。 下位クラスのコンストラクターを呼び出すとき、すべての祖先クラスのデザイナーが最初に呼び出されます。これは一般に、多くの場合、必要ではなく、一般的にリソースを消費し、単に有害です。 クラスインスタンスロジックを別のサービスクラスに集中し、すべての「販売前の準備」を同時に実行することをお勧めします。 サービスクラスは、すでに説明したすべてのストップを備えたインターフェイスなどとして設計できます。 「 ファクトリー 」が判明します。



ファクトリにはさらにいくつかの利点があります。1）nullを返すことができ、2）同じオブジェクトを何度も返すことができます。

批判。 プリミティブおよびその他のValueオブジェクト。 免疫。 内部化。

「すべてがオブジェクトである」という原則は、もちろん、その一貫性によって引き付けられます。 最初は、オブジェクト自体のプロパティ値はオブジェクトではないと想定されています。 そして、一般的に、クラスシステムは最終的に「実」への出力を持つ必要があり、「実」は常にFoxProタイプのいずれかのタイプのデータです：数値、文字列、日時、またはyes / no。 したがって、過度の柔軟性が必要でない場合は、オブジェクトを使用してすべてを実行せず、一部の非オブジェクトデータ型を残すことをお勧めします。



この考え方は、特に高レベルの言語（オブジェクトがそれらへの参照によって排他的に表される自動ガベージコレクションのある言語）で特に重要になります。 パフォーマンスを高速化するには、すべてのデータ型を参照する必要はありません。



Valueオブジェクトのデザイン境界のC プリミティブ 。 これらは、特別なメソッドを持たないオブジェクトであり、プリミティブまたはValueオブジェクトの値を持つプロパティのセットを持ち、物理的な同一性（それらへの同じ参照）ではなく、プロパティ値に基づいて同等性がチェックされます。



多くの場合、（むしろ、原則として）Valueオブジェクトは不変になります。 不変です。 イミュニティを使用すると、複雑な値オブジェクトをキーとして大胆に使用でき、通常、追加の「グッズ」を提供します。特に、「バック」ロジックのない不変のスクエア缶は、不変の長方形の継承者となります。



免疫の概念の隣には、 内部化の概念があります。つまり、特定のクラスのすべての等しい（プロパティ値に関して）オブジェクトは物理的に等しい、つまり 同じオブジェクトでした。 これは、このクラスのこれまでに使用されたすべてのインスタンスを静的または異なる「シグルトン」セット（セット）に保存し、理想的には、一意性をチェックしてすべての「製品」を「渡す」「工場一意のコピーのみを配布します。 作成フェーズでは、これは非常に遅くなりますが、使用は何度も加速されます。

IRLクラス。 批判。 「一部のクラスは他のクラスよりも同等です」

「平等」のクラスのピラミッドの頂点近くで、クラスの等価性が侵害されています。 特に、「オブジェクト指向の」ランタイム環境自体にラップしたい場合。



Javaでは、すべてのクラスのルートクラスはObjectクラスです。 ただし、Objectクラスには、Class型のオブジェクトを返すgetClass（）メソッドと、String型のオブジェクトを返すtoString（）メソッドがあります。 CloneNotSupportedException、InterruptedException、IllegalArgumentException、Throwableをスローするメソッドもあります。 同時に、Classクラス、Throwableクラス、およびStringクラスはObjectクラスの直接の子孫であり、CloneNotSupportedException、InterruptedException、およびIllegalArgumentExceptionは間接的なもの以上です。 一般に、メソッドの半分と、悪名高い子孫へのリンク（多くの場合間接的）を持つクラスは、（循環依存関係のように）悪い設計ですが、「できなくても本当に必要な場合は、一度できます」。 また、例外とエラーのルートクラス（Throwable）には、その間接的な子孫への参照も含まれています。IllegalStateExceptionとIllegalArgumentExceptionです。



ただし、StringクラスとClassクラスはfinalです。 子孫を持つことはできません。これにより、Objectクラスでの使用の「犯罪性」が軽減されます。

IRLクラス。 彼らは最終的に何をした

Java言語では、クラスは主にオブジェクトのラベルになりました。 メソッドのオーバーロードが頻繁に使用される状況では、大部分はメソッド名の一部にもなります。 時間の経過に伴う強力なタイピングは、予想外のプラスの役割を果たしました。Java言語がリファクタリングに最も適していることが判明しました。



継承、およびドメインオブジェクトのクラスへのアルゴリズムの添付は、密結合および悪い習慣として認識されており、厳密に用量に適用されます。 特に、さまざまなソーシャルネットワークで動作するプログラムに「ソーシャルアカウント」エンティティを実装する好ましい方法は、FBAccount、VKAccount、TwitterAccountの子孫を持つ抽象SocialAccountクラスを作成するのではなく、データから通常のSocialAccountドメインクラスとファクトリコンバーターを作成することですさまざまなソーシャルネットワークから、おそらくJSON-to-SocialAccount-convertersからも。 ORMを思い出させますか？ だから約10年前にすべてが戻ってきました：データベースの読み取り/書き込みロジックが永続クラス自体のメソッドに含まれるDB永続プラットフォームが配布されました。そのため、DBExternalizableObjectのような特別なクラスから継承する必要がありました。 その後、「ご存知のとおり」彼らはそれを拒否しました。



さらに、実際には、実際、ほとんどの場合、メロンデータベーステーブル内のレコードの「レイヤー」であり、最初はDBMSまたはDBMS設計ツールで設計されます。



また、プロパティ、メソッド、および継承を備えた「通常」、「クラシック」クラスは、主にアプリケーションサーバーやその他のライブラリにあります。



UPD ：コメントは、「厳密な」タイピングについてではなく、「静的」について話す必要があることを正しく示唆しました。 私は定期的に混乱します。