Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Factory Objects - practical application
Message
De
15/12/2006 12:57:01
 
 
À
14/12/2006 14:50:00
Mike Yearwood
Toronto, Ontario, Canada
Information générale
Forum:
Visual FoxPro
Catégorie:
Programmation Orientée Object
Versions des environnements
Visual FoxPro:
VFP 9 SP1
Divers
Thread ID:
01177742
Message ID:
01178062
Vues:
28
you may make a lazy load factory by usage of the decorator pattern:
Define Class Factory As Custom
  oFactory = .Null.
  Procedure THIS_Access()
    Lparameters cMember
    If Isnull(This.oFactory)
       This.oFactory = NewObject(...)
    Endif
    Return This.oFactory
  Endproc
  Procedure GetClassLoc()
    ...
  Procedure GetClassName()
    ...
Enddefine
To explain it: This_Access() works in a way, that what is finally being used is cMember of the returned object. If you call Factory.instantiate(a,b,c), this will cause the procedure Factory.This_access("instanciate") to run, which (at first call creates and afterwards) always returns Factory.oFactory, so finally what's called is Factory.oFactory.instanciate(a,b,c). The oFactory subobject is decorated.

The parameters of the NewObject(...) call could use an expression or UDF like you suggested, which looks up the class name and location of the real factory class, or you could make that lookup a method of this FactoryFactory class, like in my example.

First use of the factory instanciates the real one behind the scenes. So to the user this class can be regarded as being the real factory, while it really just decorates its own oFactory subclass.

Of course this very lightweight FactoryFactory is the one thing which indeed needs to be created somewhere once, but that doesn't hurt, does it? Put that in main.prg and let that be the first thing created, goApp the second one, created by that factory of course. Or vice versa as Craig does.

Bye, Olaf.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform