tag:blogger.com,1999:blog-5197374494377847819.post1738674524548736062..comments2024-03-22T22:13:46.650+01:00Comments on Holistycznie o inżynierii oprogramowania: Koszt DostawySławek Sobótkahttp://www.blogger.com/profile/15082577671795313109noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-5197374494377847819.post-20310868661950886142011-06-08T01:08:36.160+02:002011-06-08T01:08:36.160+02:00Co do informacji które-kiedy i kontekstu, to nakre...Co do informacji które-kiedy i kontekstu, to nakreśliłem go wyraźniej w kolejnym poście.<br /><br />Ten post odnosi się do konkretnego przykładu z książki. Natomiast gdy zaczniemy uogólniać to nie jest już tak prosto...<br /><br />Często spotykam się z takim problemem, że mając na początku naiwną wiedzę na temat domeny dodajemy metody do pewnych klas. Później okazuje się, ze aby wykonać pewne obliczenia potrzeba kilku/nastu dodatkowych współpracowników (zwykle paczek danych). Powstaje masakryczny coupling. Wówczas na prawdę lepszy będzie serwis operujący na danych - anemicznych encjach dostarczających wejścia do procedury. Ale to zostało już poruszone w następnym poście.<br /><br />Odnośnie języków to faktycznie - pozwalają na wiele zakładając, ze programista wie co robi:)<br /><br />Można by się nad tym zastanowić... np. jakiś mechanizm constraintów konstrukcyjnych nad składnią języka, które można sobie zdejmować, jeżeli np dostaniemy pozwolenie:)Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-79961512370598954842011-06-08T00:52:08.779+02:002011-06-08T00:52:08.779+02:00Troszkę mi Sławek zabrakło informacji kiedy-które....Troszkę mi Sławek zabrakło informacji kiedy-które. Poczułem jakbyś przedstawił kilka sposobów i powiedział 4. jest zajebiste idzćie i stosujcie je wszyscy. A ja bym mimo wszystko bronił rozwiązań 1. oraz 2. (a trzeciego nie - bo jestem słabym programistą, dziedziczenia nie rozumiem i unikam). Warto zauważyć jaką tu mamy dynamikę przejścia 1. -> 2. -> 3. tzn. przechodzimy od rozwiązań, w których różne logiki są jak najbliżej siebie, a dodać zachowanie należy zmodyfikować strukturę nadrzędną do takich gdzie logiki znajdują się w różnych miejscach a zyskujemy elastyczność dodania nowego zachowania. No i taki też byłby kontekst dla którego poszczególne rozwiązania stosować, czyli... jak z jakichś przyczyn chcesz widzieć wszystko na raz i NIE chcesz, żeby zestaw zachowań był łatwo rozszerzalny to idziesz w stronę 1... jak wprost przeciwnie to się kierujesz w stronę 2. Nie podejmuję się stwierdzenia ile procentowo będzie którego w projektach, natomiast nie warto ze skrzynki narzędziowej wyrzucać paralizatora - też się czasem przyda.<br /><br />A co do Liskov Substition Principle to ja bym nie był taki odważny z tą pewnością zachowania. Z przyczyn mi nieznanych projektanci języków obiektowych ignorują fakt, że LSP może być przestrzegane szczątkowo, jeśli język nie posiada Design by Contract. Mamy tylko i wyłącznie pozór LSP - bo ktoś tam gdzieś napisał "implements". Według mnie brak lub istnienie DbC w języku obietowym jest analogiczne do dynamicznej oraz statycznej typizacji - w tym sensie że bez DbC to ja sobie mogę dla każdej podklasy wymyślić kontrakt jaki mi się podoba i nikt mi nic nie zrobi.Paweł Badeńskihttps://www.blogger.com/profile/02544441831377477201noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-78198415921676636412011-06-01T15:44:12.230+02:002011-06-01T15:44:12.230+02:00@mgruca
Haszmapę też często zastąpisz if-em, np.
...@mgruca<br /><br />Haszmapę też często zastąpisz if-em, np.<br />if(klucz.equals("...")) <br /> return ...<br />else if(klucz.equals("..."))<br /> return ...<br /><br />Każdy algorytm napiszesz za pomocą tylko :=, if, i while (albo rekursji), i stąd wynika tak "moc" if-ów. No tyle że jak można to nie zawsze znaczy że trzeba.Irek Matysiewiczhttps://www.blogger.com/profile/02786161827081997066noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-27354130441734224532011-06-01T13:28:56.441+02:002011-06-01T13:28:56.441+02:00@Łukasz - w wolnej chwili stworzę projekt. Póki co...@Łukasz - w wolnej chwili stworzę projekt. Póki co być może kolejny post, który powstanie dziś wyjaśni kontekst, kiedy może mieć sens Strategia<br /><br />@iirekm<br />Zgadza się, ten przykład jest strywializowany do maksimum i nie widać na nim kontekstu opłacalności.<br /><br />Logika decyzyjna gdzieś w jakiejś (jak zauważył mgruca) musi istnieć, ale w tym przykładzie nic nie widać. Kolejny post nakreśli kontekst.<br /><br />@mgruca<br />Być może opuchlizna wynika z tego, że po prostu złożoność problemu jest taka i prostsza nie będzie.<br />Zawsze można się jednak zastanowić czy aby na pewno wszystkie operacje muszą zajść podczas requestu?<br />Jakimś rozwiązaniem odcinania pobocznej logiki jest generowanie zdarzeń biznesowych, które są obsługiwane na boku, być może nawet w innym wątku - przy okazji porządkowania logiki zyskasz na wydajności:)<br />Możesz zobaczyć na mojej prezentacji o CqRS: <br />http://art-of-software.blogspot.com/2011/03/tydzien-segregacji.html<br /><br />Co do odniesienia do Misko Hevery to będzie więcej w kolejnym poście.Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-28159657549789809192011-06-01T11:35:12.734+02:002011-06-01T11:35:12.734+02:00Niekoniecznie musi być if czy switch w naszych fab...Niekoniecznie musi być if czy switch w naszych fabrykach. Jeśli mamy dziedziczenie / kompozycję jakiegoś rodzaju to fabryka może posiadać Map i jedynie jest get na mapie wywoływany.<br />Nie zawsze to jednak możliwe i generalnie to zgadzam się: całe IOC/DI to przeniesienie wszystkich ifów o kilka poziomów wyżej.<br /><br />To czego dalej nie ustaliłem to jak uniknąć spuchnięcia warstwy services przy dużej ilości interfejsów wstrzykiwanych. W moich projektach niestety puchnie to z racji bardzo wielu ifaców jakie należy wstrzykiwać.<br /><br />A wywołany w tekście Misko Hevery kiedyś stwierdził bardzo mądrą rzecz: klasy powiny być fabrykami albo zawierać logikę. <br />W uproszczeniu - tylko te pierwsze zawierają słowo kluczowe newMichał Grucahttps://www.blogger.com/profile/00672953404604806278noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-64455494726681304592011-06-01T10:31:30.739+02:002011-06-01T10:31:30.739+02:00Ja bym dodał, że z użyciem Strategii też często ma...Ja bym dodał, że z użyciem Strategii też często mamy switcha, tylko gdzieś wyżej, np. w fabryce:<br />OrderIdem utwórzOrderIdem() {<br />switch(jakisParametr){<br />case x: return new OrderItem(new ImplementacjaStrategii1())<br />case y: return new OrderItem(new ImplementacjaStrategii2())<br />}<br />}<br /><br />Strategia to dla mnie nic innego jak if czy switch, tylko przeniesiony za pomocą czegoś w rodzaju 'extract method' gdzie indziej, np. do fabryki.<br />Zresztą podobnie jest we wzorcu Wizytator, tylko tam te ify/switche czy czasem foreach przenoszone są nie do fabryki, tylko do metody/metod 'accept'. <br /><br />Trudno omawiać to na blogu, bo przykłady blogowe muszą być proste by dało się je szybko ogarnąć, ale w prawdziwym kodzie w tak prostej sytuacji jak ta przedstawiona tutaj lepiej chyba dać sobie spokój ze strategią i zostawić te dwa switche. :-)Irek Matysiewiczhttps://www.blogger.com/profile/02786161827081997066noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-90207991219878512452011-06-01T07:39:37.137+02:002011-06-01T07:39:37.137+02:00Mógłbyś przygotować działający projekt, który obra...Mógłbyś przygotować działający projekt, który obrazuje to co opisałeś nt. Strategii ?<br /><br />Zawsze w tego typu opisach brakuje mi całościowego przykładu, aby zobaczyć szczegóły, bo jak to mówią: diabeł tkwi w szczegółach ...Łukasz Lenarthttps://www.blogger.com/profile/16282501546640140356noreply@blogger.com