2012-03-16 13 views
6

Efektywne czytanie Javy, wydaje się, że istnieje wiele zalet i bardzo niewiele wad, aby użyć statycznych metod fabrycznych. Statycznych metod fabrycznych I specjalnie oznaczać następująceCzy zawsze powinienem używać statycznych metod fabrycznych zamiast konstruktorów?

public class MyClass {  
    private MyClass() { ... }; 

    public static MyClass getInstance() { 
    return new A(); 
    }  
} 

ze skutecznej Java:

pamiętać, że metoda statyczna fabryki nie jest taki sam, jak wzorzec Factory Method z Design Patterns [Gamma95, s. 107]. Statyczna metoda fabryczna opisana w tym punkcie nie ma bezpośredniego odpowiednika w Wzorcach projektu.

Czy najlepiej jest zawsze stosować się do tej praktyki, czy tylko czasami?

Jeśli tak, kiedy?

Czy kiedykolwiek jest to przesadą?

+1

To przesada, gdy jest przesada. Tylko ty możesz to osądzić. Generalnie, ostrzegłbym cię, byś nie ślepo podążał za * każdą * otrzymaną mądrością. Zazwyczaj odkrywa się, że wszystkie pierwotne kwalifikacje, z którymi chroniono pierwotne oświadczenie, zostają zapomniane, a jedynie zasada pozostaje, często nikt tak naprawdę nie wie, dlaczego. – EJP

+0

W tym przypadku mamy szczęście, ponieważ oryginalny tekst jest zachowywany w całej okazałości w Efektywnej Jawie, pozycja 1. Nie jestem jednak pewien, czy moja interpretacja jest prawidłowa. – cendrillon

+0

Powiedziałbym, że jest to generalnie przesada, chyba że masz konkretny powód, dla którego chcesz ukryć tworzony typ, który jest w zasadzie wtedy, gdy chcesz użyć wzoru fabrycznego. Sugeruję, że w większości przypadków tak nie jest. Zastanów się, jakie będzie życie, na przykład, jeśli nie możesz zbudować łańcucha lub nici. – EJP

Odpowiedz

5

Generalnie konstruktory są prostsze niż fabryki, więc jest to główny powód wyboru konstruktorów nad fabryką. Użyj Factory, gdy sytuacja go wzywa, nie "domyślnie". Powinieneś zrobić najprostszą rzecz, która rozwiązuje twój problem, a przez większość czasu będą to konstruktorzy.

+2

Podoba mi się twoje rozumowanie (brzytwa Ockhama), jednak zastanawiam się, czy sprawienie, by konstruktor nie stał się publicznie, mógł później wrócić do gryzienia. Po jego publicznym udostępnieniu nie można go już uczynić prywatnym bez ryzyka złamania istniejącego kodu, który wykorzystał konstruktora. Oznacza to, że późniejszy montaż statycznej metody fabrycznej może być bolesny. Sądzę też, że mogą istnieć również problemy z bezpieczeństwem wątków. Nie chcę kwestionować twojej odpowiedzi, ale zastanawiam się, czy jest coś więcej niż to? – cendrillon

+2

Jest to rodzaj obszaru oceny wyroku, ale powszechnym problemem jest to, że programiści często przeprojektowują swój kod. Chociaż prawdą jest, że powinieneś myśleć z wyprzedzeniem, powinieneś rozważyć _pewne, czy wymaga takiej zmiany. Następnie musisz wykonać wezwanie do sądu. Ogólnie rzecz biorąc, powiedziałbym, że prostsze jest lepsze. Jest to zasadniczo argument dla YAGNI: http://en.wikipedia.org/wiki/You_ain't_gonna_need_it – Oleksi

+1

To jest doskonały punkt. Zastanawiam się, jak zachować równowagę pomiędzy unikaniem overdesign z jednej strony a dobrymi enkapsulacją, czyli minimalizowaniem dostępności klas i członków? Oznacza to, że konstruktor zawsze może być upubliczniony, ale po publicznym musi być publiczny do końca czasu. – cendrillon

2

Podejście fabryczne polega na utworzeniu i usunięciu obiektów z kodu przy użyciu tego obiektu.

Jeśli wszystko zależy od złożoności procesu tworzenia i inicjalizacji obiektu. Jeśli są proste, to nie ma potrzeby używania wzoru fabrycznego.

Jeśli jest nieco skomplikowany (wymaga wielu kroków podczas inicjalizacji przed użyciem) i lepiej pasuje do wzoru fabrycznego.

Powiązane problemy