Prototype design mønstret, generelt spørgsmål

måske er denne bedre til at forklare det
http://www.patterndepot.com/put/8/Prototype.PDF

Som du sikkert er klar over er anvendes metoden clone() i Java til at klone objekter, og for at kunne klones, skal de også implementere interfacet Clonable. Ideen med prototype designmønstret er, at man f.eks. kan lave flere varianter af det samme objekt at have liggende, og så kopiere (eller klone) dem efter behov. I Java er det temmelig meget hurtigere at klone et objekt end at instantiere et nyt. Jo flere variable der parses til et objekts konstruktør, jo længere tager det at instantiere det nye objekt, og jo mere CPU-tid sparer man ved at klone.

Hastighed - Ok, det kan jeg godt se nu - i nogle situationer. Det beskriver de også i loadet's pdf link. Tak for det.

Men der må være andre fiduser, hastighed nævnes slet ikke i 'the gang of 4'.

Her skriver de om 'Applicability':

Use the Prototype pattern when a system should be independent of how its products are created, composed, and represented; and

- when the classes to instantiate are specified at run-time, for example, by dynamic loading; or

- to avoid building a class hierarchy of factories that parallels the class hierarchy of products; or

- when instances of a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state.

Sidste punkt er jeg med på. Men hvad med de 2 første?

Finessen ved kloning er at man ikke behøver kende den præcise type
af det objekt man kloner.

Du modtager noget som du kun ved er et interface eller en abstrakt
basis klasse. Du ved ikke hvad det instantierede objekt er.

Du skal bruge "sådan en". Of du kan ikke new'e et interface eller
en abstrakt basis klasse.

Kloning er en pæn løsning. Objektet ved selv hvordan det laver en magen
til sig selv.

Det er meget kønnere end en stor factory klasse som enten har en
million if statements eller roder rundt med noget reflection og
dynamisk instantiering af objekter.

Dvs. det har egentlig samme formål som abstract factory (altså hvor man har én abstrakt factory klasse, og flere konkrete factory's, der laver produkt objekter)?

I begge patterns har klienten ikke kendskab til det egentligt produkt men får det oprettet gennem 1) for abstract factory's vedkommende: en factory klasse (dets interface) 2) prototypens vedkommende: Vha. kloning (af selve produktet) via prototypens interface.

Ja.

Men det er i mange tilfælde kønnere på begge sider af plankeværket at bruge
prototype.

User skal bare kalde clone i.s.f. at at skulle have instantieret den
rigtige factory.

Implementer skal bare lave en clone metode i sine klasser fremfor
at skulle lave en masse factory klasser.

Ulemperne ligger bl.a. i deep versus shallow clone problematikken.

arne_v: Du er dæleme god. Læg et svar.

Tak for hjælpen til alle.

ok

Mit argument i 23:18:20 indlægget svarer til GoF Applicability bullet 2 (p. 118) og
Consequences item 4 (p. 120).

Yes har det.