Mam problms ze wzorem obserwatora. Mówi, że Observer i Subject powinny być interfejsami. Rozumiem, dlaczego obserwatorzy są interfejsami, ale dlaczego nie lepiej jest, aby przedmiot był klasą abstrakcyjną? Czy nie możesz już w najmniejszym stopniu wdrożyć/usunąć?Observer Pattern abstract vs interface
Wzory projektowania mają być dostosowane do konkretnych potrzeb aplikacji; nie określają zasad ustanowionych w kamieniu. W szczególności, czy coś jest klasą abstrakcyjną lub interfejs jest do podjęcia decyzji, biorąc pod uwagę wszystkie konsekwencje decyzji dla reszty aplikacji.
To powiedziawszy, interfejsy są zalecane w stosunku do klas abstrakcyjnych w ogóle z kilku powodów. Na przykład klasy abstrakcyjne wymagają dziedziczenia, a w wielu językach nie można dziedziczyć z więcej niż jednej klasy. Jeśli nie jest to problemem w twoim przypadku użycia, skorzystaj z klas abstrakcyjnych, jeśli uznasz je za wygodniejsze.
Dlaczego po prostu nie ma klasy abstrakcyjnej, która implementuje temat? Korzystanie z interfejsu zapewnia większą elastyczność. To naprawdę nic nie kupi, aby zacząć od klasy abstrakcyjnej. Jeśli wszystko zmieni się bardzo dużo (na przykład przekraczanie granic procesu), wtedy obserwowalne utknie w abstrakcyjnej implementacji.
okay thank u wszystkich facetów, że pomogło :) – Maximosaic
dlaczego nie jest to lepiej mieć pacjentowi klasy abstrakcyjnej
Aby uniknąć związania projekt do konkretnego wdrożenia betonu. Pamiętaj, że celem jest stworzenie schematu, który da ci elastyczność w zamianowaniu konkretnych tematów w zależności od potrzeb i nie będzie wiązać obserwatorów z żadną oryginalną implementacją.
Nie chcesz obserwatorzy odwołać FirstConcreteSubject, ale raczej interfejs ISubject, które szybko można zmienić na realizowane przez SecondConcreteSubject bez konieczności modyfikowania obserwatorów.
Powiedział, że nie ma nic złego (IMHP) z posiadaniem BaseSubject klasy abstrakcyjnej przechowywać niektóre z kodu, który byłby inaczej powielane przez FirstConcreteSubject i SecondConcreteSubject.
W przypadku wzorca projektowego, gdy używany jest interfejs słowny, oznacza on abstrakcyjny interfejs API, który jest narażony na działanie składnika klienta, który będzie miał różne implementacje.
Gdy interfejs wzorca projektowego jest mapowany do świata Java, może to być interfejs Java lub klasa abstrakcyjna Java, a także mapy klas konkretnych wzorów do klas regularnych Java (nie abstrakcyjnych).
Jednak przy podejmowaniu decyzji trzeba zrozumieć różnicę między interfejsem Java a klasą abstrakcyjną i ich przeznaczeniem, a także zalety i wady.
Patrz: Interface Vs Abstract Class
Pod wieloma względami idealny wzór byłoby mieć klasę abstrakcyjną, która implementuje interfejs, ale nie określają żadnych miejsc składowania abstrakcyjny typ klasy - zawsze korzystaj z interfejsu. Pozwoliłoby to klasom, które mogą pochodzić z typu abstrakcyjnego, po prostu odziedziczyć użyteczny kod, podczas gdy te, które muszą pochodzić z innych typów, mogły zaimportować jakikolwiek wspólny kod jako szablonowy. Podejście to jednak nie udaje się, jeśli niektórzy konsumenci tego typu używają typu abstrakcyjnego, a nie typu interfejsu, nawet jeśli nie powinno to być konieczne, o ile klasy nie potrzebują dostępu do danych prywatnych innych instancji. – supercat