Serio aż tak "rygorystycznie" wygląda klasyczne, dobre podejście? 1. Szczerze, trochę nie rozumiem xD Czyli wg. tego nie możemy w ogóle sobie w zmiennej przechowywać pola instancji jakiejś klasy? 2. To akurat rozumiem, czyli np klasy konkretne Car extends Vehicle extends BaseObject są bez sensu, bo Vehicle i BaseObject powinny być abstrakcyjne i nie jest to potrzebne żeby tworzyć ich instancje. 3. Hmm.. czyli override jakiegoś konstruktora, afterFind, czy afterSave (wraz z returnem metody klasy bazowej) jest zły? To patrząc powyżej jest trochę bez sensu, bo dziedzicząc z BaseObject albo ActiveRecord całkiem co innego może dotyczyć logika klasy Car a całkiem co innego jakiś User.
@rzrbld: przesada. Każda klasa implementuje swój własny interfejs. Jak taki sam interfejs jest używane przez wiele klas to ma sens wyciągnięcie zewnętrznego interfejsu ale taki interfejs dla interfejsu to przesada (i ciężko wymyślić czemuś takiemu nazwę). Wyjątkiem są biblioteki, bo tam nie masz możliwości na wyciągnięcie interfejsu kiedy chcesz (bo kompatybilność)
@rzrbld: ktoś się tu trochę zagalopował, bo pierwszy podpunkt - jak najbardziej, ale dwa pozostałe? Dependency inversion ma służyć separacji warstw / modułów, ale już w ramach tej samej warstwy / modułu nie ma żadnych przeciwwskazań żeby np. klasy od UI wzajemnie po sobie dziedziczyły czy overridowały swoje metody
ale taki interfejs dla interfejsu to przesada
@Saly: to opieranie się na abstrakcjach to nie jest sztuka dla sztuki, tylko pisanie
@mag_zbc: chodzi mi o to, żeby nie robić interfejsu po to, bo "żadna zmienna nie powinna zawierać referencji do konkretnej klasy" . Javowy string implementuje CharSet, bo ma to sens. Natomiast interfejs IString, która miałaby te same metody co String byłby tylko nadgorliwością
ktoś się tu trochę zagalopował, bo pierwszy podpunkt - jak najbardziej, ale dwa pozostałe?
Pierwszy podpunkt akurat jest najbardziej bez sensu.
Przede wszystkim ktoś kto to pisał nie za bardzo zdawał sobie sprawę, że to jest takie coś za coś, taki trejdof. Interfejsy stosuje się w celu rozluźnienia wiązania między komponentami. A luźne wiązanie nie zawsze jest dobre.
Luźne wiązanie ma pewne zalety np. umożliwia większą elastyczność w kwestii rozbudowy
Serio aż tak "rygorystycznie" wygląda klasyczne, dobre podejście?
1. Szczerze, trochę nie rozumiem xD Czyli wg. tego nie możemy w ogóle sobie w zmiennej przechowywać pola instancji jakiejś klasy?
2. To akurat rozumiem, czyli np klasy konkretne Car extends Vehicle extends BaseObject są bez sensu, bo Vehicle i BaseObject powinny być abstrakcyjne i nie jest to potrzebne żeby tworzyć ich instancje.
3. Hmm.. czyli override jakiegoś konstruktora, afterFind, czy afterSave (wraz z returnem metody klasy bazowej) jest zły? To patrząc powyżej jest trochę bez sensu, bo dziedzicząc z BaseObject albo ActiveRecord całkiem co innego może dotyczyć logika klasy Car a całkiem co innego jakiś User.
#naukaprogramowania #programowanie
źródło: comment_1648729963BixO6haWFDVtMHtJZhWmw5.jpg
Pobierz@rzrbld: to takie trudne? Stosuje to z powodzeniem i nie wiem jakbym mockował gdybym tego nie stosował.
@Saly: to opieranie się na abstrakcjach to nie jest sztuka dla sztuki, tylko pisanie
CharSet, bo ma to sens. Natomiast interfejsIString, która miałaby te same metody coStringbyłby tylko nadgorliwościąPierwszy podpunkt akurat jest najbardziej bez sensu.
Przede wszystkim ktoś kto to pisał nie za bardzo zdawał sobie sprawę, że to jest takie coś za coś, taki trejdof.
Interfejsy stosuje się w celu rozluźnienia wiązania między komponentami. A luźne wiązanie nie zawsze jest dobre.
Luźne wiązanie ma pewne zalety np. umożliwia większą elastyczność w kwestii rozbudowy