Doceniasz przejrzystość, to cenne.
Poczułeś, ze napisanie klasy do tego może doprowadzić ... w teorii dobrze.
To były dwie dobre wiadomości. Teraz złe.
Nie każde class
to programowanie obiektowe, oj nie. Klasa to nie zbiornik na "wszystko co mi się udało"', ale zakres odpowiedzialności i dobra nazwa która sie wiąże z jakością projektu
Tu nazwa "zadanie3" bardzo szczerze ujawnia problem z projektem klasy, czym ona naprawdę jest. Jest zbiornikiem na wszystko. Mogła by być nazwa FibbonaciDoLimitu (celowo przesadzam z dokładnością), i bardzo wyraźnie zamierzona jako pojemnik na N liczb (podane w konstruktorze, dialogi wcześniej, a więc klasa jest czystsza) *)
.
Metody
Dobra metoda to wyrazista odpowiedzialność, wyrażająca się JEDNYM czasownikiem.
Tu jest kiepsko. Właściwie wszystkie metody mają zakłamane nazwy, a ich realne działanie opisują spójniki "i".
"Prowadź dialogi z użytkownikiem" I "wypełnij tablicę" i "drukuj"
Drukowanie.
Twój kod cierpi (jak często kod edukacyjny) na "wszędzie drukowanie". Najkrócej patologię odsłania funkcja iloczynDwochLosowych
, która jest typu void
, ale drukuje.
Funkcja 'ilosczyn' powinna zwracać swój wynik, a drukować miałby jej klient (miejsce wywołania), o ile uzna, że drukowanie na cout w ogóle go interesuje. Bo może to program graficzny, albo webowy, i chce inaczej wykorzystać uzyskaną liczbę.
Jeśli drukowanie.
jesli drukowanie, jak bym widział podanie strumienia w argumencie - niechby wywołujący miał wybór, na co chce to drukować.
void wyswietlFiby(std::ostream & str)
*)
wtedy funkcja ujawniająca jeden element void wypiszPoIndeksie(int x)
by była zupełnie inna, w wariancie master const operator tablicowy (troszkę trudniejsze), ale jeśli jako funkcja, to zwracająca wartość do dyspozycji.
Mam na myśi, że jeśli mocno się nakierujesz, że klasa to "koszyk na jabłka", to dobre operacje na takiej klasie się dość łatwo nasuną.