Projektowanie aplikacji desktopowej a OOP. Jakie są dobre praktyki.

Question

Witam. Ostatnio obejrzałem 10h kurs c++ który omawia podstawy, między innymi OOP, przepracowałem polimorfizm i hierarchie na bardzo podstawowym poziomie. Postanowiłem że stworze mały projekt w oparciu o poznaną wiedzę. Aplikacja konsolowa symuluje działanie prostego programu, który pozwala zarządzać lotami na lotnisku. Użytkownik może dodać lot do listy, zarezerwować miejsce pasażerowi, czy zmienić informacje odnośnie lotów i pasażerów. Problem napotkałem już przy opracowaniu klas do projektu, nie jestem pewien jak to ma ze sobą współgrać. Czy każda funkcja ma mieć swoją klasę, czy raczej stworzyć wszystko w jednej klasie, czy jakoś to wypośrodkować. Moje pytanie brzmi jak projektujecie swoje klasy do aplikacji, czy robicie to na początku czy w trakcie pisania wymyślacie rozwiązanie na poczekaniu. Czy właściwe jest tylko podejście obiektowe, czy niektóre funkcjonalności można realizować nie zaprzęgając klasy. Z góry dziękuję za odpowiedź przepraszam za to że to pytanie jest tak zagmatwane :)

Answer 1

Pytanie o to, jak projektować klasy jest bardzo złożone. Jest mnóstwo książek na ten temat i one często dadzą Ci tylko heurystyki, nie gotowe reguły które będą zawsze działać. Polecam zacząć od książki Roberta C. Martina "Zwinne wytwarzanie oprogramowania. Najlepsze zasady, wzorce i praktyki". Ta lektura bardzo mocno zmieniła moje spojrzenie na architekturę.

Czy właściwe jest tylko podejście obiektowe, czy niektóre funkcjonalności można realizować nie zaprzęgając klasy?

To nie tak, że któreś podejście jest właściwe, a któreś nie. To jest narzędzie. Pytasz czy młotek jest bardziej poprawny od śrubokręta. Do wbijania gwoździ tak, do wkręcania śrubek nie :) Jeżeli chcesz napisać hello worlda, to napisz go imperatywnie, strukturalnie. main, cout << "Hello world". Koniec. (Tu się w ogóle można spierać czy to nie jest program obiektowy, bo przecież std::cout to obiekt; jeżeli Ci to przeszkadza, to wyobraź sobie użycie std::printf zamiast std::cout). Jak by to wyglądało obiektowo? class Printer? class Message? Printer::print(const Message&)... Wiesz, obiektówka dokłada Ci do kodu złożoności, ale pozwala Ci rozwiązywać inne problemy. Pozwala Ci myśleć o programie jako o zbiorze urządzeń (obiektów), które potrafią dobrze robić swoją robotę i ze sobą gadają, żeby wykonać zadanie. Pozwala poprawić czytelność programu, (pozwala też pogorszyć). Na tym się nie kończy lista zalet obiektówki, ale nie mam na tyle wiedzy i czasu żeby wszystko tu wyłożyć :)

Z mojego doświadczenia: pisanie w sposób obiektowy na samym początku zajmuje więcej czasu niż gdyby to olać i robić wszystko w mainie, makaronem, ale z czasem, gdy projekt rośnie i staje się coraz bardziej złożony, panowanie nad nim staje się cholernie trudne. Jeżeli wiesz, że projekt ma być duży, albo po prostu chcesz sobie poćwiczyć obiektówkę, to pisz obiektowo :) W moich małych programach które użyję tylko raz raczej nie stosuję tego podejścia i piszę tak zwanym makaronem :) A oczywiście istnieją jeszcze inne paradygmaty: funkcyjny czy generyczny (i tu lista się nie kończy). One mają swoje zalety i wady, ale o nich za wiele się nie wypowiem, bo najwięcej siedzę w obiektówce. No i w C++ możesz te paradygmaty ze sobą mieszać, w zależności od potrzeb :)

Najpierw dowiedz się po co Ci ta obiektówka. Bo na chwilę obecną wiesz tylko, że chcesz przy budowie swojego programu użyć śrubokręta :) Dowiedz się do czego on służy, co Ci daje :) Może wyjść tak, że będziesz wbijał gwoździe śrubokrętem jak się go ślepo złapiesz :)

Comments

Nie myl używania obiektów z podejściem obiektowym. To, że masz w projekcie słowo "class" nie czyni go obiektowym. Po za tym, STL słynie z podejścia ubóstwianego przez jego twórce, czyli funkcyjnego.

Answer 2

Jak OOP to S.O.L.I.D

Comments

aha czyli jak Funkcyjne to juz nie SOLID? :D ....

---

Tego przecież nie napisałem... :/

---

@Wiciorny, a w jaki sposób się używa SOLID w FP?

---

Z definicji programowania funkcjonalnego : podstawowe paradygmaty takiego programowania to po za immutability  to  jest FCF - first class function, strategia evaluacji która ściśle wiązana jest z Single responsibility , transparetnosc referencji która jest bardzo związana z zasąda nie tyle integralnosci OPEN_CLOSED ale głównie tez struktury interferjsów.

Programowanie funkcyjne to nie tylko "reacj, js " bo tam to może inaczej wygląda, ale PF to też języki Javove, pythona i teraz też się tego używa  polecam kursy u Sobótki z architektury

---

@Comandeer, jak zasady Solid wiadomo były tworzone to mało kto tak rzetelnie znał się do uogólnienia programowania funkcyjnego, stąd też ściśle wiązalo się to z obiektowością tak też się to definiuje, jednak aktualnie inaczej wygląda świat FP i on mocno wkracza juz w samą jave powiem szczerze  że za niedługo biorąc pod uwagę istotne zmiany z coraz to nowszymi wersjami JDK to idzie to bardziej w stronę FP niz OOP 

---

Ok, ale to dalej nie tłumaczy, w jaki sposób aplikować SOLID do FP. W jaki sposób strategia ewaluacji jest związana z SRP? Czemu transparentność referencji jest związana ze strukturą interfejsów (i co ta struktura ma do samego SOLID)?

podstawowe paradygmaty takiego programowania to po za immutability […]

 IMO akurat niemutowalność jest skutkiem opierania flow na kompozycji funkcji (z czego większość jest czysta), nie jest to podstawowy paradygmat FP.

powiem szczerze  że za niedługo biorąc pod uwagę istotne zmiany z coraz to nowszymi wersjami JDK to idzie to bardziej w stronę FP niz OOP 

A może po prostu liczba mechanizmów OOP w Javie jest już na tyle duża, że nie ma sensu dalej ich rozwijać, natomiast lepiej obecnie rozwijać Javę w kierunku języka wieloparadygmatowego?