web-dev-qa-db-ja.com

OOP設計パターンが標準ライブラリに含まれていないのはなぜですか？

この他の質問に似た質問があります

言語パターンにデザインパターンが追加されないのはなぜですか？

なぜそこにないのですかJava.util.Singletonそして、それを継承しますか？ボイラープレートコードは常に同じようです。

class Singleton {
    private static final Singleton s = new Singleton();

    public static Singleton getInstance() {
        return s;
    }

    protected Singleton() {
    }
}

class XSingleton extends Singleton {

}

JavaにSingletonが組み込まれている場合、プロジェクトに同じボイラープレートを何度も含める必要はありません。コードを継承するだけです。これはシングルトンを作成し、XSingleton that extends Singleton。

同じことが他のデザインパターンにも当てはまると思います。 MVCなど。標準ライブラリに組み込まれるデザインパターンが増えないのはなぜですか？

javadesign-patternsobject-orienteddry
6
Niklas

基本的な前提、つまりデザインパターンが標準ライブラリに追加されていないということに挑戦したいと思います。例えば、 - Java.util.Iterator<E> は標準ライブラリにあり、 イテレータデザインパターン の実装です。 Java.util.Observable / Java.util.Observer は Publish/Subscribe Design Pattern の実装です。 Java.lang.reflect.Proxy は プロキシデザインパターン の実装です。

他の言語、例えばRubyには delegate および forwardable ライブラリがあり、どちらもプロキシデザインパターンの実装であり、 observer ライブラリ、パブリッシュ/サブスクライブパターンの実装、および singleton ライブラリ、- Singletonの実装デザインパターン 。

34
Jörg W Mittag

デザインパターンとは、クラスやライブラリに取り込むことができない定期的なデザインのことです。通常、それらは複数のクラスがどのように相互作用するかに関係しています。言語の標準ライブラリは、他のコードと同じようにパターンをuseできます。 Java IOライブラリはデコレータパターンを使用します。ただし、デコレータパターン自体を単一のクラスまたはライブラリでキャプチャすることはできません。

設計パターンの典型的な定義（Wikipediaから引用）：

ソフトウェアエンジニアリングでは、ソフトウェア設計パターンは、ソフトウェア設計の特定のコンテキスト内で一般的に発生する問題に対する一般的な再利用可能なソリューションです。 ソースコードまたはマシンコードに直接変換できる完成したデザインではありません。これは、さまざまな状況で使用できる問題を解決する方法の説明またはテンプレートです。

（私の強調）したがって、標準ライブラリは、通常のクラスを再利用可能なコンポーネントとして提供するのと同じように、定義上、再利用可能なコンポーネントとしてデザインパターンを提供できません。または別の言い方をすると、あるデザインパターンが再利用可能なコードでキャプチャできる場合、パターンと呼ぶのをやめます。 List<T>は広く役立つ設計ですが、これは再利用可能なクラスでキャプチャできるため、通常は「パターン」とは呼ばれず、単なるクラスです。

しかし、フレームワークは特定のデザインパターンの使用を奨励し、ある程度施行することができます。例えば。 MVCフレームワークでは、多かれ少なかれ、MVCパターンに従ってコードを記述する必要があります。

パターンによっては、パターンを再利用可能なクラスとしてキャプチャできない理由がいくつかあります。

  1. パターンが抽象的すぎます。例えば。 「アダプター」は、クラスが1つのインターフェースを別のインターフェースに変換するパターンです。概念はかなり単純ですが、実際の実装は、作動時の2つのインターフェースのセマンティクスに完全に依存します。アダプターパターンの異なるアプリケーション間で共有されるボイラープレートコードはないため、ライブラリの再利用可能なコンポーネントとして含めることはできません。

  2. このパターンは、再利用可能な形式で実装することはできません。一部のパターンは、言語の制限に対して実際に回避策です。例えば。 「Visitor」パターンは実際には、単一のディスパッチ言語が複数のディスパッチをサポートできるようにするハックです。ボイラープレートコードはいくつかありますが、ボイラープレートコードは再利用可能な方法で一般化することはできません。複数のディスパッチのサポートが組み込まれている言語では、そもそもビジターパターンは必要ありません。

    （そして、いくつかのコメントで指摘されているように、静的が継承されていないため、提供するシングルトン実装を再利用可能なクラスに一般化することはできません。）

23
JacquesB

「パターン」という言葉の微妙さがここで失われているのではないかと心配です。スーツを考えてください。パターンは機能を定義します-例えばポケット、腕、脚などがありますが、すべての詳細（ボタン、生地、裏地など）を定義するわけではありません。これは実装者に任されています。

はい、多くのデザインパターンには定型コードがあり、私たちの多くが使用する傾向がありますが、一般的に合意された方法なしでパターンを実現する方法は複数あります。

4
Robbie Dee

なぜJava.util.Singletonがないのですか？それを継承していますか？

シングルトンはstaticであり、staticメンバーで継承を使用できないためです。また、列挙型を使用してシングルトンを宣言することをお勧めします。

public enum MySingleton{
    INSTANCE;

    //class content goes below
}

また、enumがJava.lang.Enumを継承するため、継承をここで使用するのは難しく、変更することはできません。1行のボイラープレートコードを削除する方法はありません。

これがJava.util.Singletonが存在しない理由です。

言語構造にデザインパターンが追加されないのはなぜですか？

かなり多くのものがすでにjdk標準ライブラリにあります。たとえば、パターンを使用するときにいくつかのクラスがいくつかの機能を提供します。たとえば、Java.util.ObserverはObserverパターンを使用するときに実装され、他は次のように設計パターンを利用します。Java.lang.StringBuilder Builderパターンを利用します。

それらがすべて表示されない理由については、次のとおりです。

  • 一部のデザインパターンは、classes/interfaces/enums/ectで抽象化するのが困難です（たとえば、Java.util.Singleton）。
  • 標準ライブラリに入れる価値はありません。
  • まだ考えられていません。
  • 必要はありません。
2
Luke Melaia