S.O.L.I.D на примерах С++

Для того чтобы привести вышеприведённый код в соответствие с принципом единственной ответственности, создадим ещё два класса, единственной задачей которых является работа со своей выполняемой функцией, в частности — сохранение в БД и извлечение объектов класса Animal, обеспечение форматной печати:

class Animal {
    string m_Name;
  public:
    Animal(string iName):m_Name(iName){}
    string GetName() {return m_Name;} 
};

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

class AnimalSaver {
    Animal *m_animal;
  public:
    AnimalSaver(Animal *iAnimal): m_animal(iAnimal){}
    void Save() { 
      // код сохранения в базу данных 
      db << m.animal->GetName();
    }
};

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

class AnimalPrinter {
    Animal *m_animal;
  public:
    AnimalPrinter(Animal *iAnimal): m_animal(iAnimal){}
    void Print() { 
      // код печати куда либо
      cout << m.animal->GetName();
    }
}

Данный пример иллюстрирует только разбиение класса на классы своей ответственности. Лучший вариант - было бы объявить сначала абстрактные классы AbstractSaver и AbstractPrinter. И уже на из основе, путем наследования, получить первоначальные конкретные реализации.

Как привести функцию AnimalSound в соответствие с принципом открытости-закрытости? Например - так:

class Animal {
  ...
  virtual string MakeSound() = 0;
};

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

class Lion: public Animal {
  ...
  string MakeSound() override { rerurn "roar";}
};

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

class Mouse: public Animal {
  ...
  string MakeSound() override { rerurn "squeak";}
};

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

class Snake: public Animal {
  ...
  string MakeSound() override { rerurn "hiss";}
};

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

void AnimalSounds(const vector<Animal> &animals) {
  for(const auto &i: animals) {
    cout << i.MakeSound() << endl;
  }
}

Можно заметить, что у класса Animal теперь есть виртуальный метод makeSound. При таком подходе нужно, чтобы классы, предназначенные для описания конкретных животных, расширяли бы класс Animal и реализовывали бы этот метод. В результате у каждого класса, описывающего животного, будет собственный метод makeSound, а при переборе массива с животными в функции AnimalSound достаточно будет вызвать этот метод для каждого элемента массива. Если теперь добавить в массив объект, описывающий новое животное, функцию AnimalSound менять не придётся. Мы привели её в соответствие с принципом открытости-закрытости.

Для того чтобы эта функция не нарушала принцип подстановки, преобразуем её с использованием требований, сформулированных Стивом Фентоном. Они заключаются в том, что методы, принимающие или возвращающие значения с типом некоего суперкласса (Animal в нашем случае) должны также принимать и возвращать значения, типами которых являются его подклассы. Вооружившись этими соображениями мы можем переделать функцию AnimalLegCount:

uint_t TotalAnimalLegCount(vector<Animal> &A) {
  uint_t Ret = 0; 
  for(const auto &i:A) Ret += i.LegCount();
  return Ret;
}

Теперь в классе Animal должен появиться чистый виртуальный метод LegCount, и его подклассам нужно его реализовать.

Принцип разделения интерфейса предостерегает нас от создания интерфейсов, подобных Shape из нашего примера. Клиенты (у нас это классы Circle, Square и Rectangle) не должны реализовывать методы, которые им не нужно использовать. Кроме того, этот принцип указывает на то, что интерфейс должен решать лишь какую-то одну задачу (в этом он похож на принцип единственной ответственности), поэтому всё, что выходит за рамки этой задачи, должно быть вынесено в другой интерфейс или интерфейсы.

class ICircle {
  public:
    virtual void drawCircle() = 0;
};

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

class ISquare {
  public:
    virtual void drawSquare() = 0;
};

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

class IRectangle {
  public:
    virtual void drawRectangle() = 0;
};

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

class Circle: public virtual ICircle  {
  public:
    void drawCircle() override {
      ...
    }
};

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

class Square: public virtual ISquare  {
  public:
    void drawSquare() override {
      ...
    }
};

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

class Rectangle: public virtual IRectangle  {
  public:
    void drawRectangle() override {
      ...
    }
};

Теперь интерфейс ICircle используется лишь для рисования кругов, равно как и другие специализированные интерфейсы - для рисования других фигур.

Класс Http не должен знать о том, что именно используется для организации сетевого соединения. Поэтому мы создадим интерфейс Connection:

class Connection {
  public:
    XRequest* request(string url, any options, string method) = 0;
};

Интерфейс Connection содержит описание метода request и мы передаём классу Http аргумент типа Connection:

class Http {
   Connection *connection;
  public:
    Http(Connection *iConnection)
      :connection(iConnection) {}
    XRequest *get(string url, any options) {
      return connection.request(url, any, "GET");
    }
    XRequest *post(string url, any options) {
      return connection.request(url, any, "POST");
    }
};

Теперь, вне зависимости от того, что именно используется для организации взаимодействия с сетью, класс Http может пользоваться тем, что ему передали, не заботясь о том, что скрывается за интерфейсом Connection.

Перепишем класс XMLHttpService таким образом, чтобы он реализовывал этот интерфейс:

class XMLHttpService: public Connection {
    XRequest *xhr;
  public:
    XMLHttpService() {
      xhr = new XMLHttpRequest();
    } 
    XRequest *request (string url, any options, string method){
       xhr->open(url);
       return xhr->send(any,method);  
    }
};

В результате мы можем создать множество классов, реализующих интерфейс Connection и подходящих для использования в классе Http для организации обмена данными по сети:

class NodeHttpService: public Connection {
    XRequest *request (string url, any options, string method){
      // ...
    }
};

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

class MockHttpService: public Connection {
    XRequest *request (string url, any options, string method){
      // ...
    }
};

Как можно заметить, здесь высокоуровневые и низкоуровневые модули зависят от абстракций. Класс Http (высокоуровневый модуль) зависит от интерфейса Connection (абстракция). Классы XMLHttpService, NodeHttpService и MockHttpService (низкоуровневые модули) также зависят от интерфейса Connection.

Кроме того, стоит отметить, что следуя принципу инверсии зависимостей, мы соблюдаем и принцип подстановки Барбары Лисков. А именно, оказывается, что типы XMLHttpService, NodeHttpService и MockHttpService могут служить заменой базовому типу Connection.