Wpis z mikrobloga

@sarveniusz: Ten przykład z Githuba jest paskudny straszliwie. Klasa abstrakcyjna od razu z polami width i height. Szkoda, że koło też jest pochodną figury i wtedy te pola nie mają najmniejszego sensu (gdzie radius zamiast w/h?), a sposób stworzenia Shape chwilami wręcz zmusza do złamania LSP.

Dalej: pola obiektów pochodnych Shape powinny być tworzone przez konstruktor parametryczny, np. Rectangle(2, 3), Square(4), Disk(3) (sprawdziłem na wiki jak jest koło
@bolinoga

W jakim celu wydzielasz interfejs, który potem implementujesz/"dziedziczysz" w klasie abstrakcyjnej?


Ten interfejs oczywiście nie powinien być w klasie bazowej, jakoś chyba sie kierowałem tym przykładem, który wcześniej opisywałem i go tutaj wrzuciłem, za moment poprawię.

@alex-fortune masz na myśli to co wyżej opisałem czy coś innego?
@sarveniusz: Po prostu pozbądź się klasy abstrakcyjnej. Bardzo ważna zasada na równi z SOLID - composition over inheritance. Niezawodnym sposobem pisania jest tworzenie wpierw interfejsów, a następnie klas implementujących. W razie konieczności wraz z rozwojem projektu rozbijamy interfejsy na mniejsze, klasy podobnie rozbijamy na mniejsze, a następnie tworzymy kompozycję przez klasy agregujące które proxują calle w drzewie kompozycji.
@alex-fortune: jasne, właśnie to zrobiłem, ta klasa abstrakcyjna była bez sensu jak wyżej pisałem :)

Ten interfejs oczywiście nie powinien być w klasie bazowej, jakoś chyba sie kierowałem tym przykładem, który wcześniej opisywałem i go tutaj wrzuciłem, za moment poprawię.