![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 260 Pomógł: 14 Dołączył: 8.09.2011 Ostrzeżenie: (0%) ![]() ![]() |
Pytanie do mądrzejszych ode mnie forumowiczów.
Mam klase np. abstractMessage która jest szkieletem zapisujacym message do bazy danych. następne z klasy abstractMessage tworze klasy pochodne np SMSMessage, EmailMessage. Rodzaj wiadomosci przechowuje w polu $type obiektu abstractMessage, dzieki czemu wiadomo czy to SMSMessage, i EmailMessage. Potrzebuje wzorca fabryki (metody wytwórczej?), tylko poprawnego. Teraz bym to zrobił tak:
jednak takie rozwiązanie jest podobno do kitu ponieważ w przypadku jeżeli powstaną nowe typy dziedziczące po abstractMessage to będe musiał zmodyfikować ten switch tworzący obiekty, a w ten sposob zlamie zasade otwarte-zamknięte - zamiast rozszerzać klasę dodajac metody modyfikuję istniejący kod w celu rozszerzenia funkcjonalności. No a jeżeli nie utworze odpowiedniego typu (SMSMessage, EmailMessage) to nie będę mógł użyć ich specyficznych metod. Więc jak to poprawnie rozwiązać? Chcę rozwiązania na maksa poprawnego z dobrymi praktykami programistycznymi, bo już dostałem niedawno durszlakiem pełnym kodu spagetti mocno w głowę i chcę tego uniknąć (IMG:style_emoticons/default/smile.gif) |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 64 Pomógł: 6 Dołączył: 20.03.2011 Skąd: Świdnica Ostrzeżenie: (0%) ![]() ![]() |
Zawsze musi istnieć informacja o tym jaka klasa ma być użyta. To wiadome. Teraz od nas zależy kiedy tą informacje wykorzystamy - czy na poziomie kontrolera i tu:
Kod class Controller { $CommunicatorWithClients = new $NameFromPost(); $CommunicatorWithClients->sendMessage(); } czy na poziomie fabryki, czy innego sposobu jak odrębnej klasy która wybiera nam klasę do zbudowania obiektu na zasadzie strategii. Temat o tyle śliski, że dosyć niejednoznaczny - który sposób wybrać. Sam zawsze mam z tym problemy ale tylko dlatego, że myślę o elastyczności zbyt wcześnie. Zależy to od innych rzeczy, które znajdują się w kodzie. Jeśli wiesz, że będziesz rozszerzać klasę komunikacji dobrze użyć Strategii w tym przypadku jak na moje oko ;-). W switchach nie ma nic złego dopóki nie zaczynają nam przeszkadzać. Dwa case'y w switch to nie tragedia, ja bym sie tym narazie nie przejmował. Nazwij tego switch'a jako funkcje TwinPeaks() i już ;-) . Pozdrawiam. Ten post edytował LSM 11.12.2011, 20:00:00 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 13.10.2025 - 23:11 |