Jak wyrobić sobie podejście obiektowe do tworzonych pomysłów (dziedziczenie,polimorfizm)

1

Do tej pory myślałam,że jako tako ogarniam tworzenie i projektowanie aplikacji obiektowych,ale się myliłam.

W jaki sposób najlepiej wyrobić sobie podejście obiektowe do aplikacji.Załóżmy,że mamy kółko i krzyzyk. W jaki sposob zaprojektowac ta gre ? Czy kolko i krzyzyk sa oddzielnymi obiektami odziedziczonym od klasy plansza ? Czy plansza,kolko i krzyzyk sa 3 roznymi obiektami ? Czym jest menu gry - osobnym obiektem ? A moze wszystko jest jednym obiektem ?

Pisze obecnie kalkulator i myślałam,ze np. takie wyswietlanie historii operacji moze byc rozszerzeniem funkcjonalnosci a zatem obiektem dziedziczacym po klasie kalkulator.Jak zatem traktowac dziedziczenie w konteksie mozliwosci rozbudowy programu o dodatkowe funkcje ?

3
Quanti994 napisał(a):

Czy kolko i krzyzyk sa oddzielnymi obiektami odziedziczonym od klasy plansza ?

Przenigdy tak się nie dziedziczy. Krzyżyk nie JEST Planszą (owo JEST jest ważnym wskaźnikiem czy dziedziczenie jest poprawne. A w dodatku może być teoretycznie poprawne, ale nieużyteczne, nieoptymalne itd)
Koszyk jabłek i pomarańcz nie JEST jabłkiem. A przykład stwierdzenia poprawnego: Jabłko JEST Owocem.

BTW A jak nie zasymilujesz odróznienia klasa i obiekt, będzie cięzko to chwytać intuicyjnie i poprawnie

Czy plansza,kolko i krzyzyk sa 3 roznymi obiektami ? Czym jest menu gry - osobnym obiektem ? A moze wszystko jest jednym obiektem ?

W jakimś sensie (np przez kompozycję 3-4 poziomową) wszystko jest obiektem klasy Gra

Ciężko książkę napisać w formie postu. Niech koledzy zaproponują DOBRĄ książkę/kurs (bo złych jest dużo)

0

Ujmuję to sobie tak, że były dwie fale programowania obiektowego.

  • Pierwsza ujmowała "rzeczownik - obiekt (klasa)" i "czasownik - metoda", plus moda na intensywne dziedziczenie. Do dziś trwa w edukacji, ale jak się przesadzi, prowadzi na manowce.
  • Druga (aktualna): Ograniczenie dziedziczenia na rzecz np kompozycji, ale najbardziej odświeżające szerokie przyjęcie "rzeczowników odczasownikowych" jak (interfejs) DawanieGłosu implementowany przez Szczekanie, Miauczenie. Czy całkiem prozaicznie Nasłuchiwanie (Listener)

Ważnym elementem "drugiej fali" jest interfejs. Określa on jakiś aspekt, ale nie pretenduje do narzucania definicji całego obiektu (a tym by była klasa). Na przykład inaczej zapisany w/w DającyGłos, UmiejącyPływać, PosiadającySkrzydła.
Z tego można poskładać zwierzę (klasę) które daje głos i ma skrzydła.

(Wyjadacze - zgodzicie się?)

1

Tworzenie poprawnie zaprojektowanych klas wraz z ich wzajemnymi relacjami jest zadaniem wymagającym dużego doświadczenia. Przed tobą jeszcze długa droga, gdzie na własnej skórze przekonasz się jak zła architektura może rozłożyć na łopatki cały twój projekt.
IMHO w zdobywaniu tego doświadczenia bardzo pomocne może okazać się znajomość wzorców projektowych ( zobacz ), oraz przede wszystkim tworzenie własnych obiektowych aplikacji. I nie przejmuj się, że będą one pełne błędów, gdyż każdy musi je popełnić aby przejść na następny poziom zrozumienia.

1

Kod który piszemy powinien odzwierciedlać/modelować rzeczywistość.
Czy kolko i krzyzyk sa oddzielnymi obiektami odziedziczonym od klasy plansza? Zapomnij o programowaniu, zadaj sobie to pytanie, czy kółko albo krzyżyk to plansza? Jaka jest odpowiedź na to pytanie? Plansza może za to zawierać kółko oraz krzyżyk

Mówiąc bardzo ogólnie dziedziczenia używamy gdy obiekty potomne mają relację IS np. Cat IS Animal, Dog IS Animal więc można tutaj zastosować dziedziczenie. Jak koledzy wspomnieli taka abstrakcja też nie zawsze jest ~optymalna.

2
lubie_programowac napisał(a):

Kod który piszemy powinien odzwierciedlać/modelować rzeczywistość.

To jest tylko slogan, który jest bardzo szkodliwy. Sam go sobie powtarzałem jak miałem mało doświadczenia.
polecam obejrzeć w całości.

0
MarekR22 napisał(a):
lubie_programowac napisał(a):

Kod który piszemy powinien odzwierciedlać/modelować rzeczywistość.

To jest tylko slogan, który jest bardzo szkodliwy. Sam go sobie powtarzałem jak miałem mało doświadczenia.
polecam obejrzeć w całości.

Nadal uważam że nasz kod powinien modelować rzeczywistość. Oprócz tego mam również zasadę kompozycja ponad dziedziczenie, DRY, KISS, SOLID, konwencja ponad konfiguracja, nie tworzyć bytów ponad stan, rozwiązanie powinno być tak proste jak to możliwe ale nie prostsze. Uncle Bob poruszył inną kwestię: zbudowanie wspólnej nomenklatury / żargonu pomiędzy biznesem a developerami oraz byciu agile a nie wdrażaniu agile. Wchodzimy tutaj w kwestie DDD. U mnie w kodzie odpowiedzialności są jasno podzielone: część kodu jest stricte związane z architekturą / frameworkami a część stricte z domeną. Ja piszę w androidzie - może tutaj prościej utrzymać wszystko w garści.

"To jest tylko slogan, który jest bardzo szkodliwy. Sam go sobie powtarzałem jak miałem mało doświadczenia." co mamy innego do zaoferowania? Wykorzystywać wszędzie Map<Object,Object> i robić instance of? Modelowanie rzeczywistości jest ważne, dzięki temu zdecydowanie prościej zrozumieć kod. Oczywiście przerost formy nad treścią albo robienie abstrakcji bo kiedyś to się przyda nie jest dobrze widziane.

//Edit: Ten temat nie jest wyczerpany, do tego dochodzą jeszcze optymalizacje wielowymiarowe, malejący wzrostt(diminishing return), second / third order thinking, automatyzacja, OKR, KPI, tworzenie strategii rozwoju aplikacji, zarządzanie ryzykiem, przesuwanie całego developmentu w kierunku zapewnienia niezawodności...

1 użytkowników online, w tym zalogowanych: 0, gości: 1