Pojęcie w praktyce
Obecność zależna od warunku
Niektóre elementy pojawiają się tylko dla części użytkowników, danych, etapów albo stanów systemu. Traktowanie ich jako stale obecnych prowadzi do błędnych założeń i trudnych do odtworzenia wyjątków.
Najważniejszy jest warunek aktywacji
Zamiast mówić, że element „czasem jest”, warto wskazać dokładnie, co powoduje jego pojawienie się. Może to być stan, próg, wcześniejsza decyzja, typ danych lub kombinacja kilku cech. Im bardziej jawny warunek, tym łatwiej przewidzieć zachowanie całości.
Warunek powinien dać się sprawdzić bez zgadywania intencji. Jeśli wymaga interpretacji za każdym razem, system będzie zachowywał się niespójnie.
Warunkowy element tworzy ukryte ścieżki
Każda dodatkowa możliwość pojawienia się lub zniknięcia elementu zwiększa liczbę stanów, które trzeba rozważyć. Dlatego szczególnie ważne jest sprawdzenie, co dzieje się przed aktywacją, w jej trakcie i po wyłączeniu.
Częsty błąd polega na poprawnym obsłużeniu momentu pojawienia się, ale pozostawieniu śladów po jego zniknięciu.
Jak ograniczyć nieprzewidywalność
Warto opisać warunek, efekt aktywacji i zachowanie po dezaktywacji jako jedną całość. Dzięki temu użytkownik lub operator nie musi rekonstruować logiki z kilku rozproszonych wyjątków.
Praktyczny rezultat to model, w którym „czasem” zostaje zastąpione konkretnym „kiedy”.