Konstruktory a metody fabryczne [zamknięte]

Jaki jest preferowany sposób inicjowania klas podczas modelowania klas:

1. Konstruktory lub
2. Metody fabryczne

A jakie byłyby względy korzystania z jednego z nich?

W niektórych sytuacjach wolę metodę fabryczną, która zwraca null, jeśli obiektu nie można zbudować. To czyni kod porządnym. Mogę po prostu sprawdzić, czy zwrócona wartość nie jest pusta przed podjęciem alternatywnej akcji, w przeciwieństwie do zgłoszenia wyjątku od konstruktora. (Osobiście nie lubię wyjątków)

Powiedzmy, że mam konstruktor klasy, który oczekuje wartości id. Konstruktor używa tej wartości do wypełnienia klasy z bazy danych. W przypadku, gdy rekord o podanym identyfikatorze nie istnieje, konstruktor zgłasza wyjątek RecordNotFoundException. W takim przypadku będę musiał zawrzeć konstrukcję wszystkich takich klas w bloku try..catch.

W przeciwieństwie do tego mogę zastosować statyczną metodę fabryczną na tych klasach, które zwrócą null, jeśli rekord nie zostanie znaleziony.

Które podejście jest lepsze w tym przypadku, w przypadku metody konstruktora lub fabryki?

Od strony 108 Wzorów projektowych: elementy oprogramowania obiektowego wielokrotnego użytku Gamma, Helm, Johnson i Vlissides.

Kiedy używasz wzorca metody fabrycznej

• klasa nie może przewidzieć klasy obiektów, które musi stworzyć
• klasa chce, aby jej podklasy określały obiekty, które tworzy
• klasy przekazują odpowiedzialność do jednej z kilku podklas pomocniczych, a Ty chcesz zlokalizować wiedzę, której podklasy pomocniczej jest delegowany

Zapytaj siebie, czym one są i dlaczego je mamy. Oba są po to, aby utworzyć instancję obiektu.

ElementarySchool school = new ElementarySchool();
ElementarySchool school = SchoolFactory.Construct(); // new ElementarySchool() inside

Jak dotąd bez różnicy. Teraz wyobraźmy sobie, że mamy różne typy szkół i chcemy przejść z używania ElementarySchool na HighSchool (która pochodzi z ElementarySchool lub implementuje ten sam interfejs ISchool co ElementarySchool). Zmiana kodu wyglądałaby następująco:

HighSchool school = new HighSchool();
HighSchool school = SchoolFactory.Construct(); // new HighSchool() inside

W przypadku interfejsu mielibyśmy:

ISchool school = new HighSchool();
ISchool school = SchoolFactory.Construct(); // new HighSchool() inside

Teraz, jeśli masz ten kod w wielu miejscach, możesz zobaczyć, że użycie metody fabrycznej może być dość tanie, ponieważ po zmianie metody fabrycznej jest to gotowe (jeśli użyjemy drugiego przykładu z interfejsami).

I to jest główna różnica i przewaga. Gdy zaczniesz zajmować się złożonymi hierarchiami klas i chcesz dynamicznie utworzyć instancję klasy z takiej hierarchii, otrzymasz następujący kod. Metody fabryczne mogą następnie przyjąć parametr, który mówi metodzie, jaką konkretną instancję należy utworzyć. Załóżmy, że masz klasę MyStudent i musisz utworzyć instancję odpowiedniego obiektu ISchool, aby Twój uczeń był członkiem tej szkoły.

ISchool school = SchoolFactory.ConstructForStudent(myStudent);

Teraz masz w aplikacji jedno miejsce, które zawiera logikę biznesową, która określa, który obiekt ISchool ma zostać utworzony dla różnych obiektów IStudent.

Tak więc - dla prostych klas (obiektów wartości itp.) Konstruktor jest w porządku (nie chcesz przeceniać swojej aplikacji), ale w przypadku złożonych hierarchii klas preferowaną metodą jest metoda fabryczna.

W ten sposób postępujesz zgodnie z pierwszą zasadą projektowania od grupy czterech książek „Program do interfejsu, a nie implementacja”.

Musisz przeczytać (jeśli masz dostęp) Efektywna Java 2 pozycja 1: Rozważ statyczne metody fabryczne zamiast konstruktorów .

Zalety statycznych metod fabrycznych:

1. Mają imiona.
2. Nie są wymagane do tworzenia nowego obiektu przy każdym wywołaniu.
3. Mogą zwrócić obiekt dowolnego podtypu swojego typu zwrotu.
4. Ograniczają gadatliwość tworzenia instancji sparametryzowanych.

Wady statycznych metod fabrycznych:

1. Udostępniając tylko statyczne metody fabryczne, klasy bez konstruktorów publicznych lub chronionych nie mogą być podklasowane.
2. Nie można ich łatwo odróżnić od innych metod statycznych

Domyślnie preferowane są konstruktory, ponieważ są łatwiejsze do zrozumienia i napisania. Jeśli jednak chcesz oddzielić subtelności konstrukcyjne obiektu od jego semantycznego znaczenia w rozumieniu kodu klienta, lepiej skorzystaj z fabryk.

Różnica między konstruktorami a fabrykami jest analogiczna do, powiedzmy, zmiennej i wskaźnika do zmiennej. Istnieje inny poziom pośredni, co jest wadą; ale jest też inny poziom elastyczności, co jest zaletą. Dokonując wyboru, dobrze byłoby dokonać analizy kosztów w porównaniu do korzyści.

Używaj fabryki tylko wtedy, gdy potrzebujesz dodatkowej kontroli przy tworzeniu obiektów, w sposób niemożliwy do osiągnięcia w przypadku konstruktorów.

Fabryki mają na przykład możliwość buforowania.

Innym sposobem korzystania z fabryk jest scenariusz, w którym nie znasz typu, który chcesz zbudować. Często ten typ użycia występuje w scenariuszach fabryk wtyczek, w których każda wtyczka musi pochodzić z klasy podstawowej lub implementować jakiś interfejs. Fabryka tworzy instancje klas, które wywodzą się z klasy podstawowej lub implementują interfejs.

Cytat z „Effective Java”, wyd. 2, poz. 1: Rozważ statyczne metody fabryczne zamiast konstruktorów, str. 5:

„Zauważ, że statyczna metoda fabryczna nie jest taka sama jak wzorzec metody fabrycznej z wzorców projektowych [Gamma95, s. 107]. Statyczna metoda fabryczna opisana w tym punkcie nie ma bezpośredniego odpowiednika we wzorach projektowych”.

Oprócz „skutecznej javy” (jak wspomniano w innej odpowiedzi) inna klasyczna książka sugeruje również:

Preferuj statyczne metody fabryczne (z nazwami opisującymi argumenty) od przeciążonych konstruktorów.

Na przykład. nie pisz

Complex complex = new Complex(23.0);

ale zamiast tego pisz

Complex complex = Complex.fromRealNumber(23.0);

Książka posuwa się tak daleko, że sugeruje uczynienie Complex(float)konstruktora prywatnym, aby zmusić użytkownika do wywołania metody fabryki statycznej.

Konkretny przykład z aplikacji CAD / CAM.

Ścieżkę cięcia wykonano by przy użyciu konstruktora. Jest to szereg linii i łuków określających ścieżkę do wycięcia. Chociaż seria linii i łuków może być różna i mieć różne współrzędne, łatwo ją obsłużyć, przekazując listę do konstruktora.

Kształt zostałby wykonany przy użyciu fabryki. Ponieważ podczas gdy istnieje klasa kształtu, każdy kształt będzie konfigurowany inaczej w zależności od typu kształtu. Nie wiemy, jaki kształt będziemy inicjalizować, dopóki użytkownik nie dokona wyboru.

Powiedzmy, że mam konstruktor klasy, który oczekuje wartości id. Konstruktor używa tej wartości do wypełnienia klasy z bazy danych.

Ten proces zdecydowanie powinien znajdować się poza konstruktorem.

1. Konstruktor nie powinien uzyskiwać dostępu do bazy danych.

2. Zadaniem i powodem dla konstruktora jest inicjalizacja elementów danych i ustanowienie niezmiennika klasy za pomocą wartości przekazanych do konstruktora.

3. W przypadku wszystkiego innego lepszym podejściem jest zastosowanie statycznej metody fabrycznej lub w bardziej złożonych przypadkach oddzielnej klasy fabryki lub producenta .

Niektóre linie przewodnika konstruktora od Microsoft :

Wykonuj minimalną pracę w konstruktorze. Konstruktory nie powinny wykonywać dużo pracy poza przechwytywaniem parametrów konstruktora. Koszt jakiegokolwiek innego przetwarzania należy opóźnić do momentu, gdy będzie wymagany.

I

Rozważ zastosowanie statycznej metody fabrycznej zamiast konstruktora, jeśli semantyka żądanej operacji nie jest odwzorowana bezpośrednio na konstrukcję nowej instancji.

Czasami musisz sprawdzić / obliczyć niektóre wartości / warunki podczas tworzenia obiektu. A jeśli może rzucić wyjątek - konstrukcja jest bardzo zła. Musisz więc zrobić coś takiego:

var value = new Instance(1, 2).init()
public function init() {
    try {
        doSome()
    }
    catch (e) {
        soAnotherSome()
    }
}

Gdzie wszystkie dodatkowe obliczenia są w init (). Ale tylko Ty jako programista naprawdę wiesz o tej init (). I oczywiście po miesiącach po prostu o tym zapominasz. Ale jeśli masz fabrykę - po prostu zrób wszystko, czego potrzebujesz w jednej metodzie, ukrywając tę ​​init () przed bezpośrednim wywołaniem - więc nie ma problemów. Dzięki takiemu podejściu nie ma problemów z upadkiem na tworzenie i wyciek pamięci.

Ktoś powiedział ci o buforowaniu. To jest dobre. Ale musisz również pamiętać o wzorze Flyweight, który jest przyjemny w użyciu w stylu Factory.