Kwestia projektowania oprogramowania

Moje pytanie zawarłem w tym dziale ponieważ dotyczny ono książki "Modelowanie i implemetacja systemów informatycznych" M. Trzaska i filozofii która jest tam prezentowana - tzn. problematyka wytwarzania oprogramowania z wykorzystaniem podejścia obiektowego..

Zacznę od tego, że nie mam dużego doświadczenia w programowaniu.. można powiedzieć, że jestem na początku drogi i liznąłem trochę poszczególne podejścia / zagadnienia dotyczące programowania i rozwiązywania problemów...

Zastanawia mnie jednak jedna rzecz - w książce na przykładzie projektowania aplikacji dla wypożyczalni filmów przedstawiony jest np. diagram klas oraz część jego kodu który implementuje klasę Film, Klient, Pracownik, Wypożyczenia itp..

Wszystko super.. Tylko dla mnie jest to jakieś "dziwne" podejście.. tzn. ja niedawno miałem robiłem podobną rzecz z tym, że moja aplikacja wykorzystywała bazę danych.. I tutaj mi to wygląda bardziej logicznie, ponieważ w bazie istniało kilka tabel (klient, filmy, wypozyczenia, itp) i tylko za pomocą zapytań wyciągało się dane pod konkretne kontroli typu label, textLine, dataView, etc.. A w tej książce poprzez zastosowanie tych wszystkich klas i obiektów robi się to strasznie skomplikowane (przynajmniej dla mnie to tak wyglada - dużo kodu, metod, dziedziczenia.. i do tego dane są jakoś dziwnie składowane, np. w vetorze..).

Jak to wygląda w praktyce? Czy za pomocą "takiej" obietkowości w praktyce się realizuje takie projekty czy raczej z bazą danych?

Pozdrawiam,
Marek

mareKO napisał(a):

Jak to wygląda w praktyce? Czy za pomocą "takiej" obietkowości w praktyce się realizuje takie projekty czy raczej z bazą danych?

Lepiej je realizować obiektowo, bo w ten sposób można osiągnąć większą elastyczność, większe możliwości rozbudowy i większą stabilność, dzięki możliwości podzielenia aplikacji na warstwy - bo kod obsługujący interfejs użytkownika, powinien być oddzielony od tego realizującego obliczenia i logikę biznesową, oraz od kodu obsługującego źródło danych.

Kiedyś o tej kwestii rozdzielenia warstw aplikacji.. Jednak zastanawiam się jak to wykonac np. w projekcie z bazą danych.. bo tutaj nie ma za wiele klas typu Film, Wypożyczenia, Klient.. itp..

@mareKO obiektowa reprezentacja pozwala dobrze odwzorować dziedzinę. Bo dzięki temu masz w kodzie:

if (magazyn.czyFilmDostepny(tytul)){
    Film film = magazyn.pobierzFilm(tytul);
    klient.dodajFilm(film);
}

Zauważ że na tym "poziomie abstrakcji" w ogóle nie musisz wiedzieć o tym JAK te operacje są zrealizowane. Czy to się gdzieś w bazie zapisuje, czy też drukuje się u pana mietka w pokoju na jego igłówce.
Dzięki temu aplikacje pisze się znacznie łatwiej bo są podzielone na warstwy. Gdzieśtam na dole zapewne będzie warstwa dostępu do bazy danych i tam dane będą zapisywane / odczytywane z bazy, ale to będzie nas interesować dopiero na tamtym niższym poziomie abstrakcji.
Myśle że łatwiej to zrozumieć jak pomyśli się o dużym systemie ;)

No niby wygląda to fajnie (przejrzyście..). Tylko zakładając tak przygotowany kod, jak potem może być realizowane połączenie z bazą?

Np. mając ten Twój kod:

 
if (magazyn.czyFilmDostepny(tytul)){
    Film film = magazyn.pobierzFilm(tytul);
    klient.dodajFilm(film);
}

pod metodą pobierzFilm(tytul) jest np. przekazywany tytuł, który jest potem parameterem zapytania i na tej podstawie wyszukiwany jest dany film i dalsze czynności z tym związane.. ?

Na przykład. Możesz tam mieć przygotowane zapytanie które potem odpalasz i zwracasz wyniki. Możesz tam mieć odwołanie do obiektu DAO. Możesz tam mieć pobranie rekordów ORMa. Możesz tam mieć telefon do pana mietka który wklepie te dane ręcznie. O to właśnie chodzi -> to nie ma znaczenia co tam jest!
Chodzi o to że patrząc na ten kod od razu widzisz jeśli popełniłeś błąd na tym poziomie abstrakcji. Na przykład dlatego że powinieneś tu mieć jeszcze wywołanie
klient.poinformujODodanymFilmie();
Gdybyś miał tutaj kolosalną metodę na kilkaset linii, z jakimiś zapytaniami SQL i innymi cudami to w życiu być tego błędu nie znalazł - bo przeciętny człowiek jest w stanie w danej chwili myśleć na maksymalnie 2 poziomach abstrakcji ;]

@mareKO: w realnym świecie to jest trochę pewnie bardziej skomplikowane - nie czytałem tej książki akurat, ale kilka podobnych.
Temat OOP / OOD / OOA jest tak obszerny że książki tego typu zwykle stosują uproszczenia.

Po pierwsze zwykle stosuje się bazy relacyjne z programowaniem obiektowym. I to są dwa różne światy. Trzeba je jakoś połączyć.
Stosuje się w tym celu ORM / i np. wzorzec Active record / ActiveObject:

http://en.wikipedia.org/wiki/Active_record_pattern

Oprócz tego dzieli się aplikację na warstwy: MVC (model-view-controller), dzięki czemu łatwiej jest zlokalizować funkcjonalność odpowiedzialną za daną czynność, kto widział kod ZenCart PL wie jak to może być przydatne.

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Klasy które podałeś: Film, Klient, Pracownik, Wypożyczenia to warstwa Modeli.

Ok, dzieki Panowie za "naobrazowanie" tematu ;)
(ps. wydaje mi się, że takie podejście trzeba dobrze przećwiczyć aby móc je skutecznie używac..)

mareKO napisał(a):

(ps. wydaje mi się, że takie podejście trzeba dobrze przećwiczyć aby móc je skutecznie używac..)

Generalnie wszystko jest kwestią doświadczenia. Trzeba napisać kilka aplikacji na kilka różnych sposobów, żeby to "poczuć".