... aneb snižujte závislosti mezi třídami
Jedna z možných definic návrhového principu Tell, Don't Ask (TDA) zní takto:
"Každé rozhodování zcela závislé na vnitřním stavu objektu by mělo být prováděno uvnitř tohoto objektu."
Princip hovoří o tom, že bychom měli navrhovat třídy tak, aby se volající strana nemusela dotazovat na záležitosti týkající se vnitřního stavu volané třídy.
Ukázka porušení TDA
Mějme zjednodušený autobusový rezervační systém:
class Bus
{
private int numberOfSeats;
private IList<Passenger> passengers = new List<Passenger>();
public Bus(int numberOfSeats)
{
this.numberOfSeats = numberOfSeats;
}
public bool HasFreeSeat
{
get
{
return numberOfSeats > passengers.Count;
}
}
public void AddPassenger(Passenger passenger)
{
passengers.Add(passenger);
}
}
class BusReservation
{
public void AddPassengerToBus(Bus bus, Passenger passenger)
{
if (bus.HasFreeSeat)
{
bus.AddPassenger(passenger);
}
}
}
Proč je uvedené řešení problematické:
- Základním principem OOP je zapouzdřenost interních dat objektu a jeho chování. Třída
Busvšak zbytečně zveřejňuje informaci o volných sedadlech a nutí volající stranu, aby s touto informací pracovala a zohledňovala ji před voláním metodyAddPassenger. - Třída
BusReservationje závislá na tříděBusna dvou místech. Dotazováním na vlastnostHasFreeSeata voláním metodyAddPassenger. Každá nadbytečná závislost mezi třídami zvyšuje komplexitu návrhu a zhoršuje vlastnosti systému. - Třída
Busnutí volající stranu, aby měla znalost o tom, že před zavolánímAddPassengersi musí nejprve sama ověřit splnění kontraktů přidání cestujícího. S tím souvisí i závislost na správném pořadí volání. Samostatné voláníHasFreeSeatnedává smysl. - Co když se v budoucnu změní podmínky, za kterých je možné přidat cestujícího? Nyní je přidání závislé pouze na volném sedadle, ale nově může přibýt podmínka typu
"je autobus pojízdný". Pak bude nutné doplnit test na vlastnost
IsMobilena všechna místa voláníAddPassenger. - Každá nadbytečná závislost zvyšuje komplexitu jednotkových testů. Pokud chceme testovat třídu
BusReservationv izolaci, musíme mockovat tříduBus(nebo lépe rozhraní). V našem problematickém případě musíte přidat chování mocku pro vlastnostHasFreeSeatsa metoduAddPassenger.
Vhodnější řešení
Odstraníme závislost volající třídy na dotazování se na volné sedadlo. Veškeré testy na proveditelnost akce přidání cestujícího jsou zapouzdřeny uvnitř metody
AddPassenger. Pokud některá z podmínek není splněna, je vrácena výjimka, kterou zpracuje volající strana. Volající straně se situace zjednoduší.
class Bus
{
private int numberOfSeats;
private IList<Passenger> passengers = new List<Passenger>();
public Bus(int numberOfSeats)
{
this.numberOfSeats = numberOfSeats;
}
private bool HasFreeSeat
{
get
{
return numberOfSeats > passengers.Count;
}
}
public void AddPassenger(Passenger passenger)
{
bool isFull = !HasFreeSeat;
if (isFull)
{
throw new Exception("Bus is full.");
}
passengers.Add(passenger);
}
}
class BusReservation
{
public void AddPassengerToBus(Bus bus, Passenger passenger)
{
bus.AddPassenger(passenger);
}
}
Vezměte si na pomoc Adapter
Pokud využíváte rozhraní, které nemůžete měnit (komponenta třetí strany) a které porušuje TDA, můžete si pomoci návrhovým vzorem Adapter (Wrapper).
Např. v jazyce C# je za příkazem foreach schován adaptér, který zjednodušuje práci se vším, co zveřejňuje metodu IEnumerator GetEnumerator().
Z IEnumerator pak postupně volá metodu bool MoveNext() a dotazuje se na vlastnost object Current { get; }. Více na stackoverflow.com.
Závěrem
Tak jako většina principů a doporučení objektového návrhu, tak i TDA není možné bez rozmyslu aplikovat dogmaticky ve všech situacích. Záleží na zodpovědnosti navrhované třídy, zda-li poskytuje příkazy (commands) k vykonání nějaké akce nebo dotazy (queries) vracející vnitřní stavy objektu. V případě příkazů byste však měli o dodržování principu TDA usilovat.
