Object 面向 model 通用器件的设计

Question

I was asked below object oriented system design question in an interview.

There are multiple devices like Echo show, Echo dot, Echo tab, Smart microwave, Fire tv stick etc.

• Echo show - It has display screen and speaker. It works on electric power supply.
• Echo dot - It has speaker. It works on electric supply.
• Echo tab - It has speaker. It works on battery supply. Battery can be charged.
• Smart microwave - It has screen display. It works on electric supply.
• Fire tv stick - It has speaker. It works on electric supply.

So basically these are 3 categories like - speaker / screen display / both speaker and screen display There are two categories like - electric supply / battery supply. There can be queries on any of these devices like print status. Here are possible outputs for each of this device -

• Echo show - "It is on charging" or "It is not charging" depending on whether it is connected to electric supply or not. This output should come on screen and speaker.
• Echo dot - "It is on charging" or "It is not charging" depending on whether it is connected to electric supply or not. This output should come on speaker.
• Echo tab - "Battery is charging" or "Battery is not charging and battery level is 70%" depending on whether battery is charging or not. This output should come on speaker.
• Smart microwave - "It is on charging" or "It is not charging" depending on whether it is connected to electric supply or not. This output should come on screen.
• Fire tv stick - "It is on charging" or "It is not charging" depending on whether it is connected to electric supply or not. This output should come on speaker.

Assume that there are inbuilt classes for speaking and printing on screen. If we pass string to these class objects they will do respective job.

Now write 4-5 classes to model this scenario.

Design should be extensible meaning if tomorrow any new device comes with a new combination then it can be implemented without creating any new class. So you should not be creating class for each device.

Here is my object oriented solution but interviewer is not happy with it particularly with vector<Output*> outputs . He was suggesting to use some design pattern instead of vector. Can you think of a better solution?

class Output {
   public:
    virtual void print(string);
};
class Display : public Output {
    DisplayScreen obj;
   public:
      void print(string str) { obj.print(str); }
};
class Speaker : public Output {
    Audio obj;
   public:
      void print(string str) { obj.print(str); }
};
class PowerSupply {
   public :
    virtual string get_status();
};
class BatteryPower : PowerSupply {
   bool isCharging;
   int chargeLevel;
   public :
     string get_status();
};
class ElectricPower : PowerSupply {
   bool isCharging;
   public :
     string get_status();
};
class Device {
    vector<Output*> outputs;//I used vector because Echo show has both display and speaker
    PowerSupply powersupply;
    Device(vector<Output> &outputs, PowerSupply powersupply) {
        this->outputs = outputs;
        this->powersupply = powersupply;
     }
};

Answer 1

vector<Output> doesn't allow for inheritance because it stores Output s directly instead pointers or references. If you store a Display or Speaker in the vector it will be sliced .

Since outputs are unique to each device, I would make that a vector of unique pointers:

std::vector<std::unique_ptr<Output>> outputs;

Answer 2

If I were in this interview, I would talk at some length about how "model this" is an invalid directive. Every interface reflects the requirements of the consumer and the consumer is not described...

So we have to assume that there is something that needs to have a pointer to any of these things and then use any of the capabilities that it provides. Sure, Device is a good name for this.

A consumer is not going to consider all outputs to be the same so, this vector<Output> doesn't appear to be very useful. I would imagine that the consumer of the Device interface needs something like this:

class Device {
    public:
    virtual ~Device() = 0;

    // Get a pointer to the primary display (e.g., for playing video), or nullptr if there isn't one
    // It's only valid while this Device exists
    virtual Display *getPrimaryDisplay() {
        return nullptr;
    }

    // Get a pointer to the audio output, or nullptr if there isn't one
    // It's only valid while this Device exists
    virtual AudioOut *getAudioOutput() {
        return nullptr;
    }

    // Get a pointer to the charge status, or nullptr if there isn't one
    // It's only valid while this Device exists
    virtual ChargeStatus *getChargeStatus() {
        return nullptr;
    }

    // Send a notification or message to the user via the primary
    // channel (text display and/or text to speech)
    virtual void message(const std::string &msg);
}

Note that we use Interface Segregation to separate out the various capabilities that the consumer might want to use.

We also provide default implementations of these things so that when we add new ones, we don't invalidate existing Device implementations. If all the implementations are in the same source repo, though, we would want to make these pure virtual so that adding a new kind of service would force a decision about whether to support it or not for each device.

If we wanted to support both, then we'd provide a pure virtual interface and a base abstract implementation that returns nullptr for all services.

On the other hand, if we had to maintain binary backward compatibility to 3rd party Device implementations, then we would use a registration system instead of explicitly enumerating the possible services in this interface.

Then you need implementations of this interface for each device. For Echo show, for example:

class EchoShow : public Device {
   // implements Display
   std::unique_ptr<EchoShowDisplay> m_display;
   // implements AudioOut
   std::unique_ptr<EchoShowSpeaker> m_speaker;

   public:
   Display *getPrimaryDisplay() {
       return m_display.get();
   }

   AudioOutput *getAudioOutput() {
       return m_speaker.get();
   }

   // No ChargeStatus, since there's no battery -- inherit default nullptr

   void message(const std::string &msg) {
       m_display.showAlert(msg);
       // play bell and message at high priority to interrupt
       // any streaming audio, etc.
       m_speaker.queueSound("BELL", PRIORITY_NOTICE);
       m_speaker.queueSpeech(msg, PRIORITY_NOTICE);
   }

Answer 3

I do not think the interviewers request to use some design pattern was in any way constructive. Design patterns are tools to accomplish something; without a goal a design pattern is meaningless. Instead he could have said: " We are expecting to have to construct a lot of similar devices with minimal deviations. How would you accomplish that? " insted of " Now tag on a random design pattern and we are golden. ".

Apart from the technical issue John Kugelman answered here . I think there are several design patterns you could have used instead of just passing in a vector of devices and power supplies. Some examples from the top of my head:

Factory pattern

Keywords for research: Factory pattern

class DotFactory
{
    DotFactory(/*maybe you need parameters*/);
    Device* getDevice(/*more parameters e.g. speaker count*/);
}

Builder pattern

Keywords for research: Builder pattern

Depending on the complexity and use case you could integrate the Device builder into the device. For simplicity I've done it this way.

class Device 
{
    // Your stuff
    vector<Output*> outputs;
    PowerSupply powersupply;
    Device(vector<Output*> &outputs, PowerSupply *powersupply);

    // Builder functions
    bool addPowerSupply(PowerSupply*);
    bool addOutput(Output*);

    // If outside your Device class also integrate:
    Device* getBuiltDevice();
};

Additional patterns and combinations (I was expecting to come up with more than one. Maybe someone can edit more in.)

Singleton list of devices (antipattern in most cases)

Depending on the usecase you could also have any thing (method, container, class etc.) holding your predefined 'Devices' if you only need one each per application.

Answer 4

My opinion is that the part with PowerSupply and Output is okay.

The Device design I would have done differently but it is a valid design nonetheless.

I would also have used std::shared_ptr everywhere. std::unique_ptr is sometimes tricky for beginners so I prefer not to use it.

As per factory as another commenter suggested, I would just create a static method inside the Device class, it's the easiest way.

I would have done this way:

///////////////////////////////////////////////////////////////
// Device.h
...
using PowerSupplyPtr = std::shared_ptr<PowerSupply>;
using OutputPtr = std::shared_ptr<Output>;
using OutputList = std::list< OutputPtr >;

class Device {
public:
    Device();
    virtual ~Device();
    virtual PowerSupplyPtr getPowerSupply() = 0;
    virtual OutputList getOutputList() = 0;
    static DevicePtr create( const std::string& name );
};

///////////////////////////////////////////////////////////////
// EchoShow.h
#include "Device.h"
class EchoShow : public Device {
public:
    EchoShow();
    virtual PowerSupplyPtr getPowerSupply() override;
    virtual OutputList getOutputList() override;
private:
    PowerSupplyPtr _power;
    OutputPtr _sound;
    OutputPtr _wifi;
};
using DevicePtr = std::shared_ptr<Device>; 

///////////////////////////////////////////////////////////////
// EchoShow.cpp
#include "EchoShow.h"
EchoShow::EchoShow() 
 : _power( new PowerSupplyAwesome )
 , _sound( new SoundOutput )
 , _wifi( new WifiOutput ) {}

PowerSupplyPtr EchoShow::getPowerSupply() {
    return _power;
}

OutputList EchoShow::getOutputList() {
   return OutputList{ { _sound, _wifi } };
}

///////////////////////////////////////////////////////////////
// Device.cpp 
#include "Device.h"
#include "EchoShow.h"
#include "EchoDot.h"

DevicePtr Device::create( const std::string& name ) {
     if ( name == "Echo Show" ) return DevicePtr( new EchoShow );
     if ( name == "Echo Dot" ) return DevicePtr( new EchoDot );
     return {};
}

Answer 5

I suggest introducing the following 5 classes as shown below:

• PowerStatusProvider -> interface/policy class for power status and such
• BatteryStatus -> concrete implementation for all things battery powered
• WiredStatus -> concrete implementation for all things powered by a wire
• OutputHandler -> publish status to whatever endpoint using provided services (Screen, Speaker)
• Device -> The actual abstraction to your gadget

I used structs instead of classes to shorten notation. The battery level is retrieved via a dependency injected functor. C++20 has std::format, maybe your compiler has that as well.

// Assuming Screen and Speaker are provided in a common interface 
struct OutputDevice{
    virtual void publish(std::string const & output) = 0;
    virtual ~OutputDevice()=default;
}

using OutputDevice_sp = std::shared_ptr<OutputDevice>;

struct Screen : OutputDevice{
    void publish(std::string const & output) override {
        // ...
        };
};

struct Speaker : OutputDevice{
    void publish(std::string const & output) override {
        // ...
        };
};

/// Here goes the actual implementation

struct PowerStatusProvider{
    virtual std::string to_string(bool Connected) const = 0;
    virtual ~PowerStatusProvider()=default;
};

struct BatteryStatus : PowerStatusProvider{
    BatteryStatus(std::function<double()> BatteryLevelProvider)
    : mBatteryLevelProvider(BatteryLevelProvider){}
    
    std::string to_string(bool Connected) const override
    {
        if (Connected)
            return "Battery is charging";
        else
            return std::format("Battery is not charging and battery level is {}%",mBatteryLevelProvider());
    }
private:
    std::function<double()> mBatteryLevelProvider;
};

struct WiredStatus : PowerStatusProvider{
    std::string to_string(bool Connected) const override
    {
        if (Connected)
            return "Device connected";
        else
            return "Device not connected";
    }
};

struct OutputHandler{
    OutputHandler(std::vector<OutputDevice_sp> Outputs)  
    : mOutputs(Outputs) {}
    
  void handle(std::string const & output) const {
      for (auto &&output : mOutputs) {
          output->publish(output);
      }
  } 

private:
    std::vector<OutputDevice_sp> mOutputs;
};

using PowerStatusProvider_sp = std::shared_ptr<PowerStatusProvider>;
using OutputHandler_sp = std::shared_ptr<OutputHandler>;


struct Device{
    struct Device(std::string Name, PowerStatusProvider_sp PSP, OutputHandler_sp OH)
    : mName(Name)
    , mPSP(PSP)
    , mOH(OH) 
    {}

    void update_status() const{
        mOH->handle(mPSP->to_string());
    }
  
private:
    std::string mName;
    std::shared_ptr<PowerStatusProvider> mPSP;
    std::shared_ptr<OutputHandler> mOH;
};

Answer 6

you can use observer pattern here.