デザインパターンはプログラミング言語から独立していますか？
私は最近Objective Cに取り組んでいて、Delegateパターンの使用に遭遇しました。
Head Firstの本のおかげで、理論的にはJavaで一般的なパターンのほとんどを見てきました。
しかし、時々、動的言語とスクリプト言語の違いを見ると、特定のデザインパターンの必要性について混乱します。
たとえば、アダプタパターンの例を見てみましょう。
オブジェクトアダプタ[Java]とクラスアダプタ[C++]の2つの実装がすでにあります。言語が多重継承をサポートしているかどうかによって異なります。
しかし、Objective-Cのような動的言語では、ダックタイピングが可能であり、オブジェクトが実際にメソッドをサポートしているかどうかを確認するためのrespondsToSelectorのようなメソッドもあります。では、デリゲートパターンを使用する必要がある場合でも、なぜここにプロトコルがあるのでしょうか。
動的言語で何かを何かと見なすことができる場合、いくつかのパターンを実装するために抽象クラスまたはインターフェースの概念が必要ですか？
それらは、動的に振る舞うための静的型付け言語のツールのように見えます。
特に、PHPでの抽象キーワードの必要性を理解していません。
誰かがいくつかの重要な詳細を指摘できますか、私はこれに比較的新しいです。
私があなたの質問を正しく理解しているなら、答えはこれに要約されます：
TLDR
Objective-Cのような動的言語で抽象クラスやインターフェース/プロトコルのようなものを使用する理由は、主にコードの単純さとクリーンさです。
長いバージョン
アヒルのタイピングと同じくらいクールですが、オブジェクトのタイプについて何も想定できない場合、それは実際には非常に面倒です。
コードのすべてのrespondsToSelector:行はそれを台無しにします。それはあなたが実際に利益をほとんどまたは全く達成しようと試みているものを難読化するノイズを追加します。
その上、それは たわごと-仕事 です。
したがって、より静的に型付けされたモデルを使用して、ダイナミズムを失うことによってAPIコントラクトを提供する場合、ほとんどの場合、それは勝利です。
- 複数の
respondsToSelector:メソッドを単一のconformsToProtocol:で置き換えることは成功です。 - プロトコル定義に必要なメソッドの簡潔で明確なリストがあることは勝利です。 （その定義を書くこと自体もたわごとですが、それはあなたが多くの場所でより多くのたわごとをすることを妨げるので、それは許容できます。）
- これに基づいて、これらのメソッドのいずれかの実装を省略した場合にコンパイラーに警告を表示させることは、大きなメリットです。
- そして：コンパイラが警告を発し、どこで混乱したかを教えてくれるので、
respondsToSelector:またはconformsToProtocol:メッセージを1つも書く必要がないことがすべての最大の勝利です。
実際の実装の共通の基盤を提供することでそれ以上のことができれば、抽象クラスを作成することはさらに大きなメリットになる可能性があります（おそらく、委任のコンテキストではそれほど有用ではありません...）—結局のところ、実装で自分自身を繰り返すことはすべての変更が物事の一貫性を維持するためのより多くのたわごとの仕事をもたらすので、たわごとの仕事の最悪のケース。
つまり、ダイナミズムはあらゆる種類の楽しいトリックを引き出すことができるため、クールで便利なものです。しかし実際には、（適切な場合に）その一部を取り除くことで、あなたの生活がはるかに楽になり、respondsToSelector:を書くようなたわごとをするのを防ぐことができます。
いいえ。これが、私が「デザインパターン」の本を大量のクラッドだと思う理由です。この本の論文は、自動化できないものがいくつかあるというものです。デザインパターンです。
たとえば、最も有名なビジターパターン.. err ..折りたたみの適切な言語で（C++ STLに蓄積）。
この本で実際に発見されているのは、デザインパターンではなく、言語の欠陥です。
パターンがある場合、それを自動化できるようにすることが言語設計者の目標です。ほとんどすべての型理論研究は、多形型システムをより表現力豊かにすることに集中しています。
特にプログラミングでは、猫の皮を剥ぐ方法が複数あることは誰もが知っています。最近の言語は最近非常に強力で柔軟性があり、場合によってはいくつかのパターンを回避する方法を提供します。
パターンとPHP他の多くのOO言語のabstractキーワードは構造と整合性に関するものです。abstractキーワードたとえば、拡張機能クラスの記述方法についてプログラマーに指示します。この例を見てください： http://php.net/manual/en/language.oop5.abstract.php#example-181
私が知っているすぐに：
AbstractClassを単独で使用することはできません。それを拡張する別のクラスを書く必要があります。- すでに
printOut()メソッドを使用できるので、書き直す必要はありません。 - 何をするにしても、自分で保護された
getValue()メソッドとprefixvalue($prefix)メソッドを作成する必要があります。 - これらの要件に準拠している限り、それが機能することはわかっています。他の誰かがこのクラスを拡張したいとき、彼らは何をすべきかを知っているでしょう。
はい。これが、デザインパターンの本が非常に重要である理由です。これらすべての本の論文は、自動化できないものがあるということです：良いデザイン。
この本で実際に発見されたのは、言語の欠陥とは何の関係もありませんが、優れたデザインのパターンです。それらのパターンのいくつかは、言語機能によって埋められます。それらのパターンのいくつかは、言語機能によって満たされていません。
優れたデザインは言語に依存しません。
異なるデザインパターンは無制限にあります。言語設計者は、それらすべてを予測したり埋めたりすることはできません。
では、デリゲートパターンを使用する必要がある場合でも、なぜここにプロトコルがあるのでしょうか。
プロトコルは優れたデザインパターンの言語実装だからです。
いくつかのパターンを実装するには、抽象クラスまたはインターフェイスの概念が必要ですか？
ダックタイプの言語であっても、正式な抽象クラスは常に役立ちます。
正式なインターフェイスは実装であり、一部の言語で使用されます。デザインパターン（ダックタイピング言語でも）はまだ存在します。
デザインパターンを見ることで得られる主なことは、他の人のデザインから学ぶことです。それらはすべての言語に適用できるわけではありませんが、それらを研究することで、以前に理解または知らなかったデザインについて学ぶことができます。もう1つの利点は、デザインに名前を付けたので、他の開発者と簡単にそれらについて話すことができることです。パターンが異なる言語で異なる方法で実装される場合でも、比較対照するためのツールを提供し、どの状況がどのデザインでうまく機能するか、そしておそらくもっと重要なことに、どのデザインがどの状況で機能しないかについての議論を提示します。