Haopに関するOOPに特化した1週間の記事。 最後の記事は私に多くの感情を引き起こし、残念ながら非常に悪い感情を引き起こしました。 私はこの記事が本当に好きではありませんでした。 なんで？ OOPの使用に関する否定的な感情を伝えるからです。 感情は、人がOOPの完全な力を完全に理解しておらず、OOPが悪であると全員に納得させたいという事実によってのみ引き起こされます。 最も悲しいことは、人々は現実とは関係のないひどい議論を聞いて投げ始めるということです。 このような記事はGoFよりも学生には禁忌だと思います。できるだけ早く提供します。 :)
始めましょう。
OOPとは何ですか。 OOPはオブジェクト指向プログラミングおよび設計です。 もう一方のないものは完全に少し無意味です。 ソフトウェア製品の設計/プログラミングのためにOOPによって作成されました。 プロセスモデリング用ではありません。 プロトコル設計用ではなく、ソフトウェア製品用であり、実装用です。 プロトコルやビジネスプロセスなどを実装するシステムを簡素化するため。
OOPの使用を開始するとき、最初にすべきことはオブジェクト思考の使用を開始することです。 これはOOPの最大の問題だと言ったことがありますが、客観的に考えることを学ぶのは非常に難しいです。 そして、これをできるだけ早く行う方法を学ぶことが非常に重要です（ブリッジ、コンストラクター、ファサードなどの類推を持つGoFは、この点で非常に役立ちます）。 オブジェクト思考を使用すると、複雑なシステム
さらに進みましょう。 したがって、問題を解決するために必要なオブジェクトの抽象化を見つけるために、客観的に考えることが重要です。 類推と抽象化がうまく選択されると、システムで何が起こっているかをすばやく理解できる非常に明確な画像が表示されます。 そしてここで、継承とポリモーフィズムについて覚え始めます。 これらの2つのツールは、コードを複製せずにシステムを便利に拡張するために必要です。 しかし、これらのメカニズムの強さは、選択した抽象化とアナロジーの成功に依存します。 オブジェクトの思考がオブジェクトの便利な分解を形成できない場合、継承とポリモーフィズムは役に立ちません。 つまり 継承とポリモーフィズムは、システムのスケーリングの問題を解決できるツールにすぎません。
これらのツールはどのように機能しますか？ はい、蒸しているカブよりも簡単です。なぜなら、それはすべて私たちにとってなじみのあることに基づいているからです。 私は人生から簡単な例を愛しています：
1.継承。 パン屋があります。 電気ストーブとガスストーブがあります。 あなたの仕事は、各オーブンのパン職人による調理プロセスをシミュレートすることです。 問題を真正面から解決すると、食品をオーブンに移動するプロセスとオーブン自体を使用した作業が両方の炉で同一であるという事実により、多くのコードの重複が発生します。 しかし、オブジェクト思考を有効にして、継承ツールを思い出すと、次のようなものが得られます（図を描くのが面倒、ごめんなさい）：
ストーブ（抽象的なストーブ）があります。 彼女には行動があります-温度をオン、オフ、温度を上げたり下げたり、何かを置き、何かと状態を取得します-炉の温度はオンまたはオフです。 これは、カプセル化の原則が尊重されている抽象オブジェクトの素晴らしい例です（実装中は必ずそれに従います）。 そして、パン屋、イヴァンのような具体的なパン屋があります。 彼は、抽象的なストーブを使用する方法を知っています。 つまり 温度を見て、電源を入れるなど。 わかった。 継承の強みは、電気炉であろうとガス炉であろうと、各炉のIvanを書き換える必要がないことです。 誰もがその理由を知っていると思いますか？ ツールが正しく適用されていることがわかります。
2.ポリモーフィズム。 結局のところ、ストーブは異なる働きをします。 ガスはガス、電気ストーブ-電気を消費します。 ポリモーフィズムを使用すると、抽象炉の相続人の動作を簡単に変更できます。
3.カプセル化。 カプセル化の主な特徴は、オーブン内で何が起こっているかを知る必要がないことです。 ファーネスをオンにするメソッドを呼び出さず、そのプロパティをtrueに変更するとします。 この瞬間はどうなりますか？ カプセル化の原則が尊重されない場合、私は言うように強制されます 私はあなたをオンにしました。 つまり パン屋はストーブが燃料を消費していることを知っており、ストーブの仕組みを知っています。 または、たとえば、オーブンの温度を特定のレベルより下または上に設定することはできません。 カプセル化の原則に従わない場合、ストーブに現在の温度を確認するよう指示する必要があります。 つまり パン屋は再びストーブについて知りすぎている。 ゲッターとセッターは、状態変更の追跡を簡単に実装するのに役立つ言語ツールです。 それだけです ゲッターとセッターが空の場合、それは私の抽象化レベルにあるはずです。 ゲッターとセッター-カプセル化の実装を妨げることはできません。設計者/プログラマーは、カプセル化を不正に実装できます。
この例では、抽象化のレベルが適切に選択されています。 すべてが彼らのビジネスに取りかかります; 3つのOOPクジラすべてが栄光のために働きます。 しかし、悪い抽象化を選択すると、本当の悪夢が始まります。 また、
また、OOPのもう1つの柱として、抽象化を追加し始めました。 私はこれが本当である可能性が高いと思いますが、それは本当にCEPのスマックです。
タイピングに関する声明にも夢中になりました。 事実は、あなたが相続人から今働いている人に問題がないということです。 現在の抽象化レベルで、炉を使用することが重要である場合、それが何であるかは関係ありません。 ストーブはもらえますか？ 問題は解決しましたか？ これとあれ...なぜこれが動的なタイピングだと思いますか？ 焼きますか？ 取って 電気が必要ですか？ 申し訳ありませんが、ガスはもうあなたに合わないでしょう。
私を捕まえた記事で与えられた残りの例は、タスクのフレームワークでひどく選ばれた抽象化と類推の例にすぎませんでした。 ポイント。
別途、DTOについて。 DTOはパターンです。 これにより、情報を別のレイヤー、別のシステム、簡単に言えばどこかに送信するオブジェクトを作成できます。 なぜそれがオブジェクトとして私に考えられないのかは、一般的に私には謎です。 その矛盾はどこにありますか？ コンテナのみですか？ だから何？ これは、特定の抽象化レベルで調べたオブジェクトモデルのフレームワーク内の同じオブジェクトです。DTOはオブジェクトであり、分解の一部です。
言語についても、何を言おうかわからない。 言語に関係なく、オブジェクトアプローチを使用してソフトウェアを設計できます。 しかし、言語がオブジェクトを操作するための基本的なツールを実装していない場合、設計したシステムを実装することは非常に困難または不可能になります。
また、オブジェクトやそれらの相互作用の形で表現できないものもあると言います。 これはそうではないと確信しています。 抽象化のレベルを正しく選択するだけです。 プロトコルの実装、データベースへのアクセス層、プラグイン、タスクマネージャー、ビジネスプロセス、ビジネスプロセス設計システム、つまり 何でもオブジェクトとその相互作用として表すことができます。 すべては、オブジェクトとそれらの間の相互作用として実現できます。 良くも悪くも、ほとんどの場合、客観的に考える能力に依存します。
まとめます。 OOPの力を理解していない場合は、オブジェクト思考を開発する必要があります。
PS最後の記事へのコメントで、私は明らかに何人かの人々に話しかけたときに行き過ぎました。 謝ります