A.L. wrote:
> On Sun, 17 May 2009 17:21:00 +0100, Bronek Kozicki <b...@s...net>
> wrote:
>
>> 2. ...., dużo invariants
>
> Moge prosic o komentarz?...

invariant , czyli niezmienny elemnt zachowania klasy. Rzecz na której
można polegasć, bo jest zakodowana w projekcie. Np. pole klasy dla
oznaczenia rozmiaru czegoś-tam

int size;

problem: jest kilka innych pól, np.

int size_with_wings;
int size_unfold;

itd. Wartości początkowe są podane przez użytkownika albo pochodzą z
innego źródła, i w kodzie jest wymóg że size jest zawsze z najmniejszy z
tych pól. Można po prostu założyć że tak jest i pisać jakby warunek nie
musiał być sprawdzony (to jest klasyczny invariant). Ale, po uważnym
przyjrzeniu się działaniu programu, okazuje się że raz wprowadzony
rozmiar się nigdy nie zmienia (to jest okazja którą trzeba zobaczyć,
albo czasami stworzyć). A jeżeli się zmienia, to ze względu na pełnioną
funkcję, koszt utworzenia nowego obiektu jest zdecydowanie mniejszy od
kosztu sprawdzania rozmiaru za każdym razem, albo kosztu błędu. Co
robimy? Dopisujemy jedno (albo więcej, do innych pól) const.

const int size;

... i inicjalizujemy w liście inicjalizacyjnej konstruktora (jeżeli
wartość trzeba obliczyć to dobrze sprawdzają się statyczne funkcje
prywatne, albo współdzielone przez klasę i jej użytkowników "utility
functions"; jeżeli trzeba sprawdzić, to oczywiście wyjątki wyrzuca się w
konstruktorze).

W ten sposób mamy invariant zapisany w projekcie

Podobnie : wartości całkowite o specjalnym znaczeniu zapisujemy w enum
(nie #define) bo w ten sposób typesystem możne nam podpowiedzieć czy
stosowane są w dobrym (czy złym) kontekście. Podobnie : stosujemy
referencje zamiast wskaźników (invariantem staje się wybór obiektu do
któego referencja się odnosi), itd. Czyli zmniejszamy ilość kodu
wykonywanego przez CPU (którym można dokonać zmiany wartości/trezba
sprawdzać zgodność wartości z regułami) a zwiększamy ilość kodu
"wykonywanego" tylko przez kompilator - jednocześnie zwiększając
wierność projektu do konretnego zastosowania. Dodatkowa zaleta - taki
kod się łatwo refaktoruje. Jeszcze jedna zaleta - upublicznienie
invariants zapisanych w projekcie powoduje znacznie mniejsze coupling
niż klasyczne pary accesorów get/set , nawet mniejszy niż pojedyncze get
(bez set). Z tego prostego powodu, że łatwiej sprawdzić w jednym
miejscu, tj deklaracje pola klasy (ponieważ jest "const"), że raz
zainicjowane nigdy się nie zmieni, niż szukać w całym kodzie kto,
pośrednio lub bezpośrednio, może modyfikować jego wartość.

OCZYWIŚCIE BEZ PRZESADY. To jest narzędzie, i powinno być stosowane jak
każde inne - jedno z wielu, a nie jedyny młotek w pudle.


B.



--
Remove -trap- when replying. Usun -trap- gdy odpisujesz.