私がファクトリを読んでいる間、ヘッドファーストデザインパターンブックにファクトリデザインパターンを抽象化します。フレーズについて言及しました。
それを明確にするための基本的な例と説明をお願いします。
私がファクトリを読んでいる間、ヘッドファーストデザインパターンブックにファクトリデザインパターンを抽象化します。フレーズについて言及しました。
それを明確にするための基本的な例と説明をお願いします。
依存性逆転の原則; 5つのオブジェクト指向設計原則の1つ。この質問への回答を確認してください。「依存性逆転の原則とは何ですか?なぜそれが重要なのですか?」-そこには本当に良い情報がいくつかあります。
従来のアプリケーションアーキテクチャでは、低レベルのコンポーネントは高レベルのコンポーネントによって消費されるように設計されているため、ますます複雑になるシステムを構築できます。この構成では、高レベルのコンポーネントは、いくつかのタスクを実行するために低レベルのコンポーネントに直接依存しています。この低レベルのコンポーネントへの依存は、高レベルのコンポーネントの再利用の機会を制限します。
「簡単な」用語では、これは、オブジェクトの具体的なインスタンスに依存する場合、つまり、コードへの依存関係を構築している場合(その意図はありませんが)、それを再利用する機能を制限することを意味します。
具象型はインスタンス化できるクラスの型であり、抽象型はインスタンス化できない型であることを忘れないでください。つまり、インターフェース。(クラスの分類法を参照してください)
特定の具象クラスにコーディングする場合は、常にそのクラスの要件があります。ただし、インターフェース(抽象化)にコーディングする場合は、任意の数のクラスで機能するようにコードを適合させることができます。それらがその共通のインターフェースを実装している限り。
つまり、Javaでは、可能な場合はインターフェイスにコーディングする必要があり、コードを特定の項目に依存させないようにする必要があります。Interface
これは多くの場合、型をパラメータや戻り型として渡すのと同じくらい簡単です。具体的なクラスとは対照的に。
依存関係が少ない=コードを再利用する能力が高い。より多くの依存関係=コードを再利用できるようにするためのより多くの要件。
これは、デザインパターンを勉強しているときに繰り返し発生するテーマになります。
ウィキペディアの依存性逆転の原則。
工場は仮想コンストラクターだからです。これらは、実行時にさまざまなタイプを返す機能を提供します。工場は多型に依存しています。
具象型を返すとそんなことはできません。
public interface IFoo {
void execute();
}
public class Bar implements IFoo {
public void execute() { System.out.println("Bar does one thing"); }
}
public class Baz implements IFoo {
public void execute() { System.out.println("Baz does another"); }
}
public class FooFactory {
private static final FooFactory instance = new FooFactory();
private FooFactory() {}
public static final FooFactory getInstance() { return instance; }
public IFoo create(Class clazz) {
return clazz.newInstance();
}
}
Bar
createメソッドからaを返す場合、aBaz
は不可能であり、その逆も同様であることは明らかです。インターフェースが鍵となります。
抽象化によっては、クラス間の結合を緩めるのに役立つ場合があります。それが提案されている理由です。Animal
クラスの例を考えてみてください。その定義で多くの抽象化を維持できる場合は、やなどのより具体的なクラスを定義するときに、より弾力性がDog
ありBird
ます。Dog
内部の具体的な機能を配置すると、 extendingAnimal
を書き込もうとすると競合が発生します。したがって、常にクラス階層の上位レベルに物事を抽象化します。Bird
Animal