Temat: We are not OOP programmers anymore

Cześć

Na początku zacznę może od opisu obiektu wg. Booch 'a:
Obiekt ma stan, [b] zachowanie [b] i tożsamość

Właśnie dotarło do mnie, że używając wzorców Jee nie tworzymy programów obiektowych tylko proceduralne. Można by rzec, że paradygmat SOA propaguje takie zachowanie O_o. Nie będę tutaj tłumaczył, jest mase artykułów na ten temat :
* http://www.javaworld.com/javaworld/jw-05-2009/jw-05-do...
* https://docs.google.com/document/d/1RDNH0SBCWdRkVFaJc9D...
* http://www.martinfowler.com/bliki/AnemicDomainModel.html

Jak widać najwięksi GURU JEE poruszało ten temat. Istnieją nawet próby programowanie OOP w JEE. Pytanie jakie się pojawia dlaczego programujemy proceduralnie ? Według mnie główną przyczyną są relacyjne bazy danych , ciężko jest przedstawić model relacyjny na model obiektowy.

1Mam takie pytanie, czy ktoś z was stosował podejście DDD w aplikacji JEE/Spring ??
2 Czy ten model programowanie się przyjmie ??
3 Czy aplikacje działają szybciej/wolniej , łatwiej się pisze ??

ps. Jak jakiegoś świeżaka przyjmuje się na programiste i dopiero wkłada ręce w JEE to najlepiej od razu go uświadomić, żeby zapomniał o OOP :DTen post został edytowany przez Autora dnia 19.09.13 o godzinie 23:06

Temat: We are not OOP programmers anymore

OOP to sposób myślenia, który wbrew pozorom nie jest ani intuicyjny, ani łatwy. Duża część aplikacji napisanych w w nowoczesnych językach obiektowych to zlepek elementów programowania obiektowego oraz proceduralnego.

Dlatego właśnie aplikacje napisane "obiektowo" (cudzysłów celowy) są tak trudne w utrzymaniu - ponieważ część decyzji dotyczących architektury została podjęta, nazwijmy to, obiektowo, a część proceduralnie. Ten brak spójności jest bardzo bolesny, bo skutkuje implementacją antywzorca orgii obiektów.

Dlatego właśnie - paradoksalnie! - aplikacje napisane w czystym C są często bardziej czytelne i łatwiejsze w utrzymaniu niż te napisane w C++, Javie czy C#.

Temat: We are not OOP programmers anymore

Łukasz W.:
Cześć

Na początku zacznę może od opisu obiektu wg. Booch 'a:
Obiekt ma stan, [b] zachowanie [b] i tożsamość

I teraz mając tę definicję przejrzyj jeszcze raz "katalog wzorców projektowych" a zobaczysz, że część (większość?) z nich jest tak średnio obiektowa. Na przykład taki wizytator to często anonimowa klasa opakowująca jedną metodę (funkcję?) - No i jak w ogóle klasa może być anonimowa jeśli tożsamość jest częścią definicji :D

Ostatnio czytałem ciekawe opinie, że ponieważ OOP tak naprawdę opiera się na pewnym folklorze ludowym i nie ma jakiejś ścisłej definicji to można tam wrzucić cokolwiek i jak działa fajnie to jest to obiektowe a jak nie to nie jest obiektowe.

Osobiście uważam, że uwolnienie się od założenia "co jest obiektowe jest automatycznie zajebiste" jest zdrowym podejściem i w ten sposób można odkryć inne ciekawe "paradygmaty" (tudzież sposoby) programowania, które mogą okazać się dla danej osoby/zespołu bardziej produktywne.

pzdr

Temat: We are not OOP programmers anymore

Paweł W.:

Łukasz W.:
Cześć

Na początku zacznę może od opisu obiektu wg. Booch 'a:
Obiekt ma stan, [b] zachowanie [b] i tożsamość

No i jak w ogóle klasa może być anonimowa jeśli tożsamość jest częścią definicji :D

W definicji mowa o tożsamości obiektu, a nie klasy. To że nie ma identyfikatora nie oznacza, że nie ma tożsamości.
To tak na marginesie ;-)

Co do ogółu się zgadzam, widziałem wiele "obiektowych" i nieobiektowych rozwiązań. Niezależnie od paradygmatu, trafiały się i bardzo dobre i bardzo słabe wykonania. Nie należy zakładać klapek na oczy i żyć w przekonaniu, że tylko jedno podejście jest najlepsze.

Platforma javowa narzuca zestaw klocków, a których można rozwiązanie budować, jak i zestaw wytycznych (wzorce), z których można korzystać. Nikt nikogo nie zmusza do stosowania OOP, czy (nie)łączenia różnych podejść. Ot, wolny wybór. Chyba najważniejsze żeby był racjonalny :)

Temat: We are not OOP programmers anymore

Nie jest tak źle jak na początku myślałem, główny problem leży w anemicznych encjach jakie tworzymy.

Encje są tym co znamy z maperów relacyjno-obiektowych –obiektem, który jest identyfikowalny po jakimś
kluczu. W DDD encje posiadają jednak metody biznesowe. Oczywiście nie chodzi o to aby całą logikę biznesową
„rozsmarować” na encjach. Encje powinny posiadać tylko charakterystyczne dla siebie odpowiedzialności wynikające z ich natury.

Temat: We are not OOP programmers anymore

Niestety standardowy schemat opisywany w dokumentacji do JEE promuje "serwisowe" podejście, którego istotą jest proceduralny ciąg instrukcji, zapięty w transakcji. Nie jest to podejście jednoznacznie złe (dla prostych aplikacji jest wystarczające), ale rzeczywiście sprawia wrażenie zamknięcia w proceduralnym i anemicznym środowisku. Jest to zagadnienie z którym zderzyłem się jakiś czas temu i wiem dokładnie o czym mówisz.

Łukasz W.:
1Mam takie pytanie, czy ktoś z was stosował podejście DDD w aplikacji JEE/Spring ??
2 Czy ten model programowanie się przyjmie ??
3 Czy aplikacje działają szybciej/wolniej , łatwiej się pisze

Tak, zrealizowałem pełne podejście DDD w środowisku JEE 6. Ciężko jednoznacznie odpowiedzieć na te pytania, ale mogę podzielić się doświadczeniami na tym gruncie.

Po pierwsze - proceduralnie nie oznacza od razu źle... Szczególnie w przypadku mało złożonej aplikacji, proste serwisy są bardzo dobrym wyjściem. Moim zdaniem koronną zasadą jest KISS i jeśli w wymaganiach aplikacji nie ma dużej ilości logiki biznesowej, to ładowanie tam elementów DDD jest typowym przerostem formy nad treścią.

Po drugie - DDD wcale nie jest w 100% obiektowe. Twórcy DDD od samego początku przyznali, że są zagadnienie, których po prostu nie da się zrealizować obiektowo (poczytaj dokładnie o application services i domain services). Dla przykładu: EJB traktujesz jako punkt wejścia do serwisu aplikacyjnego, który wystawiany jest na zewnątrz. EJB zapewnia transakcyjność i inne możliwości kontenera, a w metodzie EJB realizujesz application service, czyli wyciągasz agregat i wywołujesz na nim operacje.

Po trzecie - są proste sposoby ucieczki od anemii w JEE. Tutaj mamy dwa podstawowe podejścia:
1. Zamienić encje JPA, w encje w znaczeniu DDD. Można bez problemu zrealizować persistence używając tylko i wyłącznie adnotacji na polach. Wyrzucasz z encji settery (gettery tez najlepiej) i wpakowujesz logikę biznesową w encje. Proste, zwięzłe i skuteczne, moje ulubione rozwiązanie.
2. Zastosować dwa modele. Jeden do persistence, drugi domenowy i używać repozytoriów do tłumaczenia jednego modelu w drugi. Te rozwiązanie pozwala na świetną izolację warstw i na stworzenie idealnie czystego i przenośnego modelu domenowego. Problem w tym, że wymaga dużo pracy i powoduję eksplozję ilości klas.

Temat: We are not OOP programmers anymore

Marcin M.:

Po trzecie - są proste sposoby ucieczki od anemii w JEE. Tutaj mamy dwa podstawowe podejścia:
1. Zamienić encje JPA, w encje w znaczeniu DDD. Można bez problemu zrealizować persistence używając tylko i wyłącznie adnotacji na polach. Wyrzucasz z encji settery (gettery tez najlepiej) i wpakowujesz logikę biznesową w encje. Proste, zwięzłe i skuteczne, moje ulubione rozwiązanie.
2. Zastosować dwa modele. Jeden do persistence, drugi domenowy i używać repozytoriów do tłumaczenia jednego modelu w drugi. Te rozwiązanie pozwala na świetną izolację warstw i na stworzenie idealnie czystego i przenośnego modelu domenowego. Problem w tym, że wymaga dużo pracy i powoduję eksplozję ilości klas.

Widzę, że wiesz co mi chodzi w głowie :)
Wiem, że twórcy DDD zdają sobie sprawe, że nie wszystko można załatwić przez OOP.
Natomiast DDD mówi wyraźnie o podziale logiki na logike aplikacyjną oraz logikę biznesową. Logika aplikacyjna powinna być cięnkim klientem, natomiast logika biznesowa w obiektach.

Na koniec zaciekawiły mnie twoje dwa podejścia :

1. Podejście
Zalety:
+ Zwięzłe
+ Optymalna ilość klas
Wady:
- W obiekcie znajdują się adnotacje specyficzne dla danego providera
- Przekazujemy ciężkie encje pomiędzy warstwami.
- Czasami uciekamy od OOP na rzecz mapowania O/R


2. Podejście
Zalety:
+ Możliwa zmiana providera , brak uzależnienia. (IZOLACJA)
+ Pełne OOP , czysty model
Minusy:
- Masa klas
- Dublowanie kodu
- Dużo pracy przy translacji mogą pojawić się błędy.
-/+ Wydajność ????

Temat: We are not OOP programmers anymore

Łukasz W.:
1. Podejście
2. Podejście
....

Wszystko zależy od tego, co potrzebujesz. Jeśli model domenowy ma być przenośny, opcja 2 jest jedynym rozwiązaniem, jeśli nie to produktywność i prostota opcji 1 jest ciężka do przebicia (KISS przede wszystkim). Myślę też, że argumenty przeciwko opcji 1 są trochę przesadzone. Najnowsze standardy JPA/Hibernate są bardzo potężne i możesz w nich zmapować praktycznie wszystko co da się wymyślić. Określenie encji tworzonych w ten sposób jako "ciężkie" jest dość zagadkowe, niestety nie rozumiem co miałeś na myśli.

Jeszcze słowo odnośnie wydajności... Z pewnością opcja 2 wygląda znacznie lepiej na tym polu, bo pozwala dostosowywać model do wymagań bazy danych, bez przejmowania się logiką biznesową. Jest w tym dużo racji, ale jeśli potrzebujesz więcej wydajności w DDD, to jest na to prostszy sposób - CQRS.

Temat: We are not OOP programmers anymore

Jeszcze słowo odnośnie wydajności... Z pewnością opcja 2 wygląda znacznie lepiej na tym polu, bo pozwala dostosowywać model do wymagań bazy danych, bez przejmowania się logiką biznesową. Jest w tym dużo racji, ale jeśli potrzebujesz więcej wydajności w DDD, to jest na to prostszy sposób - CQRS.

Dzięki widzę, że muszę się jeszcze duuużo nauczyć. W każdym razie wiem jedno na pewno być lepszym programistą OOP i patrzeć pod innym kątem na aplikacje niż do tej pory :))

Swoją drogą myślę, że w dużej mierze za taki stan rzeczy ponosi Relacyjna Baza Danych. Co z tego, że piszemy w obiektowym języku (JAVA), jak tak naprawdę w fundamencie (warstwie integracji) mamy relacyjną bazę. Sama relacyjna baza ma się nijak do programowania obiektowego. To jak ogień i woda, stąd ORM - hibernate, jpa itd. Relacyjne bazy danych uwielbiają procedury, triggery itd, stąd wydaje mi się, że programiści przenoszą myślenie relacyjne do programowania. Zgadzam się z tobą, że programowanie proceduralnie nie jest złe we wszystkich przypadkach. Jednak jeśli w swoim programie używasz w nadmiarze tego stylu to z pewnością jest coś nie tak. Wynikają wtedy z tego 2 rzeczy, albo masz taki prosty model, że powinieneś użyć np PHP , bo szkoda strzelać do muchy z armaty, albo źle zamodelowałeś system, lub co gorsza system w ogóle nie ma modelu :/

Pozdrawiam i biorę się za DDD bo mam dużo zaległości :)

Temat: We are not OOP programmers anymore

Łukasz W.:

Swoją drogą myślę, że w dużej mierze za taki stan rzeczy ponosi Relacyjna Baza Danych. Co z tego, że piszemy w obiektowym języku (JAVA), jak tak naprawdę w fundamencie (warstwie integracji) mamy relacyjną bazę. Sama relacyjna baza ma się nijak do programowania obiektowego. To jak ogień i woda, stąd ORM - hibernate, jpa itd.

trochę nie na temat ale jako ciekawostka spójrz na ORM bez RBDMS, nie używałem ale koncepcyjnie bardzo ciekawe:

http://www.objectdb.com/

Temat: We are not OOP programmers anymore

Ja dla odmiany modeluje na grafach: http://www.neo4j.org/
W tym przypadku OOP tez wchodzi w gre

Jarosław S.:

Łukasz W.:
Swoją drogą myślę, że w dużej mierze za taki stan rzeczy ponosi Relacyjna Baza Danych. Co z tego, że piszemy w obiektowym języku (JAVA), jak tak naprawdę w fundamencie (warstwie integracji) mamy relacyjną bazę. Sama relacyjna baza ma się nijak do programowania obiektowego. To jak ogień i woda, stąd ORM - hibernate, jpa itd.

trochę nie na temat ale jako ciekawostka spójrz na ORM bez RBDMS, nie używałem ale koncepcyjnie bardzo ciekawe:

http://www.objectdb.com/

Temat: We are not OOP programmers anymore

Bazy NoSql czy Obiektowe nadają się zdecydowanie bardziej dla Javy. Problem polega na tym, że wiele firm się ich "boi" jeśli chodzi o transakcje i ACID. Zwłaszcza jeśli mają być zastosowane do finansowych zagadnień.

Temat: We are not OOP programmers anymore

Łukasz W.:
Bazy NoSql czy Obiektowe nadają się zdecydowanie bardziej dla Javy. Problem polega na tym, że wiele firm się ich "boi" jeśli chodzi o transakcje i ACID. Zwłaszcza jeśli mają być zastosowane do finansowych zagadnień.

no i nic dziwnego, nosql nie powstał żeby zastąpić RDBMS ale żeby zapełnić lukę między pełnym tranzakcyjnym RDBMS a bazą typu plik CSV. Moim zdaniem nosql świetnie się nadają do przechowywania dokumentów i wyników obliczeń do raportów do późniejszej prezentacji itp. Za to dane źródłowe do obliczeń raportów pozostawiłbym trzymane w chronionej RDBMS.

Temat: We are not OOP programmers anymore

Ja wole wierzyc, ze jednak nosql powstal jako alternatywa ;P
W aktualnym projekcie caly system postawilismy na nosqlu: couchdb, redis, zero sqla a daje rade

Jarosław S.:

Łukasz W.:
Bazy NoSql czy Obiektowe nadają się zdecydowanie bardziej dla Javy. Problem polega na tym, że wiele firm się ich "boi" jeśli chodzi o transakcje i ACID. Zwłaszcza jeśli mają być zastosowane do finansowych zagadnień.

no i nic dziwnego, nosql nie powstał żeby zastąpić RDBMS ale żeby zapełnić lukę między pełnym tranzakcyjnym RDBMS a bazą typu plik CSV. Moim zdaniem nosql świetnie się nadają do przechowywania dokumentów i wyników obliczeń do raportów do późniejszej prezentacji itp. Za to dane źródłowe do obliczeń raportów pozostawiłbym trzymane w chronionej RDBMS.Ten post został edytowany przez Autora dnia 24.09.13 o godzinie 10:18

Temat: We are not OOP programmers anymore

Łukasz G.:
Ja wole wierzyc, ze jednak nosql powstal jako alternatywa ;P
W aktualnym projekcie caly system postawilismy na nosqlu: couchdb, redis, zero sqla a daje rade

Rozwiązań nosql jest jak frameworków ;-) Jakie kryteria braliście pod uwagę przy wyborze CouchDB?

Temat: We are not OOP programmers anymore

Paweł W.:
I teraz mając tę definicję przejrzyj jeszcze raz "katalog
wzorców projektowych" a zobaczysz, że część (większość?) z
nich jest tak średnio obiektowa. Na przykład taki wizytator to
często anonimowa klasa opakowująca jedną metodę (funkcję?) -
No i jak w ogóle klasa może być anonimowa jeśli tożsamość
jest częścią definicji :D

Tożsamość (identity) w programowaniu obiektowym oznacza, że np. w Javie mając dwa obiekty możesz operatorem == stwierdzić, czy są dokładnie tym samym obiektem (referencje wskazują na to samo), co w przypadku obiektu anonimowego stwierdzić możesz porównując go z dowolnym obiektem o zgodnym nadtypie. Dla kontrastu tożsamości nie mają byty języka czysto funkcyjnego - krotka (''A", 3) jest zawsze równa utworzonej w zupełnie innym miejscu programu krotce ("A", 3), czy też rekordy w czysto relacyjnej bazie danych.

Moim zdaniem każdy paradygmat jest do niczego. Paradygmat to tylko zbiór klocków, którymi próbujemy zamodelować świat. Masz same trójkąty, a musisz zamodelować koło.

Programowanie obiektowe jest dobre, bo dobrze użyte pozwala na budowanie bardzo niezależnych modułów. Same moduły wychodzą fajne, ale właściwe algorytmy są nieczytelne i rozwlekłe, np. takie banalne przetworzenie listy bytów staje się w nich czasem żenująco złożone, wymaga zdekomponowania wielu obiektów by w końcu dostać się do prostych danych. Dodatkowo to, że obiekty mają stan utrudnia ich testowanie.

W programowaniu funkcyjnym implementacje algorytmów często wychodzą wyśmienicie - przetwarzanie danych regularnych jest bardzo zwięzłe. Łatwo testuje się czyste funkcje. O plusach w przypadku współbieżności wspominać nie trzeba. Niestety budowane moduły nie są tak hermetyczne jak w OOP.

Temat: We are not OOP programmers anymore

Łukasz W.:
Cześć

Właśnie dotarło do mnie, że używając wzorców Jee nie tworzymy programów obiektowych tylko proceduralne. Można by rzec, że paradygmat SOA propaguje takie zachowanie O_o.

?
Paradygmat SOA nie ma z tym nic wspólnego.
OO przedstawia / proponuje pewną metodę organizacji kodu programu, natomiast SOA opisuje organizację komponentów systemu...Ten post został edytowany przez Autora dnia 24.09.13 o godzinie 13:52

Temat: We are not OOP programmers anymore

Nie komponentow a uslug ;)

Łukasz W.:
Cześć

Właśnie dotarło do mnie, że używając wzorców Jee nie tworzymy programów obiektowych tylko proceduralne. Można by rzec, że paradygmat SOA propaguje takie zachowanie O_o.

?
Paradygmat SOA nie ma z tym nic wspólnego.
OO przedstawia / proponuje pewną metodę organizacji kodu program, natomiast SOA opisuje organizację komponentów systemu...

Temat: We are not OOP programmers anymore

Łukasz W.:
Cześć

Na początku zacznę może od opisu obiektu wg. Booch 'a:
Obiekt ma stan, [b] zachowanie [b] i tożsamość

to bardzo stara definicja, opisuje nie tyle paradygmat co jego impelementację

Właśnie dotarło do mnie, że używając wzorców Jee nie tworzymy programów obiektowych tylko proceduralne.

nie polemizuję ale to podobno prawda :) (słyszę to już po raz kolejny)

Według mnie główną przyczyną są relacyjne bazy danych , ciężko jest przedstawić model relacyjny na model obiektowy.

to prawda, ale wystarczy nie stosować modelu relacyjnego w projektowaniu i programowaniu i jest git..

1Mam takie pytanie, czy ktoś z was stosował podejście DDD
w aplikacji JEE/Spring ??

o ile wiem pewne moje projekty były tak implementowane, ale wiem też, że wzorce "wbite" w JEE były często zastępowane innymi zgodnymi z OOP

2 Czy ten model programowanie się przyjmie ??

z obserwacji widze, że aplikacje OOP są bardziej SOLID ;) (w zasadzie dla modelu relacyjnego SOLID jest nie do osiągnięcia)

3 Czy aplikacje działają szybciej/wolniej , łatwiej się pisze ??

zależy od projektu logiki całości

to byłem ja projektant nieprogramista :)

Temat: We are not OOP programmers anymore

OOP to sposób myślenia, który wbrew pozorom nie jest ani intuicyjny, ani łatwy.

zaryzykuje tezie, że nie jest intuicyjny wyłącznie dla programistów wychowanych na tezie:

funkcje + struktury danych =oprogramowanie

Duża część aplikacji napisanych w w nowoczesnych językach obiektowych to zlepek elementów programowania obiektowego oraz proceduralnego.

to dzieło konkretnych programistów

Dlatego właśnie aplikacje napisane "obiektowo" (cudzysłów celowy) są tak trudne w utrzymaniu - ponieważ część decyzji dotyczących architektury została podjęta, nazwijmy to, obiektowo, a część proceduralnie. Ten brak spójności jest bardzo bolesny, bo skutkuje implementacją antywzorca orgii obiektów.

wystarczy najpierw zaprojektować bazę danych w modelu relacyjnym, dodać mu ORM i napisać "onbiektowo" program, - to recepta a porażkę

Dlatego właśnie - paradoksalnie! - aplikacje napisane w czystym C są często bardziej czytelne i łatwiejsze w utrzymaniu niż te napisane w C++, Javie czy C#.

nie widzę żadnego związku czytelności z narzędziem implementacji