Temat: We are not OOP programmers anymore

Paweł W.:
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.

>

dla mnie - reprezentuje kupujących - jedynym miernikiem "zajebistości" oprogramowania są, poza kosztem wytworzenia, jego koszty rozwoju (np. łączne koszty za pięć lat korzystania z niego), z mojego doświadzenia wynika, że obiektowe (takie prawdziwe SOLID) są najbardziej zajebiste (ale mówię o systemach typowo biznesowych)Ten post został edytowany przez Autora dnia 24.09.13 o godzinie 13:51

Temat: We are not OOP programmers anymore

.Ten post został edytowany przez Autora dnia 13.08.16 o godzinie 21:35

Temat: We are not OOP programmers anymore

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

bingo

Temat: We are not OOP programmers anymore

Łukasz W.:
- Przekazujemy ciężkie encje pomiędzy warstwami.

??? wystarczy stosować DTO, w zasadzie obiektów "encyjnych" nie przekazuje się bo po co? skoro są po wsze czasy dostępne w repozytorium?)

Temat: We are not OOP programmers anymore

Jarosław Ż.:

Paweł W.:
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.

>

dla mnie - reprezentuje kupujących - jedynym miernikiem "zajebistości" oprogramowania są, poza kosztem wytworzenia, jego koszty rozwoju (np. łączne koszty za pięć lat korzystania z niego), z mojego doświadzenia wynika, że obiektowe (takie prawdziwe SOLID) są najbardziej zajebiste (ale mówię o systemach typowo biznesowych)

http://sourcemaking.com/antipatterns/golden-hammer ;) ?

Mamy teraz w firmie taki program, gdzie top management zaprasza sławy IT coby przelały swą mądrość na resztę programistów. I ostatnio był ten co to opracował to SOLID (nie akronim tylko zasady) - niejaki Robert C. Martin i nawet on podawał przykłady kiedy to rozwiązanie mniej obiektowe jest bardziej "zajebiste". (dla zainteresowanych - była to wariacja bardziej ogólnego problemu http://en.wikipedia.org/wiki/Expression_problem )

Może również i tutaj sens ma pewna epicka odpowiedź - "to zależy" ;)Ten post został edytowany przez Autora dnia 24.09.13 o godzinie 15:27

Temat: We are not OOP programmers anymore

Kwestia przyzwyczajenia/wygody ;)
Akurat couch w tym konkretnym przypadku sie dobrze wpasowal

Paweł Grzegorz K.:

Ł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?Ten post został edytowany przez Autora dnia 24.09.13 o godzinie 15:39

Temat: We are not OOP programmers anymore

Paweł W.:
Mamy teraz w firmie taki program, gdzie top management zaprasza sławy IT coby przelały swą mądrość na resztę programistów. I ostatnio był ten co to opracował to SOLID (nie akronim tylko zasady) - niejaki Robert C. Martin i nawet on podawał przykłady kiedy to rozwiązanie mniej obiektowe jest bardziej "zajebiste". (dla zainteresowanych - była to wariacja bardziej ogólnego problemu http://en.wikipedia.org/wiki/Expression_problem )

Może również i tutaj sens ma pewna epicka odpowiedź - "to zależy" ;)

ja napisałem, że zajebiste są "tanie" a nie te SOLID (SOLID podałem jako pewien wyznacnzik a nie pewnik, i w sumie to może faktycznie uprościłem, bo mam na myśli "zamkniete na zmiany otwarte na rozszerzenia".)

troszkę więcej o tym tu wraz z prostym przykładem:
http://it-consulting.pl/autoinstalator/wordpress/2013/...Ten post został edytowany przez Autora dnia 24.09.13 o godzinie 15:51

Temat: We are not OOP programmers anymore

Jarosław Ż.:

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

bingo

Hm ... to brak "obiektywności" (nie wiem co autor miał na myśli używając tego pojęcia) jest problemem ? ;)

Temat: We are not OOP programmers anymore

Jakub W.:

Jarosław Ż.:

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

bingo

Hm ... to brak "obiektywności" (nie wiem co autor miał na myśli używając tego pojęcia) jest problemem ? ;)

brak obiektywności tak :)

Temat: We are not OOP programmers anymore

Jarosław Ż.:

Jakub W.:

Jarosław Ż.:

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

bingo

Hm ... to brak "obiektywności" (nie wiem co autor miał na myśli używając tego pojęcia) jest problemem ? ;)

brak obiektywności tak :)

O f..! To nie fair. To nie ja, to poprawa pisowni w firefox !!! :)
Wracając do tematu - czy "brak obiektowości" jest problemem ?Ten post został edytowany przez Autora dnia 24.09.13 o godzinie 20:15

Temat: We are not OOP programmers anymore

Jakub W.:
O f..! To nie fair. To nie ja, to poprawa pisowni w firefox !!! :)

OK, przepraszam :)

Wracając do tematu - czy "brak obiektowości" jest problemem ?

to zależy :), jeżeli jest to model odzwierciedlający logikę biznesową to raczej tak, systemy (polecam ogólną teorię systemów) to "zespół obiektów współdziałających" i wbrew temu co niektórzy mówią, "statyczny' model biznesowy w postaci obiektowej jest "najwłaściwszy" bo w 100% naturalny i zrozumiały dla biznesu.

poniżej przykład (to diagram klas UML, stereotypy zamienione na ikony, biznes wciąga to bez problemu):




tu troszkę o tym napisałem w 2011 roku:
http://it-consulting.pl/autoinstalator/wordpress/2013/...

Temat: We are not OOP programmers anymore

O f..! To nie fair. To nie ja, to poprawa pisowni w firefox !!! :)
Wracając do tematu - czy "brak obiektowości" jest problemem ?

Jak kolega wcześniej powiedział "to zależy". Jednak sądząc po dziale J2EE naszym kontekstem są aplikacje mające nieco rozbudowaną logikę biznesową, dlatego "brak obiektowości jest problemem". Jeśli system jest prosty to po co używać Javy, "nie strzela się z armaty do wróbla", (pomijając kwestie nauki języka ).

Niestety prawda jest taka, że w większości nie ma, żadnego modelu. Programista dostaje zadanie, tworzy sobie kawałki jak mu pasuje i dawaj dalej, byle do przodu. System rośnie, po części nie wiadomo co jest gdzie, klasy "utilse" rosną jak grzyby po deszczu, co chwile okazuje się, że zmieniłeś coś w miejscu A a to jeszcze trzeba było w B, do tego połowa encji nie wiadomo do czego służy, itd itd. Na początku jest szybko, ale problem pozostaje, w miarę jak aplikacja rośnie. Krzywa rozwijania aplikacji maleje z każdą iteracją, bo juz w części "core" mamy "mirsz marsz" :/

Ten post został edytowany przez Autora dnia 24.09.13 o godzinie 23:14

Temat: We are not OOP programmers anymore

Łukasz W.:

O f..! To nie fair. To nie ja, to poprawa pisowni w firefox !!! :)
Wracając do tematu - czy "brak obiektowości" jest problemem ?

Jak kolega wcześniej powiedział "to zależy". Jednak sądząc po dziale J2EE naszym kontekstem są aplikacje mające nieco rozbudowaną logikę biznesową, dlatego "brak obiektowości jest problemem".

Dlaczego "brak obiektowości" jest problemem w przypadku rozbudowanej logiki biznesowej ? :)

Niestety prawda jest taka, że w większości nie ma, żadnego modelu. Programista dostaje zadanie, tworzy sobie kawałki jak mu pasuje i dawaj dalej, byle do przodu. System rośnie, po części nie wiadomo co jest gdzie, klasy "utilse" rosną jak grzyby po deszczu, co chwile okazuje się, że zmieniłeś coś w miejscu A a to jeszcze trzeba było w B, do tego połowa encji nie wiadomo do czego służy, itd itd. Na początku jest szybko, ale problem pozostaje, w miarę jak aplikacja rośnie. Krzywa rozwijania aplikacji maleje z każdą iteracją, bo juz w części "core" mamy "mirsz marsz" :/

Yhm - ale to wskazuje, że "problem" polega na tym, że firmy biorące się za realizację złożonych projektów _czasami_ nie wiedzą jak to (realizować) robić.

Temat: We are not OOP programmers anymore

Dlaczego "brak obiektowości" jest problemem w przypadku rozbudowanej logiki biznesowej ? :)

bo jeżeli się złożonego problemu nie podzieli na mniejsze to znacznie trudniej nim zarządzać, to troszkę jak w wojsku: na dowolnym poziomie oficer ma ok. 7 podwładnych z którymi się komunikuje, wyobraź sobie generała który ma wydawać polecenia bezpośrednio to kilkunastu tysięcy żołnierzy a ci konsultują wszystko między sobą , zresztą tak wygląda wiele programów które widywałem ;)

Yhm - ale to wskazuje, że "problem" polega na tym, że firmy biorące się za realizację złożonych projektów _czasami_ nie wiedzą jak to (realizować) robić.

bo to częste zjawisko :)Ten post został edytowany przez Autora dnia 25.09.13 o godzinie 12:19

Temat: We are not OOP programmers anymore

Paweł W.:
Weźmy inny element definicji - "stan".
Jak często taka "Strategia" czy "Fabryka" ma stan?

Nie często, ale mieć może i to w sposób niewidoczny dla używającego. Ponownie dla kontrastu, funkcja w języku czysto funkcyjnym stanu mieć nie może.

Paweł W.:
I wracając do klas anonimowych - oczywiście można tworzyć przy
pomocy implementacji "ad hoc" stworzyć obiekty ze stanem i
jakąś tam uzasadnioną formą tożsamości (tak wspominam coby
się strażnicy definicji znowu nie doczepili) ale czy nie
częściej natrafiamy na taki popularny fragment jak ten poniżej
zaczerpnięty z netu? Czy on ma "stan"?:

 

button.addActionListener(new ActionListener() { 

    public void actionPerformed(ActionEvent e) 

    { 

        // do something. 

    } 

});  

Jeśli "// do something." modyfikuje środowisko zewnętrzne to tak.

Paweł W.:
I oczywiście można się tutaj kłócić, że przecież on ma
jakiś adres w pamięci (chyba) i ma też tożsamość w RAMie.
Ale czy ta tożsamość jest do czegoś w tym przypadku potrzebna?

Jeśli zdecydowałbyś się go z jakiegoś względu dynamicznie usunąć (metoda removeActionListener(ActionListener l)), to by się przydała.Ten post został edytowany przez Autora dnia 25.09.13 o godzinie 13:21

Temat: We are not OOP programmers anymore

.Ten post został edytowany przez Autora dnia 13.08.16 o godzinie 21:37

Temat: We are not OOP programmers anymore

Ok, abyśmy nie odpłynęli za daleko . W pierwszym poście masz podaną definicję "Obiektowości" według Booch 'a
Stan/Tożsamość/Zachowanie (przynajmniej to jedna z tych niewielu dyskusji gdzie pojawia się jakaś definicja) . I wiele mechanizmów używanych w rozwiązaniach nazywanych tu i ówdzie "obiektowymi" ma jakoś w dupie tę definicję - a mimo to sprawdza się.

chyba troszkę temat płynie, paradygmat obiektowy jest prostym zdaniem: model obiektowy systemu to zespół współpracujących obiektów w celu zrealizowania określonego celu (rezultatu). Definicja ta jest zresztą zgodna z definicją systemu w ogólnej teorii systemów (system to zespół elementów współpracujących).

Tak więc potrafię albo nie potrafię zaprojektować coś (np. program) go a potem zaimplementować jako "współpracujące obiekty". Czy to ma sens? ma bardzo głęboki bo pozwala dowolnie złożone zjawisko sprowadzić do skończonej ilości relatywnie prostych obiektów, wraz ze zrozumiem ich funkcji w tej całość.

To czy ktoś sobie z tym radzi czy nie to inna dyskusja... prostym miernikiem "jakości stosowanego OOAD/P" jest to czy kod/pracochłonność przyrasta liniowy czy nie w miarę rozrostu projektu....

Toteż w kontekście wątku nie spinałbym się nad tym czy coś jest OOP czy nie, a bardziej skupiłbym się na racjonalnym zastosowaniu konkretnych mechanizmów z różnych podejść.

racjonalność raczej polega na stworzeniu (zrozumieniu) ideału i ewentualnym świadomym odstępstwom od niego a nie na olaniu ideału (np. z powodu niezrozumienia).

Temat: We are not OOP programmers anymore

Jarosław Ż.:

Toteż w kontekście wątku nie spinałbym się nad tym czy coś jest OOP czy nie, a bardziej skupiłbym się na racjonalnym zastosowaniu konkretnych mechanizmów z różnych podejść.

racjonalność raczej polega na stworzeniu (zrozumieniu) ideału i ewentualnym świadomym odstępstwom od niego a nie na olaniu ideału (np. z powodu niezrozumienia).

Tak

Temat: We are not OOP programmers anymore

Jarosław Ż.:

Dlaczego "brak obiektowości" jest problemem w przypadku rozbudowanej logiki biznesowej ? :)

bo jeżeli się złożonego problemu nie podzieli na mniejsze to znacznie trudniej nim zarządzać,

tylko dlaczego "brak obiektowości" (a jeśli rozumiem intencje twórcy wątku - brak DDD) ma oznaczać problem ? Anemiczny model domeny oznacza tylko tyle, że "logika jest oddzielona od stanu" i nie uważam, żeby to był jakiś "straszny błąd" ponieważ sam, przez ok 2 lata, developowałem duży system oparty właśnie na tej zasadzie i nie miałem z tym żadnego problemu.
Jakakolwiek architektura ma tylko jeden cel - ma być skuteczna; niekoniecznie elegancka.

A tak apropo skuteczności - moim zdaniem problemem nie jest to, że "systemy nie są obiektowe - w domyśle DDD", tylko na tym, że mało która firma potrafi zaplanować rozwój systemu IT. Obecnie 95% (opracowanie własne) software'u robi się "na pałę" (niektórzy wolą określenie -Agile-) co w skrócie oznacza "nie wiemy co, nie wiemy jak, ale jesteśmy zmotywowani więc zrealizujemy projekt". Efekt chyba jest znany.

Najzabawniejsze jest to, że te różne firmy próbują właściwie wszystkiego, żeby robić dobry soft: zmieniają organizację pracy (Agile), organizację kodu (DDD), metody testowania, sposoby motywowania itd .. tylko jakoś nikomu z nie przychodzi do głowy, że właściwie nie wie co (nie wspominając o jak) ostatecznie trzeba zrobić.

to troszkę jak w wojsku: na dowolnym poziomie oficer ma ok. 7 podwładnych z którymi się komunikuje, wyobraź sobie generała który ma wydawać polecenia bezpośrednio to kilkunastu tysięcy żołnierzy a ci konsultują wszystko między sobą , zresztą tak wygląda wiele programów które widywałem ;)

"Proof by analogy is fraud." :)

... ciekawe czy ktoś / kiedyś sprzeda wojsku "Agile / Scrum" ;)

Yhm - ale to wskazuje, że "problem" polega na tym, że firmy biorące się za realizację złożonych projektów _czasami_ nie wiedzą jak to (realizować) robić.

bo to częste zjawisko :)

so true... szkoda tylko, że to samo (tzn. często nie wiedzą jak wybrać dobrego wykonawcę) dotyczy klientów tych firm :\

Temat: We are not OOP programmers anymore

Paweł,

"(...)I ostatnio był ten co to opracował to SOLID (nie akronim tylko zasady) - niejaki Robert C. Martin(...)"

napisałeś, że Uncle Bob Martin opracował SOLID. A co z L-iskov Substitution Principle ?