非OOP設計パターン？[閉まっている]

70

オブジェクト指向コードに使用される「デザインパターン」という用語を聞いたことがあるだけで、GoFパターンにはOOPデザインパターンのみが含まれていますが、デザインパターンは一般的に発生するプログラミング問題のエレガントなソリューションです。OOPに限定する必要があると言っていることは何もありませんが、ありますか？

オブジェクト指向プログラミングの領域外のデザインパターンの例をいくつか見たいと思います。あなたがいずれかを持っている？そのようなものさえ存在しますか（GoF本のような本は、必ずしも書かれている必要はなく、単に使用されるべきです;それで十分です）？

それらは特定のプログラミング言語に固有のものである場合がありますが、オブジェクト指向以外のパラダイムの一般的な（パラダイムレベル）パターンが優先されます。

design-patterns 
— アント
ソース
8
人気のあるデザインパターンブックが行った最大の不利益は、パターンがオブジェクト指向言語にのみ適用されると信じる多くの人々を作成したことだと思います。創造的なパターンは議論の余地がありますが、他のほとんどすべてのオブジェクト指向言語で常に実装可能であり、実装されています。この副作用は著者の意図ではなく、それでも副作用であると確信しています。
— ペムダス
14
さて、オブジェクトは非OO言語のデザインパターンです:)
— back2dos
1
さらに悪いことに、パターンブックは、特定のパターン（通常は同じことを信じている学校の先生が教えた最後のパターン）を適用することですべての問題を解決する必要があると考える人々のクラス全体を作成しました。
— 14年

回答:

25

Linux Kernel Design Patternsシリーズをご覧ください。記事は非オブジェクト指向言語（C）に関連しており、よく書かれていると思います。

— サヤスク
ソース
ただし、オブジェクト指向のアプローチを使用しています。
— カイス
12

実際、それはパラドックスです。最も一般的な非オブジェクト指向パターンの1つは、「クラス」です。

OOは非OO言語で発明されたため、開発者はそれをシミュレートする必要がありました（そして、彼らは今でもそれをやっています）-パターンが生まれました。LISPとCはこの例です。

しかし、私のアドバイスをしてください。よくある間違いをしないでください-クールだからといってパターンを使用しないでください。

たとえば、コマンドパターンを考えてみましょう。これは便利ですが、呼び出し側と受信側を切り離していますが、実際に必要な場合以外は使用しないでください。操作は動詞を使用して表現する必要があるためです。そして、コマンドをすべての場所で完全に分散されたOO-lambdaで終わることになります->同じことが多くの戦略に当てはまります。

— カミル・トムシク
ソース
11

「デザインパターン」は、実際には「回避策」のe曲表現です。デザインパターンはOO言語の欠点と欠陥を回避するために発明されました。たとえば、最終的にJavaでコレクションを導入するイテレータパターンを考えてみましょう。Groovyは、言語機能に変換することでさらに多くのパターンを取り除きました。Groovyの既存のクラスにメソッドを追加できるため、デコレーターパターンは不要になりました。

これは、どこでもデザインパターンを見つけることができることを意味します。実際、すべての「ベストプラクティス」は、設計パターンの単純な形式と見なすことができます。

— アーロン・ディグラ
ソース
9
同意した！Paul Grahamから：「たとえば、オブジェクト指向の世界では、「パターン」についてよく耳にします。[...]私のプログラムでパターンを見たとき、それは問題の兆候だと思います。プログラムの形は反映すべきですコードのその他の規則性は、少なくとも私にとっては、十分に強力ではない抽象化を使用していることを示すサインです。多くの場合、いくつかのマクロの拡張を手作業で生成しています私が書く必要があります。」
— アンドレスF.
7
回避策であるデザインパターンには同意しません。2つは正反対です。回避策は、特定の障害を回避するためにまとめられた短期パッチです。デザインパターンは、長期的に再利用可能なソリューションです。デコレータパターンの目的は、クラスを変更せずに機能的に「追加」することです。オブジェクトが知らないうちに、オブジェクトに異なるデコレータを配置できます。
— デスペルター
パターンが「回避策」と見なされる理由は、オブジェクトの装飾が言語の機能であるべきだからです。代わりに、これを実装するために、非常に多くのコード行を記述する必要があります。例として、反復子パターンは多くの現代言語の一部になっています。古いオブジェクト指向言語の場合、それらをシミュレートするためにいくつかのフープをジャンプする必要があります。
— アーロンディグラ
@AaronDigullaデコレータのようなパターンがそんなに重い実装だと思う理由がわかりません。あなたは数行のコードについて話しています。クラスには別のクラスが含まれており、機能を追加してリクエストを転送します。オブジェクト自体を呼び出すのと同じように、装飾されたオブジェクトを呼び出すように、継承と構成を使用します。この透明性は強みだと思います。これにより、実行時にデコレータを交換できます。groovyは、クラスにメソッドを追加できるため、デコレータを必要としないと言うと、ポイントが足りないように聞こえます。
— デスペルター
2
Iteratorパターンは、現代言語の新しい言語機能に置き換えられていません。一般的なコレクションのデフォルトの実装が付属しています。デフォルトの実装があるからといって、パターンが使用されていないという意味ではありません。独自のコレクションを作成する場合は、自分でコレクションを実装する必要があります。
— デスペルター
10

LtUは、Jeremy Gibbonsが関数型プログラミングのパターンに関する本を書いていると述べています。いくつかのティーザーについては、Gibbonの関数型プログラミングブログのパターンをご覧ください。彼は自分の投稿を古いものから新しいものへと読むことを推奨していることに注意してください。

彼の論文Design Patterns as Higher-Order Datatype-Generic Programs（pdf）は、Gang of Fourパターンを機能的にモデル化しています：Composite、Iterator、Visitor、およびBuilder。彼は、Origami Programming（folds and unfolds）で再帰方程式を使ってプログラミングのパターンを説明しています。

— コービンマーチ
ソース
7

OO以外のデザインパターンに名前を付ける代わりに、多くのデザインパターンを持つ書籍の例をいくつか紹介します（これらのパターンの中には、OO固有のものもあります）。

お役に立てれば

— キースダイク
ソース
これらは、私がお勧めするものに加えて、Hohpe＆Woolfのエンタープライズ統合パターンです。
— TMN
ファウラーのパターンは非常にオブジェクト指向です:)
— デビッドコンデ
@David Conde :)それらのほとんどは純粋なオブジェクト指向であり、すべてオブジェクト指向で記述されていますが、一部はオブジェクト指向以外にも適用されます。「Webプレゼンテーションパターン」、「セッション状態パターン」、「分散パターン"
— -KeesDijk
0

キュー、リンクリスト、ツリー、グラフなどのデータ構造をパターンとして考えるのが好きです。データを保存して処理する特定のパターンを定義します。Gang of Fourのよりハイエンドのパターンと比較すると、それらは原始的に見えるかもしれませんが、それでもパターンです。つまり、誰かがLIFOではなくFIFOとしてスタックを実装し、キューに対してその逆を行い、それ以外の名前を付けた場合はどうなりますか？

— DPD
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.