2015-10-02 10 views
5

最近、私は興味をそそるビルダーのパターンを見つけました。BuilderPattern内のロジック

したがってEntityを作成しますが、エンティティを返さないEntityBuilderがあります。

public void build(); 

は代わりに、build()方法内側、それを格納するCacheImplementationインスタンスに、作成した新しいオブジェクト、Entityを提供し:ここでメソッドのシグネチャです。 注:CacheImplは、ビルダーのコンストラクターに注入されます。

public void build(){ 
    //create new entity 
    cacheImplementation.add(entity); 
} 

これはベストプラクティスのように聞こえますか?

その後編集0

public interface EntityBuilder { 

    void setProperty0(PropertyObject propertyObject0); 
    void setProperty1(PropertyObject propertyObject1); 
    void setProperty2(PropertyObject propertyObject2); 
    //... 

    void build(); 
} 

public class EntityBuilderImpl implements EntityBuilder { 

    PropertyObject propertyObject0; 
    PropertyObject propertyObject1; 
    PropertyObject propertyObject2; 
    //... 

    // setters for all properties 
    @Override 
    public void build(){ 
     //create new entity 
     cacheImplementation.add(entity); 
    } 
} 

ビルダーは、次のように使用します。

public class EntityProcessor{ 
    private EntityBuilderFactory entityBuilderFactory;//initialized in constructor 

    void process(EntityDetails entityDetails){ 
     EntityBuilder entityBuilder = this.entityBuilderFactory.getNewEntitytBuilder(); 
     //.. 
     // entityBuilder.set all properties from entityDetails 
     entityBuilder.build(); 
    } 
} 

注:CacheImplでインスタンスだけN秒ごとにアクセスしているList<>内のエンティティを格納します。

答えて

2

これはベストプラクティスのように聞こえますか?

伝統的なビルダーパターンは、作成されたオブジェクトをどこにも格納しません。単純にそれを返します。

ビルダーがインスタンス制御の役割を持っていて、重複したオブジェクトを作成したり、不変オブジェクトのストアを管理したりすることを避けることができます。

インスタンスを返さないという決定は、メソッドに副作用があることを明確にすることです。このメソッドがオブジェクトを返した場合、それは副作用のない伝統的なビルダーだと思うと誤解するかもしれません。

いずれにせよ、これはすべて、このコードが使用されているコードの残りの部分、および実装され使用されている方法を見ていないため、投機的です。私たちは本当に判断するのに十分な文脈がありません。 新しいパターンの発明には何も問題はありませんが、それはうまくやっていくことができます。

+0

伝統的なデザインパターンのバリエーションは素晴らしいと思います。私は何を意味しているかを見るために小さなコードスニペットを追加しました。これは裁判に十分ですか? – VladLucian

+0

いいえ、十分ではありません。より興味深い部分は、ビルダーとキャッシュの使用です。キャッシュとしてのリストが奇妙に聞こえます。私は地図を期待していた。 – janos

+0

これはリストではなく、処理が開始されるたびにN秒でクリアされるSetです。ビルダーの使い方をもう一度編集しました。 – VladLucian

0

私はJCodeModelクラスで同様のvoid build()メソッドを見ました。あなたが見ることができるようにそれがあるためresources it managesIOExceptionをスロー:

public void build(File destDir, 
        PrintStream status) 
      throws IOException 

あなたは基本的にあなたのための操作を行うためにそれを尋ねると、エラーが存在しない場合 - あなたはワークフローを続行することができます。

+0

@Vlad「感謝」のコメントを削除するといいでしょう。有益な回答のサイトポリシーは、それらを投票しています。清潔に保ちます。私は後でこのコメントを削除します。 – ekostadinov

0

一般的に、ビルダーは次の方法で使用されます。 クラスによっては、クラスを作成するためにBuilderが使用されることがあります。キャッシング - シンプル

enter image description here


は今、あなたは複雑さの追加部分を持っています。 Builder内でキャッシュすることも、プロセッサ内部で1つ上のレベルにキャッシュすることもできます。

  • ビルダーはもう一つの責任を持ちません。

    ビルダー内のキャッシュ管理を置くことの意味は何ですか。

  • それはあなたが一目見ただけで期待どのように動作しません
  • あなたはキャッシュ

あなたが別のクラスにキャッシュ管理を置く場合、これらの問題は発生しませんにそれを入れずにオブジェクトを作成することはできません。


私はそれがひどい解決策ではないと言いますが、あなたのコードの保守性を確実に低下させます。