Z głową na klawiaturze

Wśród ludzi związanych zawodowo z branżą IT dość powszechna jest skłonność do fascynacji szeroko pojętą fantastyką. Jest to ciekawe zjawisko, zwłaszcza że właśnie informatycy (a już szczególnie matematycy i fizycy, z informatykami dzielący miłość do fantastyki) są mimo częstych skłonności introwertycznych ludźmi twardo stąpającymi po ziemi. Mówiąc złośliwie, pokazuje to jak bardzo ludzie związani z nauką czy IT potrafią oddzielić hobby od zawodu…

Zamiłowanie do fantastyki można jeszcze od biedy wytłumaczyć fascynacją nauką i techniką, które leżą u podstaw SF, czyli „science – fiction”. To „science” jest wbrew pozorom czynnikiem krytycznym, stąd czytelnicy SF są wyczuleni na bajkowe wytłumaczenia. SF musi mieć uzasadnienie i koniec. Nieco inaczej ma się rzecz z literaturą Fantasy, gdzie rolę nauki przejmuje magia. Pomimo, że od czasów Tolkiena masa naśladowców rozciągnęła ramy gatunku tak, że ociera się on o gore (vide opowieści o Conanie czy Xenie), to jednak co pewien czas pojawia się autor który rewolucjonizuje gatunek, i pokazuje, że wiele się jeszcze może w nim wydarzyć.

Takim autorem jest chociażby Andrzej Sapkowski, dość dokładnie opisywany przeze mnie w ramach niniejszego bloga. Magia w utworach Sapkowskiego jest naturalną siłą, którą człowiek może pod pewnymi warunkami okiełznać. Takie podejście do magii trochę odziera ją z nimbu tajemniczości, coraz mniej w niej sztuki, a coraz więcej rzemiosła. Z drugiej strony odarcie z nimbu tajemniczości nie oznacza braku możliwości tworzenia sztuki – technologia obróbki drewna jest znana od dawna a narzędzia są coraz to doskonalsze, jednak rzadko się rodzi talent na miarę Wita Stwosza.

Magię wywraca do góry nogami niezawodny Jacek Dukaj w opowiadaniu „Ruch generała”. Magia nie jest dla Dukaja niczym innym, jak skomplikowanym tworem, opierającym się na długotrwałej nauce. Samo tworzenie zaklęć to mozolne łączenie ze sobą podzaklęć i sprawdzanie działania całości. Stworzone pakiety zaklęć obwarowuje się dodatkowymi klątwami, wyzwalanymi przy zajściu określonych okoliczności. Brzmi znajomo? Tak, w „Ruchu generała” zaklęcia się programuje. Tworzący zaklęcie czarodziej pracuje niczym programista, łącząc klątwy w jedną całość dla uzyskania pożądanego efektu. A efekty często przechodzą najśmielsze oczekiwania – odpowiednio silną magią można unieść statek kosmiczny i polecieć nim na inną planetę. Skoro zaś ruch statku zapewnia magia, nic nie stoi na przeszkodzie, aby statek kosmiczny był z drewna.

Świat, w którym rozwój techniki napędzany jest magią jest w pewien sposób podobny do naszego, ale i zarazem inny. Jeśli bowiem magią można stworzyć latające lub jeżdżące maszyny, to po co prowadzić badania nad mechanizmami napędu? Pomimo więc, że można dolecieć za pomocą magii do gwiazd, to szczytem techniki transportu lądowego jest kolej parowa. Nie występuje także efekt skali – Ford model T był tani i produkowany masowo. Tu, żeby się poruszać, potrzebny jest czarodziej, który wykona odpowiednią usługę…

W opowiadaniu Dukaja fascynuje wizja przedstawionego świata, świata który trwa i trwać będzie, świata, w którym zmiana status quo jest niemożliwa. Odpowiednio dbają o to główni bohaterowie – Żelazny Generał, potężny mag, który od kilkuset lat służy królewskiej dynastii Warzhadów oraz Ptak Zdobywca, władca wrogiego imperium. Te dwa kraje de facto trzymając się w szachu skutecznie blokują możliwość zmian. Fabuły zdradzać nie zamierzam, najważniejsze jest właśnie oto dojmujące uczucie, które pozostaje po lekturze: świat w którym magia jest potężna i łatwo dla ludzi dostępna, nigdy nie dokona przełomu technologicznego. Ten świat nigdy nie będzie w pełni egalitarny, bo to właśnie technologia pozwala nam być równymi.

Opowiadanie „Ruch generała” otwiera pierwszy (w tym roku ma się ukazać drugi) tom opowiadań Jacka Dukaja zatytułowany „W kraju niewiernych”.

Jacek Dukaj: opowiadanie “Ruch Generała” z tomu W kraju niewiernych, Wydanie pierwsze: superNOWA, Warszawa 2004 (kolejne wydania - Wydawnictwo Literackie).

Podstawowym wyzwaniem podczas wdrażania jakiejkolwiek nowej technologii informatycznej, jest problem braku wykwalifikowanej siły roboczej. Przeszkolenie pracowników kosztuje, i mimo że informatycy chętnie zgłębiają arkana swej sztuki w czasie wolnym, na przystosowanie się do nowych wyzwań potrzeba czasu.

Z punktu widzenia samych pracowników poznawanie nowej technologii, to okazja do wpisania sobie kolejnego, magicznego, trzyliterowego skrótu w CV. O ile jednak obopólne korzyści pracodawcy i pracownika stają się widoczne po pewnym czasie, o tyle samo wdrożenie nowej technologii kosztuje. Koszt jest tym większy, im bardziej stroma jest krzywa uczenia się.

Trudność nauki wynika przede wszystkim z dwóch czynników. Pierwszym z nim jest trudność, jako immanentna cecha informatyki, drugim jest objętość materiału do poznania. O ile w ostatnich latach trudność jako taka ulega redukcji, dzięki zastosowaniu wszystkich zdobyczy informatyki (od języków programowania wysokiego poziomu począwszy a na metodykach zwinnych skończywszy) o tyle drugi czynnik stanowczo się pogłębia. Skądinąd wzrost ilości materiału jest pochodną radzenia sobie ze złożonością i trudnością informatyki – w języku C# programuje się dużo wygodniej niż w asemblerze 8086, mimo że asembler 8086 posiada zaledwie garść instrukcji, podczas gdy zrobienie czegokolwiek użytecznego w języku C# wymaga znajomości kilkunastu (kilkudziesięciu) klas dostarczanych przez środowisko uruchomieniowe.

Tendencja ta jeszcze bardziej widoczna jest w przypadku Javy – o ile sam język ma raczej banalną składnię, mogącą sprawiać trudność jedynie komuś, kto programować w ogóle nie umie, o tyle sama znajomość składni Javy nie daje właściwie nic. Ciężko jest wręcz napisać cokolwiek, bez znajomości nie tyle kilku standardowych klas, ile któregoś z używanych powszechnie frameworków. Dobre opanowanie danego frameworka wymagać może drastycznie więcej czasu niż nauka samego języka…

Podobna tendencja zaczyna się powoli pojawiać w ekosystemie Microsoftu. Rozbudowane biblioteki klas zaczynają grać coraz większą rolę w tworzeniu systemów dedykowanych platformie .NET. Jedną z takich bibliotek, jest dzieło firmy DevExpress (kiedyś nazywanej Developers Express, ponieważ jednak złożenie obu tych słów zawiera w sobie podciąg „sex”, ich strona internetowa była często blokowana przez firmy, więc aby nie tracić klientów nazwa się zmieniła). Historia DevExpress sięga czasów wczesnego Delphi, które zdobywać zaczęło popularność w latach 90tcyh. Delphi, narzędzie znakomicie sprawdzające się do tworzenia desktopowych klientów do systemów bazodanowych właściwie do dzisiaj nie dorobiło się podstawowego wydawało by się komponentu do pracy z danymi – grida. Lukę na rynku próbowało zapełnić wiele firm, jednak de facto tylko Quantum Grid z DevExpress stał się standardem przemysłowym, a samej firmie pozwolił się rozwinąć. Nic dziwnego , że kiedy pojawił się .NET, w siedzibie DevExpress zdecydowano się na budowę produktów także dla tej platformy.

Obecnie najciekawszą linią produktową w ramach bibliotek DevExpress są komponenty dla środowiska ASP.NET. Wybór jest dość szeroki – od rozbudowanych kontrolek edycyjnych, poprzez wszelkiego rodzaju wskaźniki, kalendarze, wykresy, raporty a na zaawansowanych gridach skończywszy. Biblioteka jest ogromna i częściowe opanowanie jej elementów pochłania olbrzymią ilość czasu. W ramach ułatwienia tego zadania Paul Kimmel napisał książkę pod wszystko mówiącym tytułem „Professional DevExpress ASP.NET Controls”.

Książkę można podsumować wprost: perfekcyjnie spełnia swoje zdanie. Dzięki temu podręcznikowi można programistę ASP.NET wyszkolić w obsłudze biblioteki DevExpress w bardzo krótkim czasie. Czas ten jest radykalnie krótszy od czasu koniecznego do samodzielnego opanowania materiału, pomimo że zarówno pomoc jak i przykładowe zastosowania na stronach DevExpress są przygotowane rewelacyjnie. Bardzo przyjemne są wstępy do rozdziałów gdzie autor stara się napisać coś o sobie lub od siebie, aby na jakimś życiowym przykładzie omówić jakąś cechę opisywanej biblioteki. Być może niektórzy czytelnicy będą tym rozdrażnieni, osobiście lubię kiedy w książce pojawia się takie „oczyszczenie atmosfery”.

W książce omówiono podstawowe technologie związane z biblioteką komponentów ASP.NET – począwszy od omówienia ASPxGridView (grida), poprzez ASPxTreeList (drzewo), komponenty nawigacyjne (menu, chmury, listy newsów, etc), komponenty do edycji danych (ORM i kontrolki) a na zastosowaniu Ajaxu skończywszy. Uzupełnieniem są rozdziały zawierające informacje dodatkowe oraz ciekawe porównanie filozofii aplikacji webowej i aplikacji klasy desktop.

Książka niestety ma minusy. Minusem podstawowym jest … objętość bibliotek DevExpress. Po przeczytaniu 600 stron ma się sporą wiedzę odnośnie komponentów ją tworzących, jednak po paru miesiącach pracy z kontrolkami ma się wiedzę większą. Niestety, wtedy już nie ma co czytać…

Pomimo tych mankamentów książkę można z czystym sercem polecić wszystkim chcącym rozpocząć swoją przygodę z DevExpress.

Paul T. Kimmel Professional DevExpress ASP.NET Controls, Wrox, Indianapolis 2009

Dwadzieścia lat temu pewien weterynarz w średnim wieku wsiadł w Krakowie do autobusu miejskiego i zobaczył cudowną kobietę. Nie byłoby w tym nic dziwnego, wszak codziennie w Krakowie do autobusów miejskich wsiadają tysiące pasażerów i zapewne jest wśród nich co najmniej kilku weterynarzy w średnim wieku. Pięknych kobiet w autobusach także nie brakuje, jednak tym co różni naszą codzienność od podróży doktora Kohoutka, jest nie tylko brak linii pospiesznej A, skasowanej wiele lat temu, ale i dalszy ciąg zaczynającej się właśnie w ten sposób historii…

Gdyby chcieć być kronikarzem chronologicznym, wypadałoby się cofnąć całe pokolenia Kohoutków wstecz, opowiedzieć historię wielkiej rzeźni i każdego kolejnego małżeństwa budującego ród, wyjaśnić dlaczego dobrzy protestanci nie umierają w zimie aby w końcu dotrzeć do doktora weterynarii Pawła Kohoutka, wiślańskiego – nie bójmy się tego określenia – jebaki, który na swoje łowy wymyka się do Krakowa. Tam poznaje kolejne swoje Aktualne Kobiety, jednak pech chce, że jedna z nich pakuje swoje rzeczy i wyjeżdża na zawsze do Wisły, aby tam spędzić życie z Kohoutkiem. Pomysł okazuje się być całkiem sensowny, jednakże Kohoutek boi się reakcji domowników: Omy, Matki Kohoutka, Ojca Kohoutka, Pastora, Pastorowej, Żony Kohoutka i nigdy nie określonego w książce pod kątem płci Dziecka Kohoutka.

„Inne rozkosze” reprezentują dość wczesny okres w twórczości Jerzego Pilcha. Nieco później zaczyna razić jego żonglowanie tymi samymi postaciami, tymi samymi nazwiskami i w końcu tymi samymi miejscami w Wiśle. Fakt, kontekst zawsze się zmienia, jednak w tym przypadku Wisła i jej uwarunkowania faktycznie zdają się być elementem powieści. Osobiście sięgnąłem po „Inne rozkosze” po przeczytaniu większości powieści Pilcha i uważam tą książkę za jedną z przyjemniejszych pozycji w jego twórczości. Na pewno jest to książka łatwa w odbiorze, można się przy niej pośmiać, niestety przed jednoznacznym zakwalifikowaniem jej do nurtu literatury humorystycznej broni się jej zakończenie, które trudno uznać za szczęśliwe.

Pewnym aspektem, który dla mnie osobiście jest ważny, jest Kraków, który pojawia się jedynie epizodycznie. Bohater poznaje swoją Aktualną Kobietę w autobusie pospiesznym linii A, z którego obserwuje między innymi budowę Hotelu Chopin koło Ronda Mogilskiego. Autobus ten po ruszeniu spod Dworca Głównego jechał nieprzerwanie właśnie do Ronda Mogilskiego, zatrzymując się dopiero na przystanku u wlotu ulicy Kieleckiej. Tam właśnie rozpoczyna się rozmowa bohatera z poznaną kobietą, po której oboje niebawem z autobusu wysiadają. Wysiadać mogli choćby w Czyżynach, albo na mojej rodzinnej Wieczystej. Zarówno miejsca, jak i autobus są dla mnie elementem mojej historii, mojego kresu dzieciństwa i powolnym wkraczaniem w okres nastoletni. Gargantuiczne wnętrze autobusu, to jak nić środek pojazdu Scania 111 - kilka takich (dość mocno wyeksploatowanych) autobusów było w Krakowie na linii A używane po upadku komuny.

Podsumowując – jest to książka, która warto przeczytać. Sto dwadzieścia stron stanowić może dobrą cezurę naszej skłonności do czytania Pilcha – jeśli nie polubimy go po tej powieści, może nie warto sięgać po następne jego książki. Jeśli jednak polubimy jego pijacko – erotyczny styl, nic nie stoi na przeszkodzie, aby poznawać jego twórczość dalej.

Jerzy Pilch: Inne rozkosze, Wydawnictwo a5, Kraków 2004

Kto wymyślił radio – Marconi czy Popow? Zagadnienie to per saldo dla ludzkości ma znaczenie niewielkie, interesują się tym Rosjanie oraz Włosi. Paradoksalnie bycie odkrywcą czegoś, daje największą satysfakcję samemu odkrywcy i gronu jego znajomych bądź krajan. Z perspektywy wszechświata, nie ma to żadnego znaczenia. W każdym kraju równolegle ktoś może wpaść na genialny pomysł. Cóż jednak z tego, jeśli tak naprawdę pierwszy wynalazca danego przedmiotu żył pięć milionów lat wcześniej pod słońcem innej gwiazdy?

Takie problemy stawia przed czytelnikiem Jacek Dukaj w swej mikropowieści „Córka łupieżcy”. Historia dziejąca się w pierwszej połowie XXI wieku już od pierwszej strony kopie czytelnika w twarz. Nagle znajdujemy się w zupełnie innym świecie, świecie który choć całkowicie różny, jest jednak naszym światem. Dla mnie ten obcy świat jest równocześnie całkowicie realnym dzisiejszym światem – krakowski Rynek, ulica Szewska, krakowskie tramwaje, Wieliczka czy wreszcie Beskid Niski. Wille w stylu „późny Gierek” czy koszulki z podobizną Kazika Staszewskiego. To moja codzienność, mimo że w perspektywie 30 lat półnagie dziewczyny z jędrnymi piersiami w towarzystwie opalonych, muskularnych młodych Polaków zmierzają przez rozgrzany do kilkudziesięciu stopni Celsjusza Rynek do elfiej dzielnicy Krakowa.

Technika kopania czytelnika w twarz jest w pewien sposób typowa dla Jacka Dukaja. Może w mniejszym stopniu występują ona w niedawnym „Lodzie” jednak we wcześniejszej jego twórczości już od pierwszej strony wciągani jesteśmy w świat powieści. Autor zwraca się do nas językiem bohaterów powieści, sami bohaterowie nie tłumaczą nam swoich przyzwyczajeń, nie spowiadają się do czego służą gadżety, których używają. Wszak czy my sami biorąc do ręki telefon komórkowy analizujemy głośno jego rozwój w ciągu ostatnich lat? Nie robimy tego, i nie robi tego także Jacek Dukaj – tajemnicze czynności i dziwne przedmioty stają się dla nas zrozumiałe w toku powieści. Paradoksalnie efektem tego jest fakt, że często pierwszy rozdział powieści Dukaja czytam po kilka razy.

Akcja „Córki łupieżcy” dzieje się w Krakowie, pod koniec pierwszej połowy XXI wieku. Rozwój cywilizacji jest niesamowity. Modyfikacje genetyczne zapewniły wszystkim chętnym piękne ciała i wysoką inteligencję. Próg pełnoletniości obniżył się do wieku dziesięciu lat, gdyż dzieci z „Generacji T” szybciej się uczyły i skończenie studiów w wieku lat kilkunastu stało się normą. Technologie produkcji ażurowych i wytrzymałych konstrukcji (zwanych z racji wyglądu „elfimi technologiami”) rozpowszechniły się na tyle, że budowa domu trwa zaledwie kilka dni. Wszechobecna, zdawało by się że przecząca prawom fizyki obecność ogólnoświatowej sieci, nie działającej jedynie w ramach komputerów, ale i w ramach istot żywych nikogo już nie dziwi.

Z tego wyścigu nowoczesności wyłamywali się niektórzy mieszkańcy wsi. Życie płynęło dla nich jak dawniej – z tym że zmieniony klimat zabijał ich swoim gorącem. Wyludnione wsie, upadłe PGRy (mimo że Dukaj wprost nie pisze o jaki rejon chodzi, to owe karpackie PGRy wskazują raczej na Beskid Niski) są dla Generacji T nową „ziemią nieodkrytą”. Polaryzacja społeczeństwa jest dość duża, w efekcie niekiedy „miastowi i nowocześni” nie zauważają nawet mieszkańców wsi, nawet jeśli mieszkańcem tym jest młody chłopak w koszulce z hologramem zespołu Kult (jest trochę racji doborze zespołu – mało który zespół trwając tak jednoczy młodych i starych jak Kult).

W tym nowoczesnym świecie Zuzanna Klajn w dzień swoich osiemnastych urodzin otrzymuje prezent od swojego zmarłego ojca. Skrupulatnie zaplanowany mechanizm prawny przekazuje jej tajemniczą szkatułkę. Cóż ciekawego może przekazać swojej córce archeolog , teoretycznie najnudniejszy człowiek na świecie?

Tylko że… wszystko już było. Królową nauk jest archeologia. Czy ma sens trudzenie się nad rozszyfrowaniem zagadek natury, skoro archeolodzy odkopią rozwiązanie owych zagadek, zanim w ogóle badania zdążą się posunąć w kierunku rozwiązania? W ziemi jest odpowiedź na każde pytanie naukowców, każdy wynalazek, jaki może przyjść nam do głowy… To archeolodzy kierują ludzkość na nowe tory…

Zuzanna w prezencie od swojego rodziciela odkrywa coś, co na zawsze zmieni jej życie. Zabierze nas ona w „podróż życia”, zobaczymy rzeczy, o których się nam nie śniło. Na końcu dowiemy się, że – jak zwykle – istnieją „oni”. Oni, którzy zawsze knują tajne spiski.

Niedawno przeczytałem wywiad z Jackiem Dukajem, w którym stwierdził on, iż powieści w stylu „Córki łupieżcy” mógłby produkować taśmowo. Miał też do tej mikropowieści stosunek raczej chłodny, zaliczając ją do mniej udanej części swojej twórczości. Nie mogę się z tym zgodzić – każdy mający choć odrobinę pokory twórca patrząc na swoje wcześniejsze dzieła jest z nich raczej niezadowolony. Jest to jednak etap, który trzeba przejść –bez „Córki łupieżcy” nie byłoby „Lodu”. Niezadowolenie musi istnieć – to nie jest cecha li tylko literatów. To samo będą czuć wszyscy twórcy, nawet ci, których twórczość nie zalicza się do kręgu literatury i sztuki, na przykład programiści. To uniwersalna cecha procesu twórczego.

Warto przeczytać „Córkę łupieżcy” także dla odkrywanych drobnych smaczków. Bogowie w tej książce są złośliwi i czytają Philipa K. Dicka – stąd Wysoki Zamek, czy tabletki ubika. Złośliwy jest także sam Dukaj – matka Zuzanny została ochrzczona w wierze „rydzykowców”, zaś elegancki model BMW nosi nazwę „Arafat”. Przytyków Dukaja do naszej rzeczywistości jest oczywiście dużo więcej, wszak kulturowo bohaterowie należą do naszej rzeczywistości. Niektóre z motywów świata są jedynie nieco przetworzonymi elementami naszego świata. Czyż zresztą mogło by być inaczej? Wszak wszystko już było…

Jacek Dukaj: Córka łupieżcy, Wydawnictwo Literackie, Kraków 2009

W swej znakomitej książce „Code Complete” Steven McConnell rozważa między innymi pojęcie kohezji.  W dużym skrócie – kohezja jest miarą „spoistości” danego modułu, klasy lub funkcji. Im większa kohezja – tym mocniej dana funkcja (klasa, moduł) zorientowana jest na realizację jednego, konkretnego zadania. Perfekcyjnie kohezyjną funkcją jest funkcja sin(), spotykana w wielu językach i licząca sinus z danej wartości. Służy ona do liczenia sinusa i nie ma żadnych efektów ubocznych ani dodatkowego działania. Podobną kohezją cechują się funkcje zwane geterami lub seterami – ich zadaniem jest zwrócić, lub ustawić odpowiednią wartość zapewniając odpowiedni poziom bezpieczeństwa.

W naturze spotka się wiele rodzajów kohezji – od najsilniejszej, funkcjonalnej, gdzie działanie danej funkcji jest ściśle podporządkowane temu, co ma ona uczynić, aż po kohezję przypadkową, którego to terminu nie trzeba chyba wyjaśniać. Istnieje wiele kohezji dobrych (np. kohezja sekwencyjna, występująca wtedy, gdy ważna jest kolejność operacji, które w innej kolejności nie mają sensu), jak i złych. Jedną ze złych kohezji jest kohezja logiczna.

Podstawową ideą kohezji logicznej jest tworzenie funkcji, które wykonują różne zadania, w zależności od przesłanej do nich flagi. Wykonywane funkcje są średnio ze sobą związane, ot najważniejsza jest owa sterująca flaga. McConnell uważa taki rodzaj kohezji za generalnie nieakceptowany.

Pomimo, że generalnie zgadzam się z McConnellem, to jednak dochodzę do wniosku, że myli się on w tej sprawie. Z jednej strony mamy bowiem czystość kodu, z drugiej zaś jego użyteczność. Przypomina mi to sytuację, gdy miałem w funkcji obsługi zdarzenia kod, który w pewnym momencie prosił użytkownika o potwierdzenie. Jakiś czas później musiałem zautomatyzować tą formatkę zapewniając funkcję, która wykona to samo co wspomniana obsługa zdarzenia, klikając „Tak” na zadawane w niej pytanie. Rozwiązaniem problemu był refaktoring kodu obsługującego zdarzenie do nowej funkcji, która otrzymała dodatkowy parametr mówiący czy pokazywać potwierdzenie, czy domyślnie zakładać kliknięcie „Tak”. Funkcja nazywała się InternalSelectItem i jej wywołanie występowało zarówno w obsłudze zdarzenia OnSelectItem (parametr mówiący o potwierdzeniu miał wartość TRUE), oraz w obsłudze automatycznej, gdzie z kolei parametr miał wartość FALSE (dłuższą dyskusję można znaleźć na stackoverlow.com).

Z drugiej strony niedawno w swej pracy stanąłem przed zadaniem dodania kilku funkcjonalności na istniejącej formatce. Formatka prezentowała różne rodzaje bytów („itemów”) które mogły być klasyfikowane na różne sposoby. Istniała cała masa możliwych zmian klasyfikacji dostępnych z menu kontekstowego. Użytkownik zaznaczał sobie dane, które chciał zmienić, wybierał z menu kontekstowego co chce zrobić, a system realizował jego życzenie.

Oczywiście zanim dochodziło do wykonania  operacji, użytkownik musiał potwierdzić chęć wykonania, później należało sprawdzić, czy zaznaczono prawidłowe itemy, potem wykonywano operację, a na końcu odświeżano listę. Całość realizowana jest przez poniższy kod (tu w pseudopascalu):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

procedure TMyForm.PerformOperationOnSelected (APerformingQuery: TSomeQuery; AQuestionText: string; ALimitOperationToAssignedOnly, ALimitOperationToIgnoredOnly:boolean);
var
  li:integer;
  lItemId: integer;
  lMustRefresh:boolean;
begin
  if Grid.SelectedRecordCount = 0 then Exit ;
  if MessageDlg(AQuestionText, mtConfirmation, [mbYes, mbNo], 0) = mrNo then Exit;
  lMustRefresh:=false;
  { Iterating selected records }
  for li := 0 to Grid.SelectedRecordCount - 1 do
  begin
    { If not a valid item, use continue to jump to next iteration}
    if NOT Grid.SelectedRecords[ li ].IsValidItem then Continue ;
    if (ALimitOperationToAssignedOnly) then
    begin
      {Use continue to jump to next iteration if unassigned or igonred}
      if (NULL = Grid.SelectedRecords[ li ].Values[ cAssignmentId ]) then Continue;
      if (cIgnored = Grid.SelectedRecords[ li ].Values[cAssignmentId]) then Continue;
    end;
    if (ALimitOperationToIgnoredOnly) then
    begin
      {Use continue to jump to next iteration if assigned or unassigned – ie limit to ignored}
      if (NULL = Grid.SelectedRecords[ li ].Values[ cAssignmentId ]) then Continue;
      if (0 < Grid.SelectedRecords[ li ].Values[cAssignmentId]) then Continue;
    end;
    lItemId:= Grid.SelectedRecords[ li ].Values[ cItemId ] ;
    APerformingQuery.ParamByName(cParamName).AsInteger:= lItemId;
    APerformingQuery.Exeute();
    lMustRefresh:=true;
  end ;
  if (lMustRefresh) then acRefresh.Execute();
end;

Cóż tu się dzieje? Ano najpierw mamy pytanie do użytkownika, następnie sprawdzenie które Itemy są w ogóle właściwe do przetwarzania (może się okazać, że część wpisów to jedynie wpisy grupujące). Dopiero później w pętli dokonywane jest sprawdzenie każdego itemu na okoliczność pasowania do flagi sterującej i jeśli w wyniku sprawdzenia nie zostaniemy skierowani na następną iterację, dokonywana jest właściwa operacja za pomocą obiektu APerformingQuery przekazywanego jako parametr. Procedura dodatkowo sprawdza, czy faktycznie dokonała jakiś operacji, i wywołuje obiekt odświeżający GUI.Jest to klasyczny przykład kohezji logicznej: nie dość, że flagami sterującymi znacząco zmieniamy zbiór itemów wchodzących w zakres działania procedury, to jeszcze sam sens działania – obiekt wykonujący działanie również jest przekazywany jako parametr! Jedyne, w czym się procedura owa broni, to tekst komunikatu dla użytkownika, przekazany jako parametr – to może mieć sens choćby ze względu na możliwość zmiany języka.

Pozostaje zadać sobie pytanie, czy kod ten jest zły? Cóż, niewielka separacja logiki biznesowej od logiki interfejsu może jednak razić. Jednak biorąc pod uwagę, iż faktyczna logika biznesowa ukryta jest w obiekcie wykonującym rzeczywiste działanie, sprawa przestaje wyglądać tak brzydko.

Śmierdzą trochę flagi sterujące, ale… czyż bez nich nie byłoby konieczne implementowanie kilku różnych procedur, do obsługi każdego elementu interfejsu użytkownika z osobna? Kohezja logiczna,  mimo że generalnie niezbyt akceptowalna, potrafi czasem pomóc nam, zmniejszając ilość kodu obsługującego interfejs użytkownika i drastycznie zmniejszając ilość punktów styku logiki interfejsu i logiki biznesowej.