Jak wyrobic dobre nawyki obiektowe

pytanie zadane 8 sierpnia 2018 w Java przez pomaraqcz Początkujący (380 p.)

Dzień dobry,

Prosiłbym o poradę w kwestii programowania obiektowego. mam wrażenie, że cały czas mam problem z myśleniem obiektowym, najlepiej wytłumaczę to na przykładzie.

W ramach ćwiczeń postanowiłem napisać sobie program do kontrolowania wydatków. Będę wpisywać jaki produkt kupiłem, w jakiej jest kategorii,cenę i datę żeby potem móc przeanalizować wydatki z jakiegoś okresu, np. sprawdzić ile pieniędzy i na co wydałem w ostatnim tygodniu w kategorii "rozrywka". Na razie idzie mi "dość sprawnie" (to znaczy kod jest zapewne cały czas słabej jakości ale na ten moment program powoli zaczyna robić to co ma robic) ale tu pojawia się mój problem. Mam tendencje do pisania wszystkiego w jednej klasie. Wszystkie dotychczasowo napisane metody jak dodajZakupy(), podzielNaKategorie(), podliczWydatki() itp itd. trzymam w jednej klasie KontrolaWydatkow. Nie wiem kiedy i jak podzielić swój projekt na kilka mniejszych klas, bardziej "intuicyjne" wydaje mi się pisanie w jednej kiedy mam też tylko jedną instancję jednej klasy, co jednak jest raczej sprzeczne z ideą pisania obiektowo. Ma ktoś może jakieś wskazówki czym się kierować, na co zwracać uwagę żeby mieć intuicję kiedy "porzucić" klasę A i zacząć pisać już klasę B? A może pisanie czasem w jednej klasie nie jest wcale grzechem?

1 odpowiedź

odpowiedź 8 sierpnia 2018 przez miro Pasjonat (23,870 p.)
edycja 8 sierpnia 2018 przez miro

Polecam rzetelnie (co tak naprawdę oznaczają i jakie problemy rozwiązują) zapoznać się z zasadami SOLID i wzorcami projektowymi. Znalazłbyś w ten sposób sens programowania obiektowego i kilka odpowiedzi na Twoje pytania:

Ma ktoś może jakieś wskazówki czym się kierować, na co zwracać uwagę żeby mieć intuicję kiedy "porzucić" klasę A i zacząć pisać już klasę B?

Single responsibility principle (Zasada jednej odpowiedzialności)
Klasa powinna mieć tylko jedną odpowiedzialność (nigdy nie powinien istnieć więcej niż jeden powód do modyfikacji klasy).

dodajZakupy(), podzielNaKategorie(), podliczWydatki() - Te wszystkie metody prawdopodobnie powinny być w oddzielnych klasach.

Na początku nauki OOP wydaje się być przerostem formy nad treścią. Jednak jak zapoznasz się z dependency injection, interfejsami, testowaniem przy użyciu mocków, wszystko nabierze sensu.

Taka porada, abyś też nie używał na siłę dziedziczenia np. kwadrat nie powinien dziedziczyć po prostokącie.

2	komentarz 8 sierpnia 2018 przez Comandeer Guru (601,110 p.) Taka porada abyś też na siłę, używaj dziedziczenia Chyba powinno być "nie używaj na siłę dziedziczenia". Od siebie dorzucę https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design

komentarz 8 sierpnia 2018 przez miro Pasjonat (23,870 p.)

Dzięki, już poprawione.

komentarz 8 sierpnia 2018 przez pomaraqcz Początkujący (380 p.)

@miro,

Dziękuję wam obu za odpowiedzi, właśnie czytam czym jest SOLID i mam szybkie pytanie,

Jeżeli dobrze to sobie tłumaczę to w moim przypadku lepiej byłoby stworzyć np interfejs "Wydatki" gdzie zdefiniowane będą wszystkie metody a potem stworzyć klasy implementujące ten interfejs, gdzie jedna klasa będzie odpowiadała jednej mechanice którą chce dodać?

Powinno wyjść coś mnie więcej podobne do : Wydatki dodajZakup=new DodajZakup(); Wydatki podliczWydtki=new PodliczWydatki(); itd?

komentarz 8 sierpnia 2018 przez Ehlert Ekspert (212,670 p.)

Nie zmieniaj każdej metody na obiekt, bo to bez sensu. Użyj tych metod, ale w odpowiednich klasach.

Co do interfejsów to chyba źle zrozumiałeś ich funkcję. Interfejs daje Ci możliwość użycia zachowania jakiegoś obiektu bez znajomości jego typu. Dzięki temu korzystając z interfejsu SendableMessageInterface interesuje Cię tylko że ma on metodę send. A pod tym interfejsem może być każdy obiekt na swój sposób realizujący wysyłanie. Massenger, gołąb, poczta polska.

komentarz 9 sierpnia 2018 przez miro Pasjonat (23,870 p.)
edycja 9 sierpnia 2018 przez miro

Tak jak Ehlert napisał, nie zmieniaj metod na klasy, a przenieś metody wraz z zmiennymi na który one operują. Metody dodajZakupy(), podzielNaKategorie(), podliczWydatki() mógłbyś przenieść odpowiednio do klas: Koszyk, Kategorie, Wydatki i stworzyć ewentualnie klasę Klient w której to mógłbyś wszystko inicjalizować. Tutaj masz przykład

Na tej samej stronie masz opisany wzorzec strategii, który mógłbyś wykorzystać, aby poćwiczyć interfejsy. Załóżmy, że będziesz chciał obliczać wydatki na różne sposoby, z vatem i bez lub dodać inne w przyszłości. Robisz sobie WydatkiInterfejs z metodą podliczWydatki() i klasy WydatkiZVat i WydatkiBezVat implementujący ten interfejs.

Tworząc obiekt Wydatki wydatki = new WydatkiZVat(); (lub inicjalizować przez konstruktor ) ustalasz jak będą liczone wydatki. Od tej pory nie musisz martwić się jakim sposobem liczysz wydatki po prostu wywołujesz wydatki.podliczWydatki();. Co najlepsze to możesz w łatwy sposób zmieniać wydatkowanie przez metodę np.

setWydatki(WydatkiInterfejs wydatki) {this.wydatki =  wydatki;}

Nie wiem jak Twój program ma wyglądać i w czym to piszesz dlatego nie robiłem implementacji i przykłady mogą być nie trafione. Jeszcze jedna uwaga, pisz kod po angielsku.

komentarz 9 sierpnia 2018 przez Wiciorny Ekspert (270,110 p.)

Ciesze się, że ktoś wreszcie porusza temat " NIE UŻYWANIA DZIEDZICZENIA" :)

feralna sprawa -> kompozycja jest zdecydowanie lepsza, a z dziedziczeniem bym przy dużych projektach bardzo uważał