V aplikaci, na které teď pracuju, se mi teď začaly množit parametry filtračních metod (metoda typu vraťMiZbožíNaZákladěPodmínek(filter1, filter2, …)). Jak se návrh aplikace mění, postupně filtrů a upřesňujících podmínek přibývá.
Z počátku se to dalo vydržet, hlavně díky funkci Eclipse, která se jmenuje Change Method Signature a přidání parametrů bylo naprosto v pohodě 🙂 Bohužel jsem se nechal zlákat a z dobrého sluhy se stal špatný pán, protože teď mají metody celkem dost parametrů, je tam hodně přetížených metod a přehlednost kódu prudce klesá…
Joshua Bloch v knížce Effective java píše o tom, že ve správně navrženém API by metoda měla mít rozumný počet parametrů (tak do pěti, spíše pak 3) a má naprostou pravdu.
Já jsem díky lákavé funkci Change Method Signature přidával parametry, až se stalo že některá metoda měla třeba i deset parametrům, existovalo k ní několik přetížených metod a i tak se volala se spoustou nullů.
Řešení je opět v Blochovi a říká že bychom měli přemýšlet nad tím jak parametry zaobalit do nějaké třídy.
Takže metodu
/** Vrací seznam zboží na základě parametrů */
public Collection vraťSeznamZboží(
String maskaKódu,
int SkupinaID,
int cenaOd,
int cenaDo,
boolean vynechejAkčníZboží,
UživatelInfo uživatel) {
...
}
můžeme nahradit takto
/** Vrací seznam zboží na základě parametrů */
public Collection vraťSeznamZboží(
Omezení omezení, UživatelInfo uživatel) {
...
}
a mnohé se zjednoduší. Rozhodně ubyde přetížených metod a omezení můžeme logicky sdružovat.
Teď k implementaci třídy (nebo lépe interfacu a třídy, ale pro jednoduchost budu implementovat třídu) Omezení.
public class Omezení {
public Omezení odDo(String property, int od, int do) { ... }
public Omezení hodnota(String property, Object hodnota) { ... }
public Omezení maska(String property, String maska) { ... }
....
}
Omezení se pak dá vytvořit např. takto:
Omezení omezení = new Omezení()
.odDo("cena", 0, 20)
.maska("kodZbozi", "A%");