私は最近、 OOPのファンではない同僚と議論をしました。私の注意を引いたのは彼が言ったことでした：
「オブジェクトでコーディングを行う意味は何ですか？再利用する場合は、ライブラリを作成して、手元にあるタスクに必要な関数を呼び出すことができます。ポリモーフィズム、継承、インターフェイス、パターンなどの概念が必要ですか？ 「」
私たちは、eコマースサイトや不動産向けの小さなプロジェクトを開発している小さな会社にいます。
「日常の現実の」セットアップでOOPを利用するにはどうすればよいですか？それとも、OOPは本当に複雑な問題を解決することを目的としており、「日常」の開発を目的としたものではありませんか？
私の個人的な見解：文脈
OOP でプログラミングすると、コンテキストをよりよく認識できます。実世界もオブジェクト指向であるため、理解しやすいようにコードを編成するのに役立ちます。
OOP の利点は、一連のデータを一連の動作に関連付けることから得られます。
したがって、関連する一連のデータに対して関連する多くの操作を行う必要がある場合は、構造体を操作する多くの関数を記述したり、オブジェクトを使用したりできます。
オブジェクトは、継承の形でコードの再利用を支援します。
IME では、一連の複雑な構造体とそれらを操作する関数を保持することである既知の一連の属性とメソッドを持つオブジェクトを操作する方が簡単です。
一部の人々は、継承とポリモーフィズムについて続けます。これらは価値がありますが、(私の意見では) OOP の真の価値は、データをカプセル化し、動作に関連付ける優れた方法にあります。
プロジェクトで OOP を使用する必要がありますか? それは、言語が OOP をどれだけサポートしているかによって異なります。それは、解決する必要がある問題の種類によって異なります。
しかし、小規模な Web サイトを作成している場合でも、開発言語で適切にサポートされている OOP 設計を使用するのに十分な複雑さについて話していることになります。
何かを機能させるだけでなく、よく設計された OO 設計は、理解しやすく、従い、拡張し、拡張し、実装するのが簡単です。たとえば、分類的に類似している作業を委譲したり、一緒に保持する必要があるデータを保持したりするのは非常に簡単です (そうです、C 構造体もオブジェクトです)。
まあ、多くの人がより多くの学術的に正しい答えを出すと確信していますが、最も価値のある利点のいくつかを以下に示します。
ほとんどのプログラミング言語の力は、それらが利用できるようにする抽象化にあります。オブジェクト指向プログラミングは、関連するアイデアやアクション間の関係を管理できるように、非常に強力な抽象化システムを提供します。
任意の拡大する形状のコレクションの面積を計算するタスクを検討してください。プログラマーなら誰でも、円、正方形、三角形などの領域の関数をすばやく作成できます。それらをライブラリに保存します。任意の形状の面積を識別して計算するプログラムを作成しようとすると、問題が発生します。五角形などの新しい種類の形状を追加するたびに、IFまたはCASE構造のようなものを更新および拡張して、プログラムが新しい形状を識別し、「関数のライブラリ」から正しい領域ルーチンを呼び出せるようにする必要があります。しばらくすると、このアプローチに関連するメンテナンスコストが蓄積し始めます。
オブジェクト指向プログラミングでは、これの多くは無料です。areaメソッドを含むShapeクラスを定義するだけです。次に、実行時にどの特定の形状を処理するかは実際には重要ではありません。各幾何学的図形をShapeから継承するオブジェクトにして、areaメソッドを呼び出すだけです。オブジェクト指向パラダイムは、現時点で、このユーザー入力を使用して、30分前に追加された円、三角形、正方形、五角形、または楕円オプションの面積を計算する必要があるかどうかの詳細を処理します。
エリア関数が呼び出された方法の背後にあるインターフェイスを変更することにした場合はどうなりますか？オブジェクト指向プログラミングでは、Shapeクラスを更新するだけで、変更はそのクラスから継承するすべてのエンティティに自動的に伝播されます。オブジェクト指向ではないシステムでは、「関数のライブラリ」を調べて、個々のインターフェイスを更新するという課題に直面することになります。
要約すると、オブジェクト指向プログラミングは、コードの繰り返しを排除し、拡張機能とメンテナンスを合理化することで、時間と労力を節約できる強力な抽象化形式を提供します。
デザイン パターンの使用を見れば、OOP の有用性がわかります。カプセル化と再利用だけでなく、拡張性と保守性も重要です。物事を強力にするのはインターフェースです。
いくつかの例:
オブジェクトなしでストリーム (デコレータ パターン) を実装するのは難しい
新しい暗号化タイプ (戦略パターン) などの既存のシステムに新しい操作を追加することは、オブジェクトがないと難しい場合があります。
PostgresQL の実装方法と、データベースの本でデータベースを実装する必要があると書かれている方法を比較すると、大きな違いがわかります。この本は、各オペレーターのノード オブジェクトを提案します。Postgres は無数のテーブルとマクロを使用して、これらのノードをエミュレートしようとします。そのため、あまりきれいではなく、拡張するのがはるかに困難です。
リストは続きます。
私にとって、OOPの力は、継承とポリモーフィズムについて話し始めるまで現れません。
OOPに対する議論がカプセル化と抽象化の概念に基づいているとすれば、それは私にとってあまり説得力のある議論ではありません。巨大なライブラリを作成して、ユーザーに認識してもらいたいインターフェイスのみを文書化することも、Adaのパッケージなどの言語レベルの構造に依存してフィールドをプライベートにし、必要なものだけを公開することもできます。公開。
ただし、本当の利点は、コードを汎用階層で記述したときに得られるため、後で再利用して、同じ結果を達成するために異なる機能に同じ正確なコードインターフェイスを使用できます。
なぜこれが便利なのですか？私は巨人の肩の上に立って現在の仕事を遂行できるからです。アイデアは、問題の部分を最も基本的な部分、つまり、構成するオブジェクトを構成するオブジェクト、つまりプロジェクトを構成するオブジェクトに要約できるということです。一般的なケースで動作を非常によく定義するクラスを使用することで、同じ実証済みのコードを使用して、同じもののより具体的なバージョンを作成し、次に同じもののより具体的なバージョンを作成し、さらにさらに具体的にすることができます同じもののバージョン。重要なのは、これらの各エンティティには、すでにコーディングおよびテストされた共通性があり、後で再度実装する必要がないということです。これに継承を使用しない場合、共通の機能を再実装するか、新しいコードを古いコードに明示的にリンクすることになります。
ポリモーフィズムは、オブジェクトから特定の機能を実現する必要がある場合に非常に便利ですが、類似しているが一意のタイプからも同じ機能が必要です。たとえば、Qtでは、データを表示してそのオブジェクトのメタデータを簡単に維持できるように、モデルにアイテムを挿入するというアイデアがあります。ポリモーフィズムがなければ、私は現在よりもはるかに詳細に気を配る必要があります（つまり、元々モデルに含めることを意図していたアイテムと同じビジネスロジックを実行する同じコードインターフェイスを実装する必要があります）。データバインドされたオブジェクトの基本クラスはモデルとネイティブに相互作用するため、代わりに問題なくこのモデルにメタデータを挿入できます。モデルが何を必要としているかを気にすることなく、オブジェクトから必要なものを取得します。
すべてのプログラミングパラダイムには同じ目標があります。それは、不要な複雑さを隠すことです。
いくつかの問題は、友達が使用するような命令型のパラダイムで簡単に解決できます。その他の問題は、オブジェクト指向のパラダイムで簡単に解決できます。他にも多くのパラダイムがあります。主なもの（論理プログラミング、関数型プログラミング、および命令型プログラミング）はすべて互いに同等です。オブジェクト指向プログラミングは通常、命令型プログラミングの拡張と考えられています。
オブジェクト指向プログラミングは、プログラマーが類似しているが同じではないアイテムをモデリングしている場合に最適です。命令型パラダイムは、さまざまな種類のモデルを1つの関数にまとめます。オブジェクト指向のパラダイムは、さまざまな種類のモデルを、関連するオブジェクトのさまざまなメソッドに分離します。
あなたの同僚は1つのパラダイムにとらわれているようです。幸運を。
1994 年頃、私は OOP と C++ を同時に理解しようとしていましたが、OOP の価値が原理的には理解できていたにもかかわらず、不満を感じていました。私は他の言語 (主に Basic、Assembly、および Pascal ファミリー言語) からアプリケーションのあらゆる部分の状態をいじることができることに慣れていたので、学術的な抽象化を優先して生産性をあきらめているように思えました。残念なことに、MFC のような OO フレームワークとの最初の数回の遭遇で、ハッキングが容易になりましたが、必ずしも多くの啓蒙が得られるわけではありませんでした。
持続性、オブジェクトを扱う別の (C++ 以外の) 方法への露出、オブジェクト指向コードの注意深い分析の組み合わせによってのみ、1) 機能し、2) 私が開始した同等の手続き型コードよりも一貫性があり直感的に読めるようになりました。本当にそれを得るために。そして 15 年後、手続き型のアプローチでこれほどきれいに実行するとは想像もできない、巧妙でありながら驚くほど単純な OO ソリューションの新しい (私にとっての) 発見に定期的に驚かされます。
私はここ数年、関数型プログラミングのパラダイムを理解しようとして、同じ一連の闘争を経験してきました。ポール・グラハムの言葉を借りれば、権力の連続体を見下ろすと、欠けているものがすべて見えてきます。力の連続体を調べているとき、力は見えません。ただ奇妙に見えます。
何か別の方法で何かを行うことにコミットするには、1) 誰かがより強力な構成要素を使用して明らかに生産性を高めているのを見て、2) 壁にぶつかったときに不信感を一時停止する必要があると思います。新しいパラダイムの理解において、少なくとも少し先に進んでいるメンターを持つこともおそらく役立つでしょう.
不信感を一時停止するために必要な勇気がなければ、オブジェクト指向モデルの価値を誰かにすぐに理解してもらいたい場合は、Rails に関する Pragmatic Programmers の本で 1 週間を過ごすよう誰かに依頼するよりもはるかに悪いことをする可能性があると思います。残念ながら、マジックがどのように機能するかについての多くの詳細が省略されていますが、OO 抽象化システムの能力を紹介するのに非常に適しています。その本を読んだ後でも、同僚がまだ何らかの理由で OO の価値を理解していない場合、その同僚は絶望的なケースかもしれません。しかし、もし彼らが、非常に独断的な OO 設計が機能し、手続き型言語で同じことを行うよりもはるかに速く 0 から 60 に到達するアプローチに少し時間を費やしたいと思うなら、希望があるかもしれません。あなたの仕事がWeb開発に関係なくても、それは真実だと思います。
特に C# や Java のような静的に型付けされた言語では、現実世界をモデル化することがわかっているため、「現実世界」を取り上げることが、優れたアプリを作成するための実用的なフレームワークと同じくらいセールス ポイントになるかどうかはわかりません。多くの場合、曲がりくねった抽象化が必要です。「形状」(形状、楕円、円) の幾何学的な抽象化のように表向きは単純なものをモデル化するのに苦労している何千人もの人々を見ると、現実世界をモデル化することの難しさの具体的な例を見ることができます。
友人に、自分の部屋、家、または都市にあるオブジェクトを視覚化するように依頼します。そのようなオブジェクトを1つだけ、システム自体がシステムであり、意味のある作業を実行できるかどうかを確認できます。
ボタンのようなものは、単独で何かをしているのではありません-電話をかけるにはたくさんの物が必要です。
同様に、自動車のエンジンはクランクシャフト、ピストン、スパークプラグでできています。オブジェクト指向の概念は、自然のプロセスや生活の中での私たちの認識から進化してきました。
「InsideCOM」の本は、質問をすることによって動物を識別するという子供の頃のゲームから類推することによって、COMの目的を説明しています。
デザインはテクノロジーと方法論に勝ります。優れた設計には、オブジェクト指向言語の機能が体系化しようとしているものの中心にあるデメテルの法則など、複雑さの管理の普遍的な原則が組み込まれている傾向があります。
優れた設計は、OO固有の言語機能の使用に依存しませんが、通常、それらを使用することが最善の利益になります。
作るだけでなく
詳細については、以下を参照してください: - Java : Hibernate - Dot Net : Entity Framework
LINQ (Visual Studio) を使用すると、プログラミングがいかに簡単になるかをご覧ください。
ちょっとしたデモでデモンストレーションするのも楽しいかもしれません:
.PS. 私はPSEUDOの方法でそれを書いてみました:)
呼び出すコード: io.file.save(objectsCollection.ourFunctionForSaving())
クラスオブジェクトコレクション
関数 ourFunctionForSaving() As String
文字列_オブジェクト
for each _Object in objectsCollection
Objects &= _Object & "-"
end for
return _Objects 終了メソッド
oo 以外のコードを書き留めるとは思いません。しかし、考えてみてください:)
OOの方法で。上記のクラスは、書籍、従業員、メンバー、アカウントなどを保存するためのすべてのメソッドの親クラスです...テキストファイルへの保存方法を変更したい場合はどうなりますか? たとえば、現在の標準 (.CVS) でコンパクト化できるようにします。
そして、ロード機能を追加したいとしましょう。どのくらいのコードを書く必要がありますか? オブジェクト指向の方法では、すべてのデータをパラメーターに分割できる New Sub メソッドを追加するだけで済みます (これは 1 回発生します)。
あなたの同僚にそれについて考えさせてください:)