Fabrike, fabrike, svuda oko nas
A šta će ova poruka ovde uopšte? Pa, s obzirom da nema foruma koji se nominalno bavi OO dizajnom, rekoh možda je ovde najprikladnije.
Prvo, imam klasu čija instanca tokom rada koristi objekte nekoliko različitih klasa. Kako bih želeo da korisnik može da menja klase za ove objekte, želeo bih da napravim po jedan factory metod za svaku klasu. Da li je bolje za recimo 3 različita objekta staviti 3 različite nepovezane „fabrike“, ili sve fabrike skupiti u novu klasu preko čijeg interfejsa će se dobijati nove instance?
Drugo, u istoj priči postoji i algoritam koji napravi iterator kroz rečene objekte i nešto radi s njima, poput foreach. Da bih postavio sve u konkretne okvire, zamislite da postoji objekat tipa Graph koji sadrži objekte tipa Vertex i Edge (oni se prave gorepomenutim fabrikama).
Recimo da imam iterator koji omogućava korisniku da se prošeta kroz sve objekte tipa Vertex. Ukoliko kasnije napravim klasu LabeledVertex (implements Vertex) i odgovarajuću fabriku, u algoritmu foreach naravno dobijaću elemente tipa Vertex, pa moram ručno da ih pretvaram u LabeledVertex kako bih sa njima odradio ono što želim. Da li je ovo rešenje u redu ili postoji nešto elegantnije? Ono što mi se u ovom rešenju ne sviđa jeste što korisnik može da „podmetne“ neodgovarajući tip datom algoritmu, što će dati ClassCastException kada foreach pokuša da „uforsira“ tip LabeledVertex. Da li to može da se izbegne nekako?
Treće, potrebne su mi dodatne metode za klasu String (konkretnije, neke metode iz java.lang.String iz jre 1.4, dok koristim jre 1.3). Da li je bolje rešenje napraviti klasu (npr. Compat) koja sadrži statičke metode ili možda naslediti String 1.3, delegirati metode koji postoje a dopisati 1.4? Pritom je naravno problem što se u novonapravljenoj klasi ne koristi nijedan metod nasleđen od String pošto je nasleđivanje bilo samo zbog is-a. A možda i nije problem? Ne znam kako JVM tretira takve slučajeve?
f
 |  |
 |
