OOPとデザインパターンはどのように関連していますか？
デザインパターンはOOP原則の拡張ではありませんか？これらの2つの概念が別々に扱われるのはなぜですか？デザインパターンを知っている人が間違いなくOOPの専門家になると信じられますか？
デザインパターン は、一般的なプログラミングの問題に対する試行錯誤されたソリューションです。それは必ずしもオブジェクト指向プログラミングの問題である必要はありませんが、それは最近最も一般的です。
プログラムを学ぶことは多くの人にとって難しいことではありません。これは、レゴで遊ぶようなものです。好きなようにスナップできるさまざまなピースがいくつかあります。時々あなたは何かクールなものを作ります、しかしほとんどの場合あなたはがらくたを作ります=）。通常、長くプレイすればするほど、上手くなります。
デザインパターンを学ぶことは、プログラムを構築するための良い方法を学ぶことです。あなたは本質的に何十年も物事を構築してきた人々からのアドバイスを読んでいます。彼らは、最も一般的な解決策を、覚えやすい名前のシンプルで消化しやすい知識にまとめました。それはデジタル時代の見習いのようなものです：あなたの年長者はあなたに彼らの最高のアドバイスを与えています。あなたはそれを取り、ゲームの先を行くか、それを無視して彼らの過ちをすべて繰り返すことができます。
デザインパターンとOOPは別々に扱われるのはなぜですか？それらは異なる主題であるためです。次に、プログラミングについて考える方法を学びます。逆の場合はいいのですが、息を止めていません。
デザインパターンを知っている人は必ずOOPエキスパートですか？いいえ。
デザインパターンはOOP原則の拡張ではありませんか？これら2つの概念が別々に扱われるのはなぜですか？
「デザインパターン」は、主に歴史的な事故によるOOPの原則です。
MLハッカーは、GoFの本よりずっと前に、代数的データ型の折り畳みについて話していたと確信しています。これは、一般的な問題に対する実証済みの解決策です。代数的データ型の内容に基づいて単一の値を計算する必要があります。同様にmapについても、私は考えています。
ソリューションテンプレートを見つけて体系化する一般的な（メタ？）プラクティスはかなり古いと思います---それは本質的に「ベストプラクティス」のすべてではありませんか？
DPとOOPが別々に扱われる理由は、重複しているものの、OOPベストプラクティスは=と関係があると思うからです。 OOP原則---ある程度の独立性があります。オブジェクト指向以外の設定でデザインパターンについて話すのは理にかなっています。
デザインパターンとオブジェクト指向プログラミングは必然的に関連していません。たまたま、多くのデザインパターンがオブジェクト指向プログラミングに関係しています。
デザインパターンは、プログラム作成に一般的に使用されるアプローチです。フィールドの共通パターン言語を見つけるアプローチは、関数型プログラミングやブリッジ構築に拡張することも、アーキテクチャーでそれが始まった場所に到達することもできます。 OOは特定の概念パラダイムであり、いくつかのプログラミングパターンが適合します。
状況はベン図のようなものです-アプローチは反対ではありませんが、それらは同一ではなく、多少異なる動作をします論理レベル。
デザインパターンブックを手に取って、紹介を読むべきだと思います。デザインパターンとは何かを理解したら、この質問に答えてもらいます。
オブジェクト指向プログラミングはそれ自体がデザインパターンです。
デザインパターンは、OOPプログラミングで発生する問題を解決するための一般的なアプローチです。デザインパターンについて知っていると、状況にアプローチする方法を決定するときに時間を節約できます。
一部のデザインパターンでは、 Visitor Pattern など、他の方法では不可能または複雑なことを実行できます。これにより、クラスのセットが新しい機能を取得できます。変化の知識。通常のOOP手法を使用して、各クラスが実装するインターフェイスまたは仮想メソッドを作成します。これは、OOP に反します。オープン/クローズド原則 。
デザインパターンを知っている人は専門家だとは言いませんがOOP.
プログラマーは、Javaおよび.NETフレームワークで広く使用されているため、パターンを学習することなく常にパターンを使用します。ほとんどのJava IO名前空間は、 デコレータパターン を利用するクラスで構成されています。それを知っていても、=の専門家になることはほとんどありません。 OOPしかし、それは物事を理解するのに役立ちます。
実際、デザインパターンとOOPは、実際には互いに関係がありません。名前が示すように、デザインを実装するためのパターン（または「レシピ」）です。は、実際に使用するすべての言語の「デザインパターン」ですが、Gang ofFourの本がOOデザインパターンに焦点を当てていることがあります。
OOデザインパターンの知識は前向きな指標になる可能性がありますが、誰かにインタビューするとき（または専門知識のレベルを測定しようとするとき）、私は彼らが精通しているパターンの複雑さを調べます。また、パターンをいつ/どこで使用するかについての十分な知識もあります。開発者が「ゴールデンハンマー」のようなパターンを利用して、必ずしも適用できるとは限らない場所で使用するのを見てきました。
したがって、レシピ本がマスターシェフにならないように、OOデザインパターンの知識は、必ずしも1人をOOエキスパートにするわけではありません。
OOP原則は、優れたプログラムを作成するためにデザインパターンを適用できるツールのセットだと思います。
デザインパターンはOOP原則の拡張ではありません：答えはNOであるべきだと思います
デザインパターンとOOPが別々に扱われるのはなぜですか？
OOPの原則-は、実際には、クラス（ビジネスオブジェクトの技術的表現）を設計/定義するときに従う必要のある制約/主題についてです。クラスの動作方法..何他のクラスの依存関係を削除して機能させるためのアクションを実行する必要があります..そしてさらにいくつか..これはSOLIDの原則としてよく知られています
これに気付いていない人のために、SOLIDは、オブジェクト指向設計の最初の5つの原則の頭字語です。
- 単一責任の原則
- オープンクローズド原則
- リスコフの置換原則
- インターフェイス分離の原則
- 依存性逆転の原則
ここで、デザインパターン-は、アプリケーションでコーディング標準を定義/維持する方法についてです。アプリケーションの実行フローを標準的な方法で単純化する方法..簡単にメンテナンスできます..
以下の例では、1つのデザインパターンが定義されています。これは、すべての開発者がオブジェクトを作成する方法に関するものです。
//Register
builder.RegisterType<ConsoleOutput>().As<IOutput>();
builder.RegisterType<TodayWriter>().As<IDateWriter>();
Container = builder.Build();
//Create instance
var writer1 = Container.Resolve<IOutput>();
writer1.Write("HelloWorld");
var writer2 = Container.Resolve<IDateWriter>();
writer2.WriteDate();
アーキテクトは、すべての開発者mustがクラスの最上位にインターフェイスを作成するデザインパターンを作成したいと考えています。インスタンスを作成するには、インターフェイスとクラスをファクトリに登録する必要があります。 ..アーキテクトは、登録されているクラス（ビジネスオブジェクト）の数や、単一のモジュールを完了するために作成されたオブジェクトの数などの統計レポートを必要としているため（今すぐ簡単に実現できますファクトリの「RegisterType」および「Resolve」機能の中にいくつかのコードを配置することによって）..
したがって、デザインパターンとOOPが
very different aspectであることが明らかになったかもしれません。
デザインパターンを知っている人が間違いなくOOPエキスパート？-そうなると期待されているとしたら...しかし必須ではありません!!
オブジェクト指向プログラミングは、コードをオブジェクトおよびオブジェクトの関係に編成するプログラミング方法論またはプログラミングの概念です。デザインパターンは、プログラム内の特定のシナリオを解決するためにタイプ/オブジェクトを構築するための実証済みの成功した方法を提案します。
これは限定的な定義です。