CODEWITHSUNDEEP
c++
pmundt
pmundt

Reputation: 137

What kind of class structure do I need?

I just needed something like this:

I have got a robot class which contains a motor object and a predefined callback function (which is triggered on an interrupt).

robot.h

class robot
{
public:
    motor motor1;
};

motor.h

class motor
{
public:
   int incrementPosition();
   int getPosition();
private:
    int position;
};

callback.cpp

void callback(){
   motor1.incrementPosition(); //callback function needs to reach this already created motor1
}

What I am trying to achive is:

So the main should be like this,

main(){
   robot myRobot;
   robot myRobot2; //is not allowed or should be useless

   printf("%d\n", myRobot.motor1.getPosition());
}

Upvotes: 2

Views: 111

Answers (1)

user0042
user0042

Reputation: 8018

Not that I really like to recommend that1, but obviously the Singleton Pattern comes to mind:

class robot {
    robot() {}
public:
    motor motor1;
    static robot& instance() {
        static robot theRobot;
        return theRobot;
    }
};

The only way to access an instance of robot is to use the instance() function then.

main(){
   robot myRobot; // Fails to compile since the constructor is private

   printf("%d\n", robot::instance().motor1.getPosition());
               // ^^^^^^^^^^^^^^^^^ Access the one and only instance 
}

The same way the single motor instance can be accessed in the callback function:

void callback(){
   robot::instance().motor1.incrementPosition();
}

Some more considerations:

  • Make your robot class implement an interface like

     struct IRobot {
     virtual ~IRobot() {}
     virtual std::vector<std::shared_ptr<IMotor>>& motors() = 0;
 };

    this makes it easier to write isolated unit tests and mock the robot singleton.

  • Instead of the static instance() function provide a global access function for the singleton instance that returns the above mentioned interface. This also can be easier replaced with a function that returns a mock object for unit testing.

1)The Singleton Design Pattern is often blamed as a bad design, and in most cases it actually is a bad decision. Nevertheless there are valid use cases, especially when designing embedded systems. You have one single and autonomous robot, that's clear and deserves a singleton.
It's considerable though, if you should fix yourself to a single motor from the beginning, it would be hard to change if the HW engineers decide to need a second motor.

Upvotes: 7

Related Questions