Factory Method DP

Svrha

Definisanje interfejsa za kreiranje objekta, uz mogućnost da klasa prepusti potklasi kreiranje samog primerka (bilo da klasa ne može da zna klasu objekata koje treba da pravi ili da klasa namerno prepušta potklasama odluku o klasi primerka).

Kratak opis problema

Često postoji potreba da se u objektno-orijentisanim sistemima kreiraju objekti čiji konkretan tip nije poznat na mestu kreiranja.
Neka, na primer, u sistemu postoji apstraktna klasa Document, čije su podklase TextDocument i DrawingDocument .
Dalje, neka postoji klasa Application, sa podklasama TextApplication i DrawingApplication.
Klasa Application sadrži zajednički kod manipulacije dokumentima. Taj kod je takav da ne zavisi od konkretne vrste dokumenata kojima se manipuliše.

Na primer Application može da obavlja operacije otvaranja, zatvaranja dokumenata, snimanja na disku, prikazivanje na ekranu ,...
Ali kako Application ima potrebu i da kreira nove dokumente, nastaje problem zbog toga što Application "ne poznaje" tip dokumenata koje će da kreira (TextDocument ili DrawingDocument), jer ovaj tip zavisi od konkretnog tipa aplikacije (TextApplication ili DrawingApplication) koja se izvršava. Zato je ovde koristan factory method DP.

Ideja:

Kreiranje objekata preneti na konkretnu aplikaciju koja se izvršava i time "sakriti" od aplikacije koja koristi te objekte . I obezbedti factory metod Create() koji je dostupan aplikaciji, ali čija implementacija zavisi od tipa konkretne aplikacije koja se izvršava.

Proizvod (ili u našem primeru Document)

definiše interfejs objekta koji pravi FactoryMethod

KonkretanProizvod (u našem primeru konkretan dokument)

implementira interfejs proizvod

Kreator (ili u našem primeru Application)

deklariše factory method koji vraća objekat tipa Proizvod. Kreator može da pozove factory method radi pravljenja objekta tipa Proizvod.

KonkretanKreator (ili u našem primeru konkretna aplikacija)

može da nadjača factory method da bi vratio instancu KonkretnogProizvoda

Primena

Kao što je već navedeno, od Application je "sakriveno" kreiranje različitih objekata tipa Document. Ovo kreiranje je ostavljeno FactoryMethod-u Create(), koji je apstraktan i koji je adekvatno definisan u potklasama (TextApplication i DrawingApplication). Time, dovoljno opšti kod (u smislu da je zadužen za manipulaciju dokumentima nezavisno od njhovog tipa i da je zajednički za sve aplikacije) unutar klase Application može da kreira odgovarajuće objekte. Ako je trenutna aplikacija TextApplication/ DrawingApplication, taj kod (putem metoda Create()) može da kreira TextDocument / DrawingDocument objekte.

Relativno je jednostavno zameniti delove ovakvog sistema (npr. zameniti objekte TextDocument objektima WordProcessorDocument ), kao i proširiti sistem (npr. dodavanje PaintDocument i PaintApplication klasa).

Prednosti primene Factory DP-a

• omogućuje da i klijenti (a ne samo Proizvođači ) mogu da iskoriste factory metode što se naročito odnosi na pojavu paralelnih hijerarhija klasa
  Nastanak paralelne hijerarhije klasa je u situaciji kada jedna klasa delegira neke svoje odgovorosti drugoj klasi. Na primer, pri implementaciji interaktivne manipulacije grafičkim objektima (istezanje,rotiranje pomoću miša,..) , često je potrebno sačuvati, ali i ažurirati informacije o stanju manipulisanja u zadatom trenuku. No, to stanje je potrebno samo za vreme manipulacije i nije nužno pamtiti to stanje u objektu oblik.
  Ali, mora se još voditi računa i da se različiti oblici različito ponašaju kada korisnik njima manipuliše (nije isto istezati liniju i istezati tekst).
• eliminacija potrebe da se u kôd ugrađuju klase specifične za pojedine aplikacije
  Naime, kôd radi sa interfejsom Proizvod, te on može da radi i sa ma kojom korisnički definisanom klasom KonkretanProizvod
• pruža sredstvo potklasama za obezbeđivanje proširene verzije objekta
  Kreiranje objekata unutar klase pomoću factory method-a je fleksibilnije negoli neposredno kreiranje objekta.

Mane primene Factory DP-a

• klijent pravi potklasu klase Proizvođač radi kreiranja objekta neke određene klase KonkretanProizvod.
  Ovo nije problematično, ako klijent, inače, će praviti potklasu klase Proizvođač. U suprotnom, to je jedna obaveza više za klijenta.

Poznat i pod imenom

Primeri korišćenja factory method-a u realnim sistemima

• sistem Orbix ORB (Object Request Broker) upotrebljava Factory method radi generisanja adekvatne vrste proxy-ja u situacijama kada objekat zahteva referencu na udaljeni objekat.
• Java RMI

Standardi za slanje poruka

• CORBA (Common Object Request Broker Architecture)
• RMI (Remote Method Invocation)
• COM (DCOM)
• SOAP (Simple Object Acces Protocol)

CORBA

To je standard koji omogucava da proizvodi raznih proizvodaca medusobno sadraduju.
CORBA ima standarni API za vecinu funkcija ORB-a: inicijizacija ORB-a, pozivanje metoda udaljenih objekata, prevodjenje tipova podataka iz jednog u drugi programski jezik itd.
Objekti obavljaju komunikaciju preko Internet Inter-ORB protokola (IIOP) protokola.
Vecina velikih proizvodjaca podrzava CORBA-standard, osim Microsofta.
CORBA funkcionise tako sto kreira kopije udaljenih objekata (tj. distribuirani objekat u lokalnom adresnom prostoru) koji se naziva stab (eng. stub- klada, odsecak).
CORBA je projektovana da radi sa velikim skupom programskih jezika (C, C++, ADA, Smalltalk, Java, ...) i zbog toga nudi samo ogranicen skup osobina zajednicki svim jezicima.

RMI

RMI je ORB ugraden u JDK 1.1.
To je objektno orijentisana verzija RPC-a (Remote Procedure Call).
RMI stvara iluziju da se udaljeni objekti pozivaju lokalno (ne moramo da brinemo o osnovnim mehanizmima kao sto su sockets i dr.)
RMI je namenjen samo programskom jeziku Java.