-4
\$\begingroup\$

The idea is that when we want to create an object of some type, we will only use a robotcreator and enum from the interface. the goal is to decides what type of robot to use internally, based on a parameter supplied by the client at runtime.

what's better enum or define?

InterfaceRobot.h

 class InterfaceRobot
    {
   public:
    InterfaceRobot();
    enum RobType { Y=0, C=1, D=2, F=3 };

    virtual void open() = 0;
    virtual void close() = 0;
 };

#endif // INTERFACEROBOT_H

RobotCreator.h

class RobotCreator :public InterfaceRobot
{
public:
    RobotCreator(InterfaceRobot::RobType _robType);
    void open();
    void close();
    ~RobotCreator();

private:
    InterfaceRobot *Robot; /** pointer to InterfaceRobot**/
};

RobotCreator.cpp

RobotCreator::RobotCreator(InterfaceRobot::RobType _robType)
{
    switch (_robType)
    {
    case InterfaceRobot::C:
        this->Robot = new c();
    break;
    case InterfaceRobot::Y:
        this->Robot = new y();
    break;
    case InterfaceRobot::D:
         this->Robot = new D();
    break;
    case InterfaceRobot::F:
        this->Robot = new F();
    break;
    }
}

void RobotCreator::open()
{
    this->Robot->open();
}

void RobotCreator::close()
{
     this->Robot->close();
}

RobotCreator::~RobotCreator()
{

}

Example of robot Y.h:

class Y: public InterfaceRobot
{
public:
   Y();
   // InterfaceRobot interface
public:
   void open();
   void close();
};

Example of robot Y.cpp:

Y::Y()
{

}

void Y::open()
{
    cout<< "open Y" <<endl;
}

void Y::close()
{
    cout<< "close Y" <<endl;
}

use in main:

int main()
{

 RobotCreator rob(InterfaceRobot::Y);
 rob.open();
 rob.close();
}
\$\endgroup\$
  • 1
    \$\begingroup\$ What's the difference of those implementations you have for c, y, D and F. It's unclear which particular problem should be solved with your code. Generally a factory is for creating new instances that implement an interface, whereas strategy is to choose a specific algorithm. \$\endgroup\$ – πάντα ῥεῖ Jul 7 '19 at 8:00
  • \$\begingroup\$ @πάνταῥεῖ c,y,d,f are different robot and each one implements the functions in the interface differently. \$\endgroup\$ – zbar Jul 7 '19 at 8:04
  • \$\begingroup\$ All in all it looks like you simply have a flawed and bad design (referring to none of those desgn patterns you mentioned), which violates the single reponsibility principle. Plus some essentially bad practices and simply not working code (using delete[] for stuff created with new). Generally note that we don't accept any stub or hypothetical code for review here. \$\endgroup\$ – πάντα ῥεῖ Jul 7 '19 at 8:11
  • 1
    \$\begingroup\$ Sorry if I sounded harsh in some way, but it's not a question about being gentle, just what the policies of this site are (see the 2nd bullet specifically). \$\endgroup\$ – πάντα ῥεῖ Jul 7 '19 at 8:27
  • \$\begingroup\$ @πάνταῥεῖ ok great. i will read the policies. \$\endgroup\$ – zbar Jul 7 '19 at 8:29
1
\$\begingroup\$

Your robot creator is not a factory in the traditional sense, because it never returns the robots it creates, or exposes them publicly. Generally, a factory object would do the same job as a class constructor, with the advantage of being a first-class object that can be passed around, stored in a field somewhere, and so on (without resorting to reflection or other "magic," in languages that support that).

This looks more like a strategy pattern, where it decides what type of robot to use internally, based on a parameter supplied by the client at runtime.

It's difficult to propose an alternate solution, because it's not clear exactly what problem this code attempts to solve.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Thenks , The idia its like what you said : "where it decides what type of robot to use internally, based on a parameter supplied by the client at runtime." \$\endgroup\$ – zbar Jul 7 '19 at 7:57

Not the answer you're looking for? Browse other questions tagged or ask your own question.