tag:blogger.com,1999:blog-5197374494377847819.post3801766995599661525..comments2024-03-22T22:13:46.650+01:00Comments on Holistycznie o inżynierii oprogramowania: Object Oriented czy jedynie Class Oriented?Sławek Sobótkahttp://www.blogger.com/profile/15082577671795313109noreply@blogger.comBlogger23125tag:blogger.com,1999:blog-5197374494377847819.post-53431494879585070032010-06-05T20:06:15.009+02:002010-06-05T20:06:15.009+02:00My tu sobie pierniczymy coby teoretycznie było gdy...My tu sobie pierniczymy coby teoretycznie było gdyby... Z samą teorią daleko się nie zajedzie.<br />Znacie jakieś dobre, praktyczne, opensourcowe przykłady kodu, większe niż helloworld, napisane z użyciem mixinów i/lub traitów i/lub DCI?<br />Jeden przykład lepszy niż tysiąc postów. :-)<br /><br />Odnośnie Scali - podobają mi się niektóre ficzery tam wprowadzone, ale jestem do niej sceptycznie nastawiony bo integracja z IDE jest dla Scali gorsza niż dla Javy (a przynajmniej tak było z rok temu jak próbowałem coś w Scali napisać). Wolę napisać trochę więcej 'boilerplate code', ale mieć przynajmniej zajebiaszcze wsparcie do refaktoryzacji, narzędzia jak EMMA, Checkstyle, Findbugs i podobne. <br />Jeśli społeczność Scali twierdzi, że ich język jest taki superzajebiaszczy, to niech to udowodnią: Niech na przykład za jego pomocą napiszą pluginy do IDE dorównujące lub przewyższające jakością pluginy do Javy.Irek Matysiewiczhttps://www.blogger.com/profile/02786161827081997066noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-53552074116667666692010-06-04T18:26:13.993+02:002010-06-04T18:26:13.993+02:00@oodventurer akurat podejście Twoje i Pawła B. bar...@oodventurer akurat podejście Twoje i Pawła B. bardziej mi pochodzi pod podejście writera.<br /><br />Sam też jestem zdania, że o ile wszystko można i tak zrobić w assmeblerze czy bytecodzie to jednak nie o to się rozchodzi. Chodzi o konstrukcje, które wspierają siłę wyrazu dla mentalnych modeli.Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-45566626586093580722010-06-04T17:41:40.641+02:002010-06-04T17:41:40.641+02:00@Sławek
> http://art-of-software.blogspot.com/2...@Sławek<br />> http://art-of-software.blogspot.com/2010/05/konstruktor-destruktor.html<br /><br />Eh... :( Tyle starań o utrzymanie wizerunku "writera" na marne. Zdemaskowałeś mnie ;)<br /><br />A na poważnie, ciekawa mogłaby być dyskusja, jakie cechy obu rozwiązań lepiej wyrażają wartości (readable, minimal, self-documenting, expressive) z <a href="http://blog.solidcraft.eu/2010/05/writer-versus-constructor.html" rel="nofollow">artykułu Jakuba</a>?<br /><br /><i> < dygresja historyczna > </i><br />Przed Javą 1.5 bardziej świadomi programiści posługiwali się wzorcem typesafe enum. Od Javy 1.5 stało się to w większości wypadków zbędne, dzięki nowemu słowu kluczowemu. Analogicznie, większość użyć iteratora w pętlach ludzie zaczęli zastępować rozszerzoną składnią pętli for.<br /><i> < /dygresja historyczna > </i><br /><br />Czy jest to pogoń za nowinkami? Nie. Czy zmniejsza to czytelność i zrozumiałość kodu? Wręcz przeciwnie.<br />Identycznie jest z traitami Scali. Enumy nie są wolne od wad (sam czasem wybieram stary typesafe enum pattern z modyfikacjami), traity także nie są idealne. Kluczem jest umiejętność dokonania właściwej oceny, kiedy zastosować dane rozwiązanie.<br /><br />@iirekm<br />Fakt, liberalne używanie traitów niesie ze sobą zagrożenie namespace pollution. Jest to jednak trochę jak z nożem: można pokroić chleb, a można się zranić. <a href="http://www.youtube.com/watch?v=IKmQW7JTb6s" rel="nofollow">With great power comes great responsibility</a>. Gdy klasa w Javie implementuje wiele interfejsów (pośrednio lub bezpośrednio), problem zanieczyszczenia przestrzeni nazw też wystąpi. Przy korzystaniu z delegacji objętość boilerplate'u będzie jednak bardziej kłuć w oczy i być może odwiedzie niektórych od złych wyborów (nie da im się zranić). Zakłuje niestety też w przypadkach, gdy mixin jest idealnym rozwiązaniem (ciężko pokroić chleb).Anonymoushttps://www.blogger.com/profile/08968963615797084668noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-54618516757089356202010-06-03T15:57:09.228+02:002010-06-03T15:57:09.228+02:00nowa porcja informacji o DCI: http://www.infoq.com...nowa porcja informacji o DCI: http://www.infoq.com/interviews/coplien-dci-architectureSławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-58321679879359176572010-06-01T18:34:58.194+02:002010-06-01T18:34:58.194+02:00Z tego co widzę, to na problem można patrzeć z ró...Z tego co widzę, to na problem można patrzeć z różnych perspektyw, np pod względem pisania/konstruowania: http://art-of-software.blogspot.com/2010/05/konstruktor-destruktor.htmlSławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-16133866864846164822010-06-01T16:24:12.809+02:002010-06-01T16:24:12.809+02:00Odwołuję się do tego artykułu:
http://scg.unibe.ch...Odwołuję się do tego artykułu:<br />http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf<br /><br />Dobrze napisany mixin to trait. Zasadnicza różnica jest taka, że trait nie zawiera stanu (stąd ten abstract getAnimal() zamiast pola private Animal animal ).<br /><br />'glue code' to własnie implementacja tej metody: public void getAnimal() { return this; }<br />W większości przypadków kompilator nie byłby na tyle mądry by taką metodę zaimplementować.<br /><br />Zaletą Scalowego:<br />class Bat extends Mammal with Flying {<br /> def getAnimal = this<br />}<br />... jest mniej pisania (ale tak czy owak musisz napisać to 'glue code'). Wadą - potencjalne konflikty. Co by było jakbyśmy mieli 'A extends B with C with D', i gdyby było do zaimplementowania 'C.getCośtam()' i 'D.getCośtam()' - ta sama nazwa a zupełnie różne przeznaczenia.<br />Takie konflikty raczej nie zdarzają się przy 'normalnych' klasach, bo każda klasa zna swoją nadklasę i wie jakie nazwy zostały użyte, ale mogą zdarzać się tu - trait nie zna swojego miejsca w hierarchii klas.<br />Stosując strategię czy template method takie konflikty rozwiążesz łatwo - każda strategia czy klasa szablonowa jest w sama w sobie osobnym 'namespacem'. W rozwiązaniu opartym na dziedziczeniu (jak w Scali) wszystko jest pakowane do jednego worka i zaczynają się kłopoty.<br /><br />O zaśmiecaniu namespace'a klasy przez mixiny trochę piszą tu:<br />http://www.artima.com/weblogs/viewpost.jsp?thread=246483<br /><br />Ogólnie: mixiny typu 'Scalowego' czy 'Pythonowego' nadużywają dziedziczenia, a jak wiadomo w przypadku kodu większych rozmiarów, dziedziczenie jest paskudne.Irek Matysiewiczhttps://www.blogger.com/profile/02786161827081997066noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-82640609257121837852010-05-31T23:29:31.472+02:002010-05-31T23:29:31.472+02:00@iirekm
Napisałeś: "...dobrze napisane mixiny...@iirekm<br />Napisałeś: "...dobrze napisane mixiny (=traity) wymagają wiele tzw. 'glue code', a tego za programistę kompilator nie zrobi". Co rozumiesz pod słowami "dobrze napisane" i "glue code"?<br /><br />Jeśli dobrze napisany mixin to taki, który umożliwia dynamiczną zmianę zachowania, to można łatwo wykazać zbędność 'glue code'. Napisałem <br /><a href="http://pastebin.com/VEyiFHeV" rel="nofollow">taki</a> przenosząc na Scalę <a href="http://coding-masters.blogspot.com/2010/04/write-reusable-java-code-with-mixins.html" rel="nofollow">Twój przykład oparty na Template Method.</a> Glue code ogranicza się tam do jednej linijki implementacji abstrakcyjnej metody oraz klauzuli with w deklaracji klasy. Nie ma potrzeby generowania metod delegujących wywołania. Trait Flying może więc nabyć np. 16 nowych metod, a klasa Eagle pozostać niezmieniona. To jest bardzo ciekawa cecha traitów w Scali, wydatnie zwiększająca czytelność. Dzięki temu, że trait Flying nie deklaruje "self type" można go miksować z czymkolwiek w dowolnych konfiguracjach bez troszczenia się o linearyzację.Anonymoushttps://www.blogger.com/profile/08968963615797084668noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-3793242266807515652010-05-31T12:44:13.378+02:002010-05-31T12:44:13.378+02:00@Paweł
Nie musimy chyba biernie oczekiwać na ludz...@Paweł<br /><br />Nie musimy chyba biernie oczekiwać na ludzi nauki - do porównania elementów składni można spróbować wykorzystać <a href="http://martinfowler.com/bliki/SyntacticNoise.html" rel="nofollow">artykuł Martina Fowlera</a> <br />akceptując to, że w konkretnych wypadkach mogą pojawić się różnice w ocenach, czy dany element składni zalicza się w tym wypadku do szumu.Anonymoushttps://www.blogger.com/profile/08968963615797084668noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-14369372329708145752010-05-30T16:57:59.600+02:002010-05-30T16:57:59.600+02:00O tym co piszesz to nie wiem czy są jakieś akademi...O tym co piszesz to nie wiem czy są jakieś akademickie artykuły, ale są np. o mixinach i traitach:<br />http://scg.unibe.ch/research/traitsIrek Matysiewiczhttps://www.blogger.com/profile/02786161827081997066noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-56137645726480696002010-05-30T13:24:34.703+02:002010-05-30T13:24:34.703+02:00W sprawie pierwszej kwestii powtórzę tylko, że tu ...W sprawie pierwszej kwestii powtórzę tylko, że tu nie o to chodzi, że to się da tylko w jaki sposób to zmienia postrzeganie struktury modelu (myślę o czymś w kontekście Naurowego "programming as theory building"). Zresztą np. foo with A with B już tak prosto nie zrobisz. Nasza dyskusja utwierdza mnie w przekonaniu, że bez jakiegoś sensownego modelu do porównywania struktur języka daleko się nie ruszymy. Z tego co patrzyłem ostatnia praca o zbliżonej tematyce jest z roku '93, więc ponawiam apel do ludzi nauki (i studentów :P).Paweł Badeńskihttps://www.blogger.com/profile/02544441831377477201noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-32401766496225724632010-05-28T15:23:37.818+02:002010-05-28T15:23:37.818+02:00>>>> Po wywołaniu "foo with SomeB...>>>> Po wywołaniu "foo with SomeBehaviour" obiekt potrafiłby odbierać więcej komunikatów niż sam "foo" <<<<<br />Masz na myśli dodawanie metod do już utworzonych obiektów? <br />new SomeBehaviour(foo) - klasa SomeBehaviour zawiara dodatkowe metody dla foo. Na dodawanie nowych metod do już istniejących obiektów pozwala wzorzec Visitor (choć szczególnie go nie lubię). Może też wystarczyć 'cwany utils':<br />void SomeBehaviour.nowaMetoda(Foo foo, parametry...)<br /><br /><br />>>>> Większość GPL jest Turing-complete, ale chyba nie o to chodzi ;) <<<<<br />są elementy języka które są bardzo użyteczne i zaoszczędzają wielu kłopotów, klepania i poprawiają jakość kodu (np. pamięć zarządzana przez GC, klasy, generyki, adnotacje, closures, LINQ, foreach, ...), są też elementy które niewiele wnoszą, lub wręcz sprawiają problemy i do tego niepotrzebnie komplikują język (wielokrotne dziedziczenie, większość 'cwanych' rzeczy które są w Groovym czy w Perlu, duck typing, yield z C#, preprocesor)<br />ja bym mixiny raczej zaliczył do tych, które niewiele wnoszą - nie są obowiązkowe w składni języka; dobrze napisane mixiny (=traity) wymagają wiele tzw. 'glue code', a tego za programistę kompilator nie zrobiIrek Matysiewiczhttps://www.blogger.com/profile/02786161827081997066noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-87192464606691149242010-05-28T10:08:27.477+02:002010-05-28T10:08:27.477+02:00Dynamicznego podpinania zachowania, a nie dynamicz...Dynamicznego podpinania zachowania, a nie dynamicznej zmiany zachowania. Może zbyt lakonicznie przedstawiłem pomysł. Mówię o dynamicznym (czyli de facto kontekstowym i tymczasowym) rozszerzeniu interfejsu obiektu. Po wywołaniu "foo with SomeBehaviour" obiekt potrafiłby odbierać więcej komunikatów niż sam "foo". Trudno tu znaleźć analogię z istniejącym wzorcem, zwłaszcza na poziomie filozofii mechanizmu.<br /><br />Wracając do mixinów, to przedstawiłeś argument "dlatego jestem raczej przeciwny mixinom jako elementom języków programowania - wystarczy wiedzieć jak robić 'mixiny' za pomocą strategii czy template method", którą pozwolę sobie uogólnić jako "dlatego jestem raczej przeciwny XXX jako elementom języków programowania - wystarczy wiedzieć jak robić XXX za pomocą YYY". Większość GPL jest Turing-complete, ale chyba nie o to chodzi ;) Niefajnie, że nie posiadamy metodyki porównywania mechanizmów języków (jeśli czyta to jakiś student - temat na mgr :P), bo w takich przypadkach jak ten na ogół wszyscy pokazują "czy XXX w A da się zrobić w B". A pozostaje chociażby kwestia złożoności poznawczej czy kosztów pielęgnacji (prawdopodobnie etc.).Paweł Badeńskihttps://www.blogger.com/profile/02544441831377477201noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-73043622998674039882010-05-27T18:55:26.065+02:002010-05-27T18:55:26.065+02:00>>>> mi osobiście jeszcze brakuje zupe...>>>> mi osobiście jeszcze brakuje zupełnego oddzielenia warstwy danych od zachowania, czyli możliwości dynamicznego podpinana zachowania pod jakąś klasę (dla osób znających Scalę: "var a = new A; foo(a with SomeBehaviour)") <<<<<br /><br />hehe, dynamiczne podpinanie zachowania to przecież wzorzec Strategy :-)<br />fakt, strategia wymaga ciut więcej roboty niż np. mixiny (traity) w Scali, ale uważam że się opłaca, bo to tylko CIUT więcej roboty, a zysk ogromny, np. owa dynamiczna zmiana<br /><br />dlatego jestem raczej przeciwny mixinom jako elementom języków programowania - wystarczy wiedzieć jak robić 'mixiny' za pomocą strategii czy template method<br /><br />luknij tu:<br />- http://coding-masters.blogspot.com/2010/04/write-reusable-java-code-with-mixins.html<br />- http://coding-masters.blogspot.com/2010/04/mastering-mixins.htmlIrek Matysiewiczhttps://www.blogger.com/profile/02786161827081997066noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-38577644624534989802010-05-27T12:22:47.378+02:002010-05-27T12:22:47.378+02:00Wygląda to tak, że rzesze programistów twierdzają ...Wygląda to tak, że rzesze programistów twierdzają że znają OO, odwołując się do umiejętności programowania w Javie, C++ czy C#. Tymczasem na przykład po dziś dzień nie powstał (chyba) język, który w równie umiejętny sposób jak Eiffel implementuje Design by Contract (a chodzi mi m. in. o wsparcie zasady podstawienia Liskovej na poziomie semantyki operacji). Przy okazji - dość trudno jest mówić o 100% OO, co Meyer mówi wprost w swojej księdze (przyznacie, że trudno nazwać ją książką :P), a o tym co różni badacze uznają za OO można poczytać u Armstrong (The Quarks of Object-Oriented Development). Część osób może zaciekawić również flame OO w wykonaniu Jonathana Rossa http://www.eros-os.org/pipermail/e-lang/2001-October/005852.html (sugeruję nie zniechęcać się pierwszym na wpół zrozumiałym postem i przeczytać cały wątek). Ogólnie oceniłbym świadomość przemysłu w temacie OO na 3.5 w skali akademickiej, zwłaszcza że duża liczba osób po studiach nie potrafi pisać OO w (sic!) Javie. Cieszę się, że wreszcie ruszamy na przód, zwłaszcza pokładam nadzieję w Scali, która pozwala nam wyjść z obiektowego żłobka.<br /><br />Co do DCI uważam, że to genialny pomysł. Muszę powiedzieć, że chyba z 2 tygodnie chodziłem podjarany jak się o tym dowiedziałem ;D Nie pamiętam jak to wygląda w koncepcji Trygve, ale jeśli chodzi o implementację w Scali, to mi osobiście jeszcze brakuje zupełnego oddzielenia warstwy danych od zachowania, czyli możliwości dynamicznego podpinana zachowania pod jakąś klasę (dla osób znających Scalę: "var a = new A; foo(a with SomeBehaviour)"). Nie wiem jak to działałoby w praktyce, ale uważałbym eksperyment z takim mechanizmem za ciekawy :P<br /><br />P.S. Przepraszam. Temat OO ostatnio stał się moim uzależnieniem ;]Paweł Badeńskihttps://www.blogger.com/profile/02544441831377477201noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-8920102729355246032010-05-26T17:22:10.666+02:002010-05-26T17:22:10.666+02:00hehehe
true, truehehehe<br />true, trueSławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-12851789772165961102010-05-26T16:51:26.926+02:002010-05-26T16:51:26.926+02:00Noo, dobry przykład podobnie jak dobry rysunek był...Noo, dobry przykład podobnie jak dobry rysunek byłby wart więcej niż 1000 słów czy (w sumie) 4 godziny prezentacji o DCI z Oredev 2009. :-)Irek Matysiewiczhttps://www.blogger.com/profile/02786161827081997066noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-54529464000495753222010-05-26T10:20:37.614+02:002010-05-26T10:20:37.614+02:00Racja, bez przykładów możemy błądzić we własnych u...Racja, bez przykładów możemy błądzić we własnych urojeniach;)<br />Zaciekawiło mnie to co piszesz o problemach z mixinami - w wolnej chwili napisz coś więcej.<br /><br />Odnośnie porównań to czegoś innych rzeczy to jest to efektywna technika poznawcza, dopóki nie mamy do czynienia z czymś zupełnie innym/nowym - wówczas takie porównywanie to jeden z typowych błędów kognitywnych. Powoduje uwięzienie umysłu.<br /><br />- Data to owszem warstwa domenowa. Ale w DDD encje, agregaty i VO mają odpowiedzialność biznesową. W DCI dane są "głupie" - może nie aż tak jak w mainstremowym podejściu proceduralnym ponieważ mogą mieć proste, wspólne zachowania. Ale cała logika biznesowa siedzi w Interaction.<br /><br />- Interaction jak pisałem powyżej <br />zawiera logikę biznesową. <br />/*Z tego co rozumiem bo jak uznaliśmy obaj - bez przykładu możemy dryfować. Być może to ja popełniam błąd kognitywny dopasowując DCI do dłasnych wyobrażeń;)*/ Warstwa aplikacji zawiera logikę aplikacji.Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-6204301570064822622010-05-26T01:03:22.060+02:002010-05-26T01:03:22.060+02:00Trudno o tym gadać bez rzeczywistych przykładów - ...Trudno o tym gadać bez rzeczywistych przykładów - niestety na tych prezentacjach prawie nic nie ma, a te co są używają właśnie mixinów. Ponieważ mixiny mogą być upierdliwe (podobnie jak proxy czy dekorator), lepiej używać strategii + AOP.<br />Ale ogólnie, to chyba nic nowego:<br /><br />- data - to obiekty domenowe, np. w stylu DDD. To po prostu warstwa domenowa.<br /><br />- context - wzorce strategia+dependency injection. To strategie powstrzykiwane obiektom domenowym by zmienić ich zachowanie zależnie od kontekstu. Tak naprawdę po to właśnie te wzorce są. Czasami tworzenie strategii byłoby czynnością mechaniczną (np. nakładanie tranzakcji) - wtedy lepiej użyć AOP.<br /><br />- interaction - to wysokopoziomowy kod scalający to wszystko razem - znany jako fasada, warstwa aplikacji czy usecase controller.Irek Matysiewiczhttps://www.blogger.com/profile/02786161827081997066noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-87564269226578096922010-05-26T00:57:32.884+02:002010-05-26T00:57:32.884+02:00Ten komentarz został usunięty przez autora.Irek Matysiewiczhttps://www.blogger.com/profile/02786161827081997066noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-82241737347843258322010-05-26T00:11:02.229+02:002010-05-26T00:11:02.229+02:00Nowe jest zastosowanie niektórych z wymienionych p...Nowe jest zastosowanie niektórych z wymienionych przez Ciebie technik do modelowania domeny.<br /><br />Mixiny zwykle pokazuje się na przykładzie tych nieszczęsnych kolekcji czy Active Record. Pewnie niezbyt szukałem, ale nie znalazłem tak odważnego ich wykorzystania w warstwie logiki. Mało tego - takie podejście mentalne musi być wykorzystywane nie tylko na poziomie developmentu, ale również na poziomie analizy.<br /><br />Wzorce GoF... można wyciągać role do strategii, ale Data musi wiedzieć o Interaction. Aby tego uniknąć weszlibyśmy pewnie w jakieś dekoratory albo paskudne Proxy.<br /><br />AOP - zawsze musisz mieć punk złączenia, który pozwoli na nałożenie porady. Przez co Dane będą sztucznie "obłożone" takimi punktami.<br /><br />Bounded Context - ok jestem w stanie uznać tą odpowiedź... W DDD otworzymy koncepcyjne "wyspy" hermetyzujące strukturę. A globalny model to antywzorzec. W DCI jest odwrodnie - struktura jest globalna. Więc są to diametralnie różne podejścia. Nie czuję się na siłach aby je teraz wartościować - wszystko jak zwykle zależy:)Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-71463538631264561812010-05-25T23:41:12.311+02:002010-05-25T23:41:12.311+02:00Czy jest to takie nowe podejście?
Dużo niepotrzebn...Czy jest to takie nowe podejście?<br />Dużo niepotrzebnego gadania, a tak naprawdę to wszystko sprowadza się do umiejętnego stosowania rzeczy jak mixiny (które lepiej zastąpić wzorcami GoF), AOP czy Bounded Context.Irek Matysiewiczhttps://www.blogger.com/profile/02786161827081997066noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-30284781803600699112010-05-25T16:17:26.587+02:002010-05-25T16:17:26.587+02:0080 lat... nie wygląda... chyba każdy chciałby być ...80 lat... nie wygląda... chyba każdy chciałby być w takim wieku w takie formie umysłowej.<br /><br />Co do jaj, to kiedyś przeglądałem biografię Rickarda Öberga (Qi4j) - założył JBossa, po czym uznał, że EE nie ma sensu:)Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-52114390958048165662010-05-25T08:35:51.810+02:002010-05-25T08:35:51.810+02:00Ten co ma jaja, to autor wzorca MVC (gdzieś z lat ...Ten co ma jaja, to autor wzorca MVC (gdzieś z lat 70tych), aktualnie 80-letni staruszek, więc może sobie pozwolić na innowacje ;-) A tak serio, to niesamowite i godne najwyższego szacunku, że człowiek w tym wieku nie odcina kuponów, tylko wciąż jest kreatywny.<br />Drugi z jajami to Jim Coplien, który znany jest z kontrowersyjnych wypowiedzi (java is a toy language; agile is like a teenagers sex - everybody talks about it, a few really do it; tdd will destroy your application).<br /><br />Pomysł jest faktycznie ciekawy, ale tak jak piszesz zupełnie do javy nie pasuje. Wszelkie łatki w rodzaju Qi4j powodują, że kod staje się mniej czytelny zamiast bardziej. A przecież w OO chodzi m.in. o czytelność.<br /><br />Zainteresowanym dokładniejszym opisem DCI odsyłam do http://www.artima.com/articles/dci_vision.htmlPaweł Lipińskihttps://www.blogger.com/profile/02772675014904905654noreply@blogger.com