2015-10-02 3 views
5

Ostatnio natknąłem się na wzór, który mnie intrygował.Logika wewnątrz BuilderPattern

Tak, mam EntityBuilder, który buduje Entity, ale nie zwraca encji. Oto podpis metoda:

public void build(); 

Zamiast wewnątrz metody build(), zapewnia nowy obiekt utworzony, tym Entity, do CacheImplementation przykład do zapisania. Uwaga: CacheImpl jest wstrzykiwany do konstruktora konstruktora.

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

Czy to brzmi jak najlepsza praktyka?

Później edit 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); 
    } 
} 

Budowniczy stosowany jest w następujący sposób:

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(); 
    } 
} 

Uwaga: instancja cacheImpl tylko przechowuje podmioty w List<> która uzyskuje dostęp do co n sekund.

Odpowiedz

2

Czy to brzmi jak najlepsza praktyka?

Tradycyjny wzorzec budowniczych nie przechowuje utworzonego obiektu w dowolnym miejscu, po prostu go zwraca.

Potrafię sobie wyobrazić odmianę, w której konstruktor również odgrywa rolę kontroli instancji, aby uniknąć tworzenia duplikatów obiektów i zarządzania magazynem niezmiennych obiektów.

Decyzja o nieprzyjęciu instancji może oznaczać, że metoda ma efekt uboczny. Jeśli metoda zwróciła obiekt, może wprowadzić w błąd myślenie, że jest to tradycyjny builder bez efektów ubocznych, kiedy nie ma to miejsca w tym przypadku.

W każdym razie jest to tylko spekulacja, ponieważ nie widzieliśmy reszty kodu, w którym jest używana oraz sposobu, w jaki jest ona wdrożona i używana. Nie mamy wystarczającego kontekstu, aby naprawdę osądzić. Nie ma nic złego w wymyślaniu nowych wzorów, ale można to zrobić dobrze lub źle.

+0

Wariacje tradycyjnych wzorów są przyjemne. Dodałem mały fragment kodu, aby zobaczyć, co mam na myśli. Czy wystarczy to osądzić? – VladLucian

+0

Nie, za mało. Bardziej interesującą częścią będzie użycie budowniczego i pamięci podręcznej. Przy okazji lista jako cache brzmi dziwnie. Spodziewałem się mapy. – janos

+0

To nie jest lista, jest to zestaw czyszczony w ciągu N sekund, za każdym razem, gdy rozpoczyna się przetwarzanie. Ponownie edytowałem sposób użycia budowniczego. – VladLucian

0

Widziałem podobną metodę void build() w klasie JCodeModel. Jak widać to rzuca IOException powodu resources it manages:

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

Zasadniczo prośbą o przeprowadzenie operacji dla Ciebie, a jeśli błąd nie występuje - można kontynuować pracy.

+0

@ To będzie miłe, jeśli usuniesz komentarz "dziękuję". Polityka witryny zawierająca pomocne odpowiedzi to ich głosowanie. Pozwala zachować czystość. Później usunę ten komentarz. – ekostadinov

0

Generalnie program budowniczy jest używany w następujący sposób: Niektóre klasy będą używać budowniczego do tworzenia klasy. Proste

enter image description here


Teraz masz dodatkowy kawałek złożoności - buforowania. Możesz umieścić buforowanie wewnątrz Buildera lub o jeden poziom wyżej w procesorze.

Jakie są konsekwencje wprowadzenia zarządzania cache wewnątrz konstruktora:

  • Builder nie ma już jednolitego odpowiedzialność.
  • To nie działa, jak można się spodziewać na pierwszy rzut oka
  • Jesteś w stanie utworzyć obiektu bez wkładania go do pamięci podręcznej

Te problemy nie wystąpią, jeśli umieścić zarządzanie cache do osobnej klasy.


Powiedziałbym, że to nie jest straszne rozwiązanie, ale z pewnością zmniejszy konserwowalność kodu.