![]() |
![]() |
![]() ![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 25 Pomógł: 0 Dołączył: 15.04.2009 Ostrzeżenie: (0%) ![]() ![]() |
|
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) ![]() ![]() |
Wątek zejdzie nam tutaj nieco na inny temat (reprezentacji bazy danych w aplikacji), ale mniejsza z tym... od razu zaznaczę, że wypowiadam się jedynie w kontekście tych trzech cytatów, nie całych artykułów.
Mocno bym się spierał z tym co zostało tu przedstawione. Zarzucają, że obiekty domeny nie posiadają logiki co nie jest do końca prawdą. Wydaje mi się, że autorzy za bardzo wzięli sobie do serca podstawową definicję obiektówki*. Obiekty takie zawierają po prostu najbardziej elementarną logikę, która nie wymaga żadnych dodatkowych zależności czy skomplikowanego kodu. Czyli dla przykładowego obiektu News będą to metody pozwalające przyporządkować mu daną kategorię albo sprawdzić czy nie został on skasowany (gdzie skasowanie traktuje się np. jako niepustą wartość pola deletedAt). Innymi słowy proste metody, gdzie większość z nich mieści się w 5 - 15 linijkach kodu (nie mówię tutaj o klasycznych getterach/setterach). Na samą myśl co by się stało z tym obiektem, gdyby wrzucić do niego realną, "ciężką" logikę słabo mi się robi. Ten nieszczęsny obiekt stałby się nagle odpowiedzialny na kilka, może nawet kilkanaście rzeczy na raz. Praca z takimi potworkami do przyjemnych nie należy, a gdy nagle trzeba dla jakiegoś fragmentu aplikacji zastosować inną logikę mamy niezły problem - bo właściwie jedyne co da się zrobić to dziedziczyć, czyli robić z potworka prawdziwe monstrum. Dalej twierdzą, że takie obiekty niby są idealnym odzwierciedleniem bazy danych, co jest oczywiście bzdurą. Interfejs takich obiektów powinien być projektowany pod dobry model domeny, nie bazę danych (czy jakiekolwiek inne źródło danych). Przy późniejszym zapisie danych do źródła danych model obiektowy powinien zostać przetworzony na model relacyjny dla bazy danych - ale to już zadanie jakiegoś porządnego ORM-a, a nie samego obiektu domeny. * Podstawowa definicja programowania obiektowego to połączenie struktury danych i funkcji operujących na niej w jeden logiczny obiekt, co stoi w sprzeczności z programowaniem proceduralnym, gdzie struktura danych i funkcje operujące na niej są kompletnie niezależne. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 7.10.2025 - 04:51 |