Hi Gyzmo,

It''s better to use abstract factory instead of global factory. Just instantiate desired factory in the beginning of the program and pass that to rest of the application.

Cheers, Altair


"Only two things are infinite, the universe and human stupidity, and I''m not sure about the former." - Albert Einstein

As I said, the type of factory is completely hidden by an abstraction-layer of the UberFactory/Monolith/whatever. You could even have ''sub-uberfactories'' inside it, I don''t know why, but you could.

I should actually write this baby, but well, that''s my problem, full of ideas and too lazy to implement them.

(YES I KNOW, my sig is misspelled, misgrammered and missomethingeelsed)

Gyzmo
=======================

This actually sounds alot like COM''s object creation method. I''ve been playing with COM lately at work (I''m designing a HAL for DAQ devices) and it''s pretty cool. It''s not exactly what you''re doing, but related. (COM doesn''t provide a container and serialize access to object instances like your Uberfactory.)

It''s fairly involved, and a major pita to setup the first time, but once you figure out how to register the .dll and write the neccessary functions it gets a bit easier.

This is what COM does that pertains to what you''re doing:
A GUID is generated and stored in the registry for every object interface specification and for each object implementation.

Any given object can support many interfaces and must implement IUnknown. For instance IUnknown, IDirectDraw3, IDirectDraw5, IDirectDraw7, etc... are all implemented in the CODirectDraw7 class.

In order to create an object you need to know it''s class GUID (aka reference uuid) and an interface it supports. Remember all COM objects support the IUnknown interface, so you really only need to know it''s refiid - though you''ll need another interface ID in order to do anything useful.

COM fully & clearly seperates the interface declaration from the class definition. There''s even a handy-dandy language called IDL, that is supported by VC, VB, & Delphi, to create your interface defintions with. The particular compiler then ''compiles'' the idl file and generates the correct header files for the given language.

COM further defines a binary specification for the interfaces - so the binary representation of the interfaces to the class object is also the same in RAM with all environments. That means you can create an object in any of the languages, and use it in any of the languages, pain free.

It''s ideal for plug-ins.

Magmai Kai Holmlor
- The disgruntled & disillusioned

I know, I own a book about COM (DCOM actually) and that''s where part of my idea came from, the fact that I don''t want to use it in my Uberfactory is because first of all, it adds complexity for the client-programmer and secondly it doesn''t need a lot of features of COM, such as global access to objects in computer-space (as opposed to program-space) (I hope I''m explaining this well). And well, if I were to use it in a game, using ID''s for each registered object, compares of longs are a lot faster than GUIDs.

Maybe when I''m (IF I) implementing it, I''ll see that the use of COM might be useful, but we''ll see (or won''t)...

Gyzmo
=======================

Gyzmo,

I just don''t find it very good way to have a global instance of a factory, even if it''s actually a pointer to an abstract factory interface. Also, I don''t understand why it needs to be singleton.

I wouldn''t either use any key words for creating objects, but direct method calls dedicated to create certain type of objects. Like: factory->createThread(); ID''s, particularly string ID''s, are very error prone and inefficient way to create objects. Instead, if you have separate methods for creating different objects, you can provide different interfaces to access them. It''s not convenient to have Thread and Goblin sharing the same base interface, because to be able to use the object, you should perform some nasty downcasting.

If you have sub-factories, you can nicely split the creation of objects to several interfaces. It makes your code alot easier to follow and control. If you have first a factory, which creates only sub-factories, it''s better first create monsterFactory and then monsters from it.

Anyway, I don''t think that factory is proper way to create all objects. You should use factory to only create objects, which are platform dependant or require extremely good performance and I don''t find Goblin belonging into this group (: But Thread and Socket do, of course.

Cheers, Altair


"Only two things are infinite, the universe and human stupidity, and I''m not sure about the former." - Albert Einstein