On Apr 15, 5:57 pm, Jędrzej Dudkiewicz <jedrzej.dudkiew...@nospam-
gmail.com> wrote:

> Raczej nie o to chodzi. Ja rozumiem to tak, że masz klasę K, w niej
> metodę M, implementacja metody nie jest pure, czyli np. loguje coś klasą
> L. L używa do synchronizacji S itd, itp. Jeżeli projekt taki jest, to
> faktycznie musisz targać za sobą pół dżungli.

Nie jestem pewny, czy można to tak określić. To nie moja wina, że
jedynym celem działania każdego programu jest modyfikowanie jakiegoś
stanu (jeżeli program nie modyfikuje żadnego stanu, to nie ma po co go
uruchamiać).
Natomiast to, czy logger, semafor, itd. mają być zaszyte w kodzie nie
jest w żaden sposób cechą szczególną OO [*]. Niektórzy starają się to
rozpinać albo wyciągać tego typu zależności poza program (pozdrawiam
miłośników programowania w XMLu), ale tak czy siak jakiś loger musi
być i synchronizacja musi być, itd. - czyli wyciągnięcie czegoś z kodu
zawsze powoduje, że to coś wylezie gdzie indziej.
Jak przysłowiowa plastelina, którą się ściska w dłoni. :-)

[*] Akurat OO daje narzędzia do tego, żeby te zależności wyciągać,
więc krytykowanie OO za istnienie takich zależności jest szczekaniem
na niewłaściwe drzewo.

> Swoją drogą pytanie, jak to rozwiązać, jest dość ciekawe

Ciekawszym pytaniem jest czy w ogóle trzeba to rozwiązywać. Widziałem
przypadki, gdy adaptery i inne takie rozdmuchiwały projekt i same w
sobie wnosiły nowe zależności (np. konieczność ładowania dodatkowych
bibliotek) a nigdy nie było okazji skorzystać z potencjalnych zalet
ich wprowadzenia. Wtedy jest koszt a nie ma zwrotu z inwestycji.
Pytanie jak to przewidzieć.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com