Model prostej aplikacji, podstawy OOP

Witam, chcę napisać prostą aplikacje konsolową (sklep) gdzie są użytkownik i administrator. Chciałbym by ktoś sprawdził czy to ma sens jeśli chodzi o OOP.

Główną klasą w tym systemie jest Konto. Jest to klasa abstrakcyjna z której dziedziczą klasy Użytkownik i Administrator. Klasa Konto posiada konstruktor, który dziedziczą (i rozszerzają o własne pola) klasy potomne i metodę abstrakcyjną loguj( gdyż inaczej loguje się użytkownik a inaczej admin ). Użytkownik ma metody kupowania i płacenia a Admin to dodawanie/usuwanie konta. Klasa Program w której wybiera się konto admina lub usera i konstrukcja switch jako menu do zarządzania danym kontem.

Pomijając fakt ze taki konsolowy sklep nie sensu to czy jest to poprawne z punktu widzenia programowania obiektowego? Czy można inaczej rozłożyć klasy( konto, user, admin, może jakieś inne? ) i zastosować dziedziczenie by nie powielać kodu i korzystać z OOP?

Artur Adamowski napisał(a):

Klasa Konto posiada konstruktor, który dziedziczą (i rozszerzają o własne pola) klasy potomne i metodę abstrakcyjną loguj( gdyż inaczej loguje się użytkownik a inaczej admin ).

Ta część budzi u mnie wątpliwości. Nie wiem, czy klasa Konto jest właściwym miejscem, żeby umieszczać w nim mechanikę logowania. Czy to jest zgodne z zasadą pojedynczej odpowiedzialności i open-closed principle?

Od tej pory:

• jeśli mechanika logowania się zmienia (np. oprócz hasła można się zalogować odciskiem palca), prawdopodobnie musimy zmienić i klasę Użytkownik, i Administrator.
• to oznacza, że są już dwa możliwe powody, dla których musielibyśmy zmienić klasę Użytkownik. Rozbudowa czy modyfikacja danych przechowywanych dla samego Użytkownika (np. dodanie pola e-mail), oraz jakaś modyfikacja procesu logowania.

Może logowaniem powinien się zajmować jakiś Autentykator? Może to "stanie na bramce" to jest odrębna odpowiedzialność?

Food for thought, jak mawiają Angole. Dwie kwestie do wzięcia pod uwagę:

• Zasady OOD to tylko zbiór wytycznych i przeważnie nie jest tak, że istnieje jedna prawidłowa architektura / design
• W przypadku małych, ćwiczebnych przykładów tworzenie nadmiaru klas prowadzi do przeinżynierowania w stosunku do rozmiarów przykładu. Zawsze trzeba tu godzić dwie sprzeczne wartości: z jednej strony chodzi o zademonstrowanie pewnych zasad, a z drugiej mały rozmiar projektu nakazywałby inżynierskie uproszczenia.

@V-2
Dzięki, wiele mi to wyjaśnia.

Ta aplikacja to tylko dla mnie przykład działania podstawowych mechanizmów OOP.

Lepiej zrób "na pałę" taką apkę, bez po szanowania OOP, wszystko proceduralnie jak chcesz, albo wal byle jak klasy. Albo na zasadzie eksperymentów "pierdyknę tutaj dziedziczenie, bo dziedziczenia jeszcze nie stosowałem" (nie jest to szlachetny sposób programowania, ale bardziej realistyczny bo twój post to też w sumie taka zabawa, eksploracja tego czym jest OOP, ubrana w jakiś ładnie brzmiący bullshit poprawne z punktu widzenia programowania obiektowego czy inne bajeczki)

Popracuj nad nią parę dni (albo tygodni), zacznij rozbudować i dodawaj do niej sztucznie dodatkowe "wymagania biznesowe", np. co jeśli użytkownik będzie chciał się logować w inny sposób, np. przez Facebooka? Albo co jeśli użytkownikiem może być równocześnie administratorem? A co jeśli administrator administratorowi nie będzie równy itp. (np. no bo jeden admin może mieć inne uprawnienia niż drugi admin. Swoją drogą dlatego to, jak chcesz to zrobić, że admin = oddzielna klasa, się rozleci szybko, bo jest to dość naiwne patrząc na realia)

Wtedy dopiero zobaczysz, na jakie realne problemy możesz natrafić przy takiej aplikacji.

I dopiero wtedy jest czas na przepisanie apki od nowa, już z myślą o tym, żeby to napisać ładnie.

Jak nie napisałeś takiej apki brzydko i bez OOP (albo z brzydkim OOP), to nie napiszesz ładnie w OOP. Swoją drogą OOP nie mówi wcale o tym, jak zrobić logowanie użytkownika, bo OOP to ogólne zasady, a pytasz o konkretne recepty dot. konkretnych zastosowań OOP przy apkach biznesowej.

To też dobre wskazówki. Dodałbym, że warto od razu próbować pisać testy jednostkowe. To się wiąże z dobrym OOP. Jedną z przewag kodu obiektowego nad proceduralnym jest właśnie lepsza testowalność. Jeśli trudno jest napisać testy, to jest dobry wczesny znak ostrzegawczy, że z naszymi obiektami jest coś nie tak (może robią za dużo, może ukrywają jakieś sztywne zależności etc.).

No dobra, tylko jak ktoś nie umie jeszcze za bardzo programować, to testów też nie będzie umiał pisać.

Stopniowo niech się uczy jednego i drugiego... pisanie prostych testów nie wymaga chyba jakiejś znacząco więcej wiedzy, niż pisanie prostych programów. Zrozumieć, co to asercje, i można klepać. Kolega OP jest, przypuszczam, ambitny, skoro o porady techniczne rozpytuje się na forum, zamiast zrobić fuszerę i odhaczyć temat.

@LukeJL
Z tą zabawą to racja. Staram się do tego podchodzić eksperymentalnie ("na wyczucie"). Na początek to chyba jedyna droga, a później inżynieria oprogramowania :D

@V-2
Jeśli chodzi o testy to jak najbardziej warto spróbować.

Gdybyś miał z tym problemy, dawaj na forum.

Znaczy problem w sensie praktycznym, a nie że burzysz się o tę sugestię