Obecnie stworzyłem klasę ABCFactory, która ma jedną metodę tworzenia obiektów ABC. Teraz, gdy o tym myślę, może zamiast mieć fabrykę, mógłbym zrobić statyczną metodę w mojej metodzie ABC. Co to jest pro i con's w dokonywaniu tej zmiany? Czy nie doprowadzi do tego samego? Nie przewiduję, że inne klasy odziedziczą ABC, ale nigdy nie wiadomo!W jakich przypadkach użyteczne są klasy fabryczne zamiast funkcji statycznych?
Dzięki
W rzeczywistości, jeśli chcesz uzyskać korzyści z klasy fabrycznej, potrzebujesz statycznej metody w swojej klasie. Umożliwi to później tworzenie nowych klas fabrycznych lub rekonfigurowanie istniejącego, aby uzyskać różne zachowania. Na przykład jedna klasa fabryczna może tworzyć jednorożce, które implementują interfejs IFourHoovedAnimal. Możesz mieć napisany algorytm, który robi rzeczy z IFourHoovedAnimal i musi je utworzyć. Później możesz utworzyć nową klasę fabryczną, która zamiast tego tworzy instancje Pegasusa, które również implementują IFourHoovedAnimal. Stary algorytm można teraz ponownie wykorzystać dla Pegaza za pomocą nowej fabryki! Aby było to możliwe, zarówno PegasusFactory, jak i UnicornFactory muszą dziedziczyć po wspólnej klasie bazowej (zazwyczaj klasie abstrakcyjnej).
Widzisz, umieszczając metodę statyczną w jej własnej klasie fabrycznej, możesz zamienić klasy fabryczne na nowsze, aby ponownie użyć starych algorytmów. Działa to również w celu poprawy testowalności, ponieważ teraz testy jednostkowe mogą być karmione fabryką, która tworzy symulowane obiekty.
Zrobiłem to wcześniej (statyczna metoda fabryczna dla klasy, w której tworzysz instancje) dla bardzo małych projektów, ale tylko dlatego, że potrzebowałem go, aby pomóc w refaktoryzacji starego kodu, ale zachowaj zmiany do minimum . Zasadniczo w tym przypadku wyodrębniłem fragment kodu, który utworzył grupę kontrolek ASP.NET, i wprowadził wszystkie te kontrolki do formantu użytkownika. Chciałem, aby moja własność nowej kontroli użytkownika była oparta, ale starszemu starszemu kodowi łatwiej było stworzyć kontrolę użytkownika za pomocą konstruktora opartego na parametrach.
Tak więc stworzyłem statyczną metodę fabryczną, która pobierała wszystkie parametry, a następnie zainicjowała kontrolę użytkownika i ustawiła jego właściwości na podstawie parametrów. Stary kod starszego typu użył tej statycznej metody do utworzenia kontroli użytkownika, a przyszły kod użyłby zamiast tego "ładniejszych" właściwości.
Dla konkretnych klas, metod fabryczne są naprawdę tylko sposób pośredni wokół tworzenia rzeczywistego typu (co nie znaczy, że nie są użyteczne, ale jak już znajdziesz, metoda fabryki może naprawdę być w dowolnym miejscu).
Tam, gdzie metoda fabryczna naprawdę świeci, jest to, kiedy twoja metoda tworzy instancje typu interfejsu.
Posiadanie pojedynczej, statycznej metody sprawia, że testowanie jest o wiele trudniejsze, a posiadanie obiektu, który jest dostępny, pozwala na łatwiejsze sprawdzenie. Ponadto, wtrysk zależności jest później bardziej opcją z rozwiązaniem niestatycznym.
Oczywiście, jeśli nie potrzebujesz tego, to nie są to dobre argumenty.
Główną zaletą metody fabryki jest możliwość ukrycia odniesienia do konkretnej klasy za interfejsem. Ponieważ metody statyczne nie mogą być częścią interfejsu, statyczne metody fabryczne są zasadniczo takie same jak sama metoda konstruktora. Jedynym użytecznym zastosowaniem metod statycznych w fabrykach jest zapewnienie dostępu do prywatnego konstruktora - co jest powszechnie stosowane w implementacji singleton-pattern.
+1 Krótki i wyraźny. –
"D" w Uncle Bob's SOLID Principles of Object Oriented Design to "Zależność od inwersji zależności" Zależy od abstrakcji, a nie od konkrecji.
Ekstremalne podążanie za tą zasadą może spowodować, że twoja główna klasa stworzy wszystkie swoje fabryki, a każda fabryka będzie korzystała z innych fabryk za pośrednictwem interfejsów. Jedyny wygląd "nowego" (tworzenie konkretnych obiektów) byłby w twojej głównej klasie i twoich fabrykach. Wszystkie twoje obiekty działałyby z interfejsami (abstrakcjami), z konkretnymi zależnościami uzyskanymi z dostarczonych implementacji fabrycznych.
Następnie można bardzo łatwo dostosować lub zapewnić wiele klas głównych dostosowanych do różnych scenariuszy.
Nadużywanie wzorców projektowych jest niebezpieczne, a twórcze wzorce projektowe mają sens, gdy masz hierarchie klas ze zdefiniowanymi interfejsami lub potrzebujesz zbudować złożone obiekty. Jeśli masz prosty projekt, użyj prostych rozwiązań. Dlatego też, w przypadku, Factory Method wystarczyłoby
Tak, masz rację, to jest inny wzorzec projektowy :)
Dlaczego jest to łatwiejsze do testowania z metodą non-statycznej? –
@ elwizowane elysium: na przykład klasa testowa może zawierać podklasę oryginału, która przesłoniła metodę, dla instrumentacji lub zwarcia normalnego zachowania. To nie jest (łatwo) możliwe dzięki statycznej metodzie. –
@ vvoured elysium - Ponieważ nie można przekazać klasy statycznej jako parametru do metod testowych (przynajmniej nie za dobrze). Jest to związane z drugim punktem dotyczącym iniekcji zależności. Ale, jak powiedział Jaxidian, te punkty mogą nie być ważne. –