Projekt programowanie obiektowe

0

Witam. Mam na uczelni w ciągu miesiąca do zrobienia projekt z programowania obiektowego w c++. Nie ukrywam - jestem mocno zielony jeżeli chodzi o paradygmaty programowania obiektowego, i tak naprawdę będę się uczył tworząc ten projekt.
Najpierw jednak muszę wybrać sobie temat - by nie rzucać się od razu na głęboką wodę, myślałem o prostym programie "katalogu zwierząt" w ZOO. Co by w nim było? Na początek logowanie lub rejestracja (loginy i hasła przechowywane w pliku tekstowym), następnie w zależności czy jesteśmy:

  • zwykłym użytkownikiem - możliwość wyszukiwania zwierząt według ich "systematyki" - ssaki, które potem by się dzieliły na drapieżne, gryzonie i tak dalej, płazy, gady... Ogólnie wiadomo o co chodzi ;) A także oczywiście możliwość wyszukiwania według konkretnej nazwy gatunku. Każde zwierze miałoby swoje cechy indywidualne takie jak wiek, waga czy imię ;)
  • administratorem -to co zwykły użytkownik + możliwość usuwania/dodawania zwierząt z katalogu, a także możliwość nadawania praw administratora innym użytkownikom

I teraz moje pytanie brzmi - czy tego typu projekt wyczerpie wymagania projektowe - hermetyzacja, dziedziczenie, polimorfizm, przeciążenie operatorów?

1
Nieposkromiony Wąż napisał(a):

I teraz moje pytanie brzmi - czy tego typu projekt wyczerpie wymagania projektowe - hermetyzacja, dziedziczenie, polimorfizm, przeciążenie operatorów?

Raczej tak – dziedziczenie można zastosować w deklaracji klas zwierząt, hermetyzację też (zależy ile danych chcesz na temat zwierzątek obsługiwać), polimorfizm na pewno, przeciążanie operatorów też się gdzieś zastosuje.

Według mnie masz zielone światło. ;)

0

Polimorfizm, dziedziczenie i hermetyzacja na pewno. Robisz klasę bazową/interfejs Animal i od niej dziedziczą takie rzeczy jak Mammal, Reptile czy Amphibian. No i dalej lecisz sobie z hierarhią w dół i specjalizujesz do takich rzeczy jak Frog czy Horse. Później tworzysz np. jakiś kontener z samymi płazami etc.., etc... już za pomocą polimorfizmu.

przeciążenie operatorów

Nie wiem... rozmnażać chcesz te zwierzaki i w związku z tym potrzebujesz np. przeładować operator +? :-) Bez przesady. Z ręką na sercu powiem, że już nawet nie pamiętam kiedy ostatnio przeładowywałem jakikolwiek operator.

1
grzesiek51114 napisał(a):

przeciążenie operatorów

Nie wiem... rozmnażać chcesz te zwierzaki i w związku z tym potrzebujesz np. przeładować operator +? :-) Bez przesady. Z ręką na sercu powiem, że już nawet nie pamiętam kiedy ostatnio przeładowywałem jakikolwiek operator.

Może podstawienie?

Zawsze można przeciążyć << (wyświetlanie) i może nieco rzadziej >> (wczytywanie) -- ale to poza klasami (ewentualnie friend). Jeśli masz przeciążyć operator koniecznie jako składową klasy, to można pomyśleć nad czymś nietypowym, tak na siłę -- jak może += w celu dodania praw?

0

No... wyświetlanie to jeszcze zrozumiem, a friend to antywzorzec. W ogóle zauważyłem, że piszący w C++ są jakimiś fetyszystami przeładowywania operatorów.

0
grzesiek51114 napisał(a):

No... wyświetlanie to jeszcze zrozumiem, a friend to antywzorzec. W ogóle zauważyłem, że piszący w C++ są jakimiś fetyszystami przeładowywania operatorów.

Bo jest fajne! :)

1

@grzesiek51114: przeciążanie operatorów też się gdzieś upchnie – jest ich na tyle dużo, że ich wykorzystanie to tylko kwestia kreatywności. Nie musi to mieć wielkiego sensu – to tylko zadanie.

A operator + można wykorzystać np. do spinania w pary papużek nierozłączek. ;)

0

Dzięki bardzo za odpowiedzi ;D Ważne było dla mnie, że da się to tu wcisnąć ;) skoro się da, to biorę ten projekt, a miejsca gdzie użyję np. owego przeladowania operatorow, mam nadzieję, że wyjdą w praniu.

1

A ja powiem szczerze, że nie widzę tu potencjału na dziedziczenie. Cały "interfejs" klasy Animal będzie się ograniczał do funkcji typu ustawX i pobierzX. Z tym, że np. słoń będzie miał funkcję dotyczącą długości trąby a małpa koloru nosa. Nie widzę tutaj przypadku gdzie jakaś klasa musiałaby posiadać własną implementację danej funkcjonalności Animal.
Nie ułatwi to też wyszukiwania zwierząt według gatunku/rodziny/typu itp., bo będzie to wymagało dynamic_cast. No chyba, że te informacje będą zapisane w klasie Animal, ale wtedy bezsensowne staje się dziedziczenie i cała hierarchia klas.

0

Idealne na UI projekt w QT z zastosowaniem nawet MSSQL

0

A może tak szachy? Mamy klasę abstrakcyjną Bierka, z niej możemy wywieść Pion, Skoczek itd... Każda ma swój ruch i bicie i można się tu pobawić.

A jeśli chodzi o operatory, to można zrobić + żeby skłał dwie figury w jedną, zamiast definiować od początku (auto hetman = Wieza() + Goniec())

0

Myślałem nad jakąś grą, ale wydaje mi się, że w tak krótkim czasie może mnie to przerosnąć - dlatego wołałbym coś prostszego, typu właśnie tego co napisałem.
@tajny_agent - a czy widzisz na pierwszy rzut oka jakąś funkcjonalność, którą mógłbym dodać, a która sensownie wprowadzałaby dziedziczenie? Jednocześnie, żeby była spokojnie do zrobienia dla osoby uczącej się dopiero obiektówki

1

I teraz moje pytanie brzmi - czy tego typu projekt wyczerpie wymagania projektowe

  • hermetyzacja, dziedziczenie, polimorfizm, przeciążenie operatorów?

Kubeł zimnej wody: twoja uczelnia zrobiła cię w balona, dając tak idiotyczne wytyczne, a wykładowca zachował się bardzo nierozsądnie dając ci takie zadanie.

hermetyzacja, dziedziczenie, polimorfizm, przeciążenie operatorów - to są narzędzia, których się nie powinno używać na siłę (jak ci kazano).

Dawanie wytycznych projektu typu masz tutaj hermetyzację, dziedziczenie, polimorfizm, przeciążanie operatorów i musisz użyć wszystkiego, żeby tylko użyć to totalny bezsens. Trochę jak masz w kuchni sól, cukier, dżem, mięso, marchewkę, makaron, czekoladę, wódkę i chipsy i zrób zupę używając wszystkich składników. A potem tysiące studentów opuszcza mury uczelni i zaczyna pisać komercyjnie strasznie przeinżynierowany kod, bo tak się nauczyli na uczelni (niestety ludziom przez lata zostają te chore nawyki).

dla osoby uczącej się dopiero obiektówki

paradygmat obiektowy polega raczej na zrozumieniu zależności między obiektami, i na tym, w jaki sposób się komunikują ze sobą. Wcale nie musi oznaczać to robienia aplikacji z nawrzucanym byle jak dziedziczeniem, hermetyzacją, polimorfizmem. Jeśli tego cię uczą na uczelni, to twoja uczelnia jest bardzo słaba i tracisz tylko czas.

Jakbym ja był wykładowcą, to raczej uczyłbym tego jak zrobić, żeby obiekty się ładnie komponowały ze sobą, ładnie komunikowały itp. Komunikacja między obiektami jest ważniejsza od samych klas.

możliwość wyszukiwania zwierząt według ich "systematyki" - ssaki, które potem by się dzieliły na drapieżne, gryzonie i tak dalej, płazy, gady...
...
Ogólnie wiadomo o co chodzi ;) A także oczywiście możliwość wyszukiwania według konkretnej nazwy gatunku.

umieszczanie takich hierarchii w kodzie jako hierarchię klas spowoduje to, że potem ciężko będzie się do nich dostać, czy wyszukać coś w trakcie trwania programu (chyba, że C++ dysponuje jakimiś zaawansowanymi metodami refleksji, ale tego nie wiem). Jak dla mnie lepiej byłoby stworzyć nowe pole w klasie Animal, które oznacza rodzaj zwierzęcia i potem przy tworzeniu dowolnego zwierzaka ustawiać w konstruktorze (tak, że np. type będzie się równało 'cat'). Wtedy łatwiej będziesz mógł to wyszukać dynamicznie. Hierarchię też możesz zrobić dynamicznie, nie za pomocą archaicznych konstrukcji dziedziczenia, ale przechowując gdzieś w jakiejś liście dane o każdym rodzaju zwierzęcia i odnośnik do rodzaju nadrzędnego (w sumie to jest problem, o którym prościej się myśli w kategoriach tabel w bazach danych niż za pomocą tworzenia hierarchii klas... )

0

Doskonale zdaję sobie sprawę z tego, że ów projekt jest bezsensem - tymbardziej, że połowa uczy się programowania dopiero na studiach (w tym ja) i mając na pierwszym semestrze podstawy programowania, w których "najtrudniejszymi" zagadnieniami były wskaźniki czy tablice dynamiczne, dostaje w drugim semestrze już na dzień dobry do zrobienia projekt, który ma zawierać chyba wszystkie "elementy" programowania obiektowego. W poprzednich latach były laboratoria, gdzie uczono się po kolei wszystkiego, i gdzie dobrzy laboranci myślę uczyli co i gdzie używać, by było jak najefektywniej.
Nasz wykładowca został w czasie jeżeli chodzi o programowanie dobre 15 lat, także o nim nawet się nie wypowiadam.

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