Hi,
I'm using the delegator pattern as part of the AI for a strategy game I'm writing in C++. The details of the game are unimportant. All you need to know is that there are various game states that come up while playing, and I need to handle each one differently. What's more, as my code evolves, I will need to add new games states that I hadn't thought of (dealing with more and more specific cases)....
The delegator class has only two relevant methods:
void add(Condition* condition, GameState* gamestate);
Action getNextAction();
The delegator will loop through the conditions (which can be thought of as describing game states), and find a gamestate which matches the current condition. The delegator will then delegate its "getNextAction()" to the gamestate's "getNextAction()" method. The gamestate object will then return an action.
This part of the design I am happy with. My problem is with the specifics of how I've handled the conditions. I have a condition class, with a virutal "isTrue()" method. I then subclass the Condition class to create the concrete condition classes that correspond to game states. But these concrete condition classes only need to be created once, and also should be globally accessbile. To answer both these requirements, I've created a convenience class call "Cond" that looks like this:
class Cond {
public:
static ConcreteCondition1 concreteCondition1;
static ConcreteCondition2 concreteCondition2;
static ConcreteCondition3 concreteCondition3;
//and so on
};
Now, the benefit of this is that I can write statements like this:
delegator_->add(&Cond::con
On the other hand, every time I create a new condition, I must not only create a new condition class, but also remember to add a static instance of that class to "Cond". I'm not sure if this is bad design or not, but something about it does not sit right with me.
In addition, the condition classes themselves all simply implement the single "isTrue" method -- thus, they exist merely as a formalism for containing a function, so that I can pass object around rather than passing pointers to functions around. This seems reasonable, but I wasn't entirely sure about that design decision either.
I'm looking for general comments about the effectiveness of this design. Any and all feedback will be much appreciated!
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
If you want to be able to derive from ConcreteDecision you would need to pass the concrete condition to register by pointer rather then by reference. Or you pass a function pointer for creating new instances of the derived ConcreteCondition class and store the function pointer instead of a concrete instance.
>>>> Could you explain the advantage of using your method over mine?
The methods are quite different. By using a container you freely can add new conditions even from derived classes wihout changing the Cond class. You would address the registered conditions e. g. by
Cond::getCondition("Any")-
while with your method it would be
Cond::concreteConditions1-
In my case the check function probably is a virtual function and the concrete conditions probably are instances from derived classes.
Okay, makes sense. Thank you. What did you think of this concern of mine:
In addition, the condition classes themselves all simply implement the single "isTrue" method -- thus, they exist merely as a formalism for containing a function, so that I can pass object around rather than passing pointers to functions around. This seems reasonable, but I wasn't entirely sure about that design decision either
Like Alex, I'd separate out the delegate from the condition that causes the delegate to be invoked.
It looks like you want singleton delegates or perhaps function pointers. If delegates are objects, derive from from a base class with a virtual "do it" function.
e.g.
class delegate_base {
public: virtual ~delegate_base() {};virtual void doit() = 0;
};
Your delegator will know about the base class delegate_base, but will not know about the classes derived from it. It will invoke the derived class's doit function via dynamic polymorphism.
When you add your delegate to your delegator, create the instance and pass ownership of the instance to the delegator, along with the condition for delegation.
e.g.
class super_delegate : public delegate_base {
public: void doit() {cout << "Super\n";}
};
void register() {
delegator.add_delegate_for
}
Leave it to the delegator to clean up the delegates, when they are not wanted (e.g. in the delegator's Dtor).
If your delegator uses Alex's map<>, it only needs to know about conditions and the base class or function signature for delegates. That's good design. No need to recompile the delegator every time you design a new delegate.
You will need a multi_map<>, if the same condition needs to invoke multiple delegates. Conversely, you will need to delete existing mapped delegates, if you need to have a new delegate replace an existing one in a map<> and the delegator "owns" the delegates.
Hi rstavely,
This is indeed how I already have the delegates working... my question is about the conditions. In this line of code above:
delegator.add_delegate_for
I understand what is going on with "new super_delegate()", but what is happening when you call "Condition("super_conditio
The bool return has the purpose to make the registering of conditions part of the static initialization of other classes :
// any.h
class Any
{
static bool myRegisterCC;
static ConcreteCondition myCC;
...
};
// any.cpp
#include "any.h"
bool Any::m_registerCC = Cond::registerConcreteCond
Itsmeandnobodyelse,
I
Thanks.
>>>> What is this Any class? Why is it doing the registering?
'Any' means it could be done by *any* class (or even function) as Cond::registerConcreteCond
Concretely, you would do the registering where you firstly *know* of the ConcreteCondition to register or in the ConcreteCondition derived class itself.
The latter probably is the best way to do it:
- derive from ConcreteCondition
- use a static bool member in that derived class to make a
one-time registering of the new class at class Cond
Note, any static (data) member *must* be initialized in a .cpp. That mechanism was used in my code above to do the registering exactly once in the initialization phase of the program.
FYI: the method described above is another pattern called 'factory pattern'. It *normally* is used to create instances of derived classes by means of a base or factory class without the factory class has to know of the derived classes. The creation of other instances of the registered derived class can be made either by storing a function pointer in the factory map (A) or by storing a creator instance by pointer in the factory map which would create new instances by calling an appropriate virtual function. For (A) the derived class has to provide a static member function to create new instances like
class Derived : public Base
{
public:
static Base* createDerived() { return new Derived(); }
};
and for (B) it would provide a virtual function like
class Derived : public Base
{
public:
virtual Base* createDerived() { return new Derived(); }
};
> what is happening when you call "Condition("super_conditio
Your temporary would be a const reference. You'd need a copy constructor for your condition class and your delegator would manage a collection of conditions, which it owns and maps/multi_maps to delegates.
If your condition objects were themselves derived classes, you'd need to be able to clone (e.g. via Alex's factory) rather than copy construct and you'd be better off with a pointer in any case. So you'd want to use new and to transfer ownership of the object to the delegator.
Consider using auto_ptr<> to make your intentions explicit about transferring ownership in add_delegate_for_condition
Business Accounts
Answer for Membership
by: itsmeandnobodyelsePosted on 2009-10-02 at 02:27:27ID: 25476229
>>>> I must not only create a new condition class, but also remember to add a static instance of that class to "Cond".
You could sove that differently by using a static container - say a map m_concreteConds - in the class Cond where the concrete Conditions can be registered by calling static function
bool Cond::registerConcreteCond
{
m_concreteConds[condId] = cc;
return true;
}
With that you could retrieve a concrete condition from Cond class by key.
The bool return has the purpose to make the registering of conditions part of the static initialization of other classes :
// any.h
class Any
{
static bool myRegisterCC;
static ConcreteCondition myCC;
...
};
// any.cpp
#include "any.h"
bool Any::m_registerCC = Cond::registerConcreteCond
...