Jump to content
  • Advertisement
Sign in to follow this  
jmau0438

Unmangle the Factory Method

This topic is 3095 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

OK, I gotta raise my hand here. What I'm trying to do is heterogenously define container objects with their own set of functionality while perserving a homogeneously defined higher level system that manages them. After looking into it I found out that creating/implementing a factory object/method is the best way to go. Sadly, almost every example I find has some extened functionality attached to it, which although cool is just getting me more and more confused. I'm afraid I just don't have the patterns fundamentals down yet, which is why I'm so confused. I just need a simple step-by-step breakdown (preferably in C++), can someone help me?

Share this post


Link to post
Share on other sites
Advertisement
Quote:
What I'm trying to do is homogeneously define container objects with their own set of functionality while perserving a heterogenously defined higher level system that manages them.


"There are a lot of long words in there, sir; we're naught but humble coders. What is it that you want?"


Seriously - what exactly do you want to achieve. Not in generic, patternized way. Are you trying to create instances of... what? And these instances will by used by... whom?

Share this post


Link to post
Share on other sites
Quote:
"There are a lot of long words in there, sir; we're naught but humble coders. What is it that you want?"


That was hilarious, I almost feel out of my seat! [lol]

OK, I'll break it down:

1. HETEROGERNOUS CONTAINERS -

Think of STL containers, or anything similiar defined by a user/programmer. This is what I'd be using. They are heterogenous, meaning simply that there are aspects that will vary from container to container, but they all share a similiar purpose. I'll get more into it...

1.1 BASE FUNCTIONALITY: The container meant for the factory is derived from something similiar to (if not the) STL, and is in-fact bears the default initialization of an STL vector container class containing double as the default data type.


template < class CONTAINER = std::vector < double > >
class Foo: CONTAINER {

};



What this does for me is provide any basic operations that I might need, particularly with memory management & element manipulation.

1.2 INTERFACE: The templated class definition you see in 1.1 is meant to be an interface full of pure virtual functions. These virtual functions allow me to use similiar function names in derived objects while allowing me to customize how they perform the operation.


template < class CONTAINER = std::vector < double > >
class Foo: CONTAINER {

public:

virtual void Bar ( void ) = 0;

};



To summarize, what this interface does for me is provide a means of defining how I want elements managed, what kind of elements they are, and how each operation performs the tasks therein.

2. HOMOGENOUS HIGH-LEVEL MANAGEMENT -

What I'm saying here is merely have a managing object that does not vary regardless of the implementation of objects derived from Foo. A melting pot if you will.

Does this help?

Share this post


Link to post
Share on other sites
The idea behind a factory is to facilate the "production" of these heterogenous containers so that I can filter them into the managing object.

Share this post


Link to post
Share on other sites
Quote:
Original post by jmau0438
The idea behind a factory is to facilate the "production" of these heterogenous containers so that I can filter them into the managing object.


A factory takes a key, and returns an instance. Depending on needs the implementation might return cached, newly allocated, a singleton instance...


If you need a factory for containers, then something like this would do:

Container * c = newContainer("double", "Bar");
Which would create a container holding Bar interfaces which would be stored as double... Probably...

Share this post


Link to post
Share on other sites
Quote:
A factory takes a key, and returns an instance.


So do think a vector is a poor choice? Maybe a map or set, as they consist of std::pair which has a key and a real value (the instance)?

Quote:
Depending on needs the implementation might return cached, newly allocated, a singleton instance...


This is one of the hotspots of confusion for me, how it is returned.

Quote:
If you need a factory for containers, then something like this would do:

Container * c = newContainer("double", "Bar");


And this would be a member of the factory object with the container being its "product", right?

Quote:
Which would create a container holding Bar interfaces which would be stored as double... Probably...


Does the factory have to mirror the definition of the interface, or is it a standalone object?

Share this post


Link to post
Share on other sites
The heterogenous container is an abstract interface, allowing one to describe the behavior/capabilities of an object by defining what is required for any given implementation without actually committing to it. Through this abstract interface I can homogenously define container objects through a factory pattern method.

What I don't understand is what is happening in the middle.

Share this post


Link to post
Share on other sites
Look, if you don't understand factories, ignore this container business for now.

A factory returns an object. In the simplest version a factory just says return(new foo()); (and then expects you do delete the object later). Some more complex factories will return a shared common object, or return foo or bar based on some parameter or configuration option.

It all depends on what you need it to do specifically. There's not some magical set of code that is a factory, it's the shape of the code and the general concept of what it does. A factory sits there and gives you objects.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!