Visitor pattern.
Evidentně budete zasahovat do kódu, takže místo přidávání and cp a
boolean to udělat trochu jinak.
(Tady se da udelat i extends ale to se provaze s implementaci)
Extrahovat interface (IfaceA) ze současné struktury (StructA) - a přidat
druhou strukturu (StructB) která implementuje tento interface také
(může i rožšiřovat StructA).
Interface bude mít navíc metodu jako "setResults(ServiceInterface
serviceA)".
A service bude mít selectResult(IfaceA obj) která zavolá
Iface.setResults(this)
StructA.setResults(ServiceInterface service)
{
service.selectResults(this); // v tomhle pripade uz "this" je plne
znamy typ
}
StructB.setResults(ServiceInterface service)
{
service.selectResults(this); // v tomhle pripade uz "this" je plne
znamy typ
}
no a konecne v ServiceInterface bude mit
ServiceInterface.selectResult(Struct A) a
ServiceInterface.selectResult(Struct B)
Takhle nebudete mit zadny if else if else if a v budoucnu pokud pridate
StructC D E F G H
zasahnete kod ServiceInterface. Ono dokonce lze zdetit i
ServiceInterface na ServiceIterfaceCDEF
a v StructCDEF bude mit ServiceIterfaceCDEF - protoze Implementace zna
sebe diky "this" tak to bude dal fungovat.
Testovani: pokud se zavede boolean (N=2) nebo int (N) a to k tomu kazda
dalsi stuktura (M) melo by se napsat NxM testu. Takhle 2xM. Tohle ma
spis ukazat tu vyhodnost.
Karel
A je to refactoring safe. Coz v pripade booleanu nebo intu neni
Naopak OOP bylo vymysleno tak aby se kod funkcni a odzkouseny pouzival
znova a znova a znova.
> > d) pro omezení zbytečného výpočtu statistik v c) přidat do volání API
> > boolean (nebo raději int pro více možných stavů) parametr udávající,
> > zda výpočty volat či nikoli (rozhodování může to být řešeno dědičností
> > konkrétní datové struktury, ale to je pořád onen boolean či int a s
> > ním někde svázaný switch či kupa ifů).
