SOLID

SOLID - это аббревиатура, представляющая собой пять основных принципов объектно-ориентированного программирования и проектирования. Эти принципы были сформулированы Робертом Мартином (Uncle Bob) и стали стандартом в индустрии программной разработки.

История развития SOLID началась с публикации Робертом Мартином его книги "Объектно-ориентированный анализ и проектирование с примерами приложений" в 2000 году. В этой книге он впервые представил эти принципы и описал их значение для создания гибкого, расширяемого и легко поддерживаемого программного обеспечения.

С тех пор SOLID стал широко распространенным набором принципов, который используется в индустрии программирования для повышения качества и надежности кода.

• S - SRP (Принцип единственной ответственности): Объект должен иметь только одну причину для изменения.

• O - OCP (Принцип открытости/закрытости): Программные сущности должны быть открыты для расширения, но закрыты для модификации.

• L - LSP (Принцип подстановки Барбары Лисков): Объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.

• I - ISP (Принцип разделения интерфейса): Клиенты не должны зависеть от методов, которые они не используют.

• D - DIP (Принцип инверсии зависимостей): Зависимости внутри системы строятся на основе абстракций, а не на основе конкретных реализаций.

SRP

Принцип единственной ответственности (SRP) - это принцип, сформулированный Робертом Мартином (Uncle Bob), который утверждает, что каждый объект должен иметь одну и только одну причину для изменения, то есть каждый объект должен быть ответственен за выполнение только одной задачи или иметь только одну обязанность.

S - Single (Единственная): Один объект должен быть ответственен только за один аспект функциональности программы.

R - Responsibility (Ответственность): Каждый объект должен быть ответственен за выполнение только одной задачи или иметь только одну обязанность.<o:p></o:p>

Примеры и сценарии применения SRP

Пример 1: Класс управления базой данных.

• Плохой пример: Один класс, отвечающий и за управление подключением к базе данных, и за выполнение SQL-запросов.

• Хороший пример: Разделение функциональности на два класса: один для управления подключением к базе данных, другой для выполнения SQL-запросов. Каждый класс отвечает только за свою область ответственности.

Пример 2: Класс для отправки электронной почты.

• Плохой пример: Класс, который отвечает за формирование сообщения, подключение к SMTP-серверу и отправку сообщения.

• Хороший пример: Разделение функциональности на три класса: один для формирования сообщения, второй для подключения к SMTP-серверу и третий для отправки сообщения.

Плюсы и минусы

Плюсы:

•  Улучшение читаемости и понимаемости кода.

•  Уменьшение связанности между классами.

• Упрощение тестирования и отладки.

Минусы:

• Возможное увеличение количества классов и интерфейсов.

• Не всегда явно определяется, что именно является "одной обязанностью" для класса.

Предположим, у нас есть класс FileManager, который отвечает за чтение и запись данных в файл. Однако, в соответствии с SRP, этот класс должен быть ответственен только за одну обязанность. Разделим его функционал на два класса: FileReader и FileWriter

class FileReader {
public:
   std::string read(const std::string& filename) {
       std::ifstream file(filename);
       std::string content;
       if (file.is_open()) {
           std::getline(file, content, '\0');
           file.close();
       }
       return content;
   }
};

class FileWriter {
public:
   void write(const std::string& filename, const std::string& content) {
       std::ofstream file(filename);
       if (file.is_open()) {
           file << content;
           file.close();
       }
   }
};

int main() {
   FileReader reader;
   std::string content = reader.read("example.txt");
   std::cout << "Read from file: " << content << std::endl;

   FileWriter writer;
   writer.write("output.txt", "Hello, World!");

   return 0;
}

OCP

Принцип открытости/закрытости (OCP) - это принцип, сформулированный Бертраном Майером, который утверждает, что программные сущности (классы, модули, функции и т. д.) должны быть открыты для расширения, но закрыты для модификации. Иными словами, новый функционал должен добавляться путем расширения, а не изменения существующего кода. 

Примеры и сценарии применения OCP:

• Пример 1: Функции сортировки.

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

Хороший пример: Создание интерфейса сортировки и реализация конкретных алгоритмов сортировки в отдельных классах. При необходимости нового критерия сортировки добавляется новый класс, реализующий интерфейс сортировки.

• Пример 2: Фильтрация данных.

Плохой пример: Изменение кода фильтрации для добавления новых условий.

Хороший пример: Создание набора фильтров, каждый из которых реализует конкретное условие фильтрации. Новые фильтры могут быть добавлены без изменения существующего кода.

Предположим, у нас есть класс Shape, который имеет метод calculateArea(), который должен рассчитывать площадь для разных фигур. Используем наследование и полиморфизм, чтобы сделать класс Shape закрытым для модификации и открытым для расширения.

#include <iostream>

class Shape {
public:
   virtual double calculateArea() const = 0;
};

class Rectangle : public Shape {
private:
   double width;
   double height;
public:
   Rectangle(double w, double h) : width(w), height(h) {}
   double calculateArea() const override {
       return width * height;
   }
};

class Circle : public Shape {
private:
   double radius;
public:
   Circle(double r) : radius(r) {}
   double calculateArea() const override {
       return 3.14 * radius * radius;
   }
};

int main() {
   Rectangle rect(5, 10);
   std::cout << "Area of rectangle: " << rect.calculateArea() << std::endl;

   Circle circle(7);
   std::cout << "Area of circle: " << circle.calculateArea() << std::endl;

   return 0;
}

LSP

Принцип подстановки Барбары Лисков (LSP) - это принцип объектно-ориентированного программирования, введенный Барбарой Лисков в 1987 году. Он утверждает, что объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.

Примеры и сценарии применения LSP

• Пример 1: Использование наследования.

Плохой пример: Создание подтипа квадрата от прямоугольника, где методы для изменения ширины и высоты переопределяются таким образом, что они не соответствуют контракту базового класса.

Хороший пример: Подтип квадрата от прямоугольника, где ширина и высота меняются одновременно, что соответствует контракту базового класса прямоугольника.

• Пример 2: Использование интерфейсов.

Плохой пример: Использование интерфейса, где некоторые методы не реализуются в подтипе.

Хороший пример: Использование интерфейса, где все методы реализуются в подтипе и выполняются корректно.

Плюсы и минусы

Плюсы:

• Повышение гибкости и расширяемости программного кода.

• Сохранение принципа подстановки, что позволяет безопасно использовать подтипы вместо их базовых классов.

• Улучшение тестируемости кода

Минусы:

• Не всегда легко определить, является ли подтип действительно заменяемым на экземпляр базового класса.

• Необходимость строгого следования контракту базового класса при создании подтипа. 

Предположим, у нас есть иерархия классов Bird и Penguin. По LSP, должно быть возможно заменить экземпляр базового класса (Bird) его производным классом (Penguin) без изменения корректности программы

#include <iostream>


class Bird {
public:
   virtual void fly() const {
       std::cout << "Flying..." << std::endl;
   }
};


class Penguin : public Bird {
public:
   void fly() const override {
       std::cout << "I can't fly!" << std::endl;
   }
};


void makeBirdFly(const Bird& bird) {
   bird.fly();
}


int main() {
   Bird bird;
   Penguin penguin;


   makeBirdFly(bird);
   makeBirdFly(penguin);


   return 0;
}

ISP

Принцип разделения интерфейса (ISP) - это принцип объектно-ориентированного программирования, который утверждает, что клиенты не должны зависеть от методов, которые они не используют. Вместо этого следует создавать узкоспециализированные интерфейсы, которые содержат только те методы, которые необходимы клиенту.

Примеры и сценарии применения ISP

• Пример 1: Интерфейсы для классов животных.

Плохой пример: Один интерфейс "Животное" с методами "дышать()", "перемещаться()" и "питаться()".

Хороший пример: Несколько узкоспециализированных интерфейсов: "Дышащее", "Двигающееся", "Питающееся", которые реализуют различные классы животных.

• Пример 2: Интерфейсы для пользовательского интерфейса.

Плохой пример: Один интерфейс "ПользовательскийИнтерфейс" с методами "отображать()", "редактировать()", "удалять()", "сохранять()".

Хороший пример: Разделение интерфейса на несколько узкоспециализированных интерфейсов: "Отображаемый", "Редактируемый", "Удаляемый", "Сохраняемый".

Плюсы и минусы

Плюсы:

• Уменьшение связанности между классами.

• Повышение читаемости и понимаемости кода.

• Улучшение тестируемости и поддерживаемости кода.

Минусы:

• Необходимость создания большего количества интерфейсов и классов.

• Дополнительная сложность при проектировании архитектуры программы.

Предположим, у нас есть интерфейс Worker, который имеет методы work() и eat(). Но некоторым работникам не нужно есть во время работы (ахаххаха). Разделим интерфейс на Worker и Eater, чтобы предоставить клиентам только те методы, которые им действительно нужны.

#include <iostream>


class Worker {
public:
   virtual void work() const = 0;
};


class Eater {
public:
   virtual void eat() const = 0;
};


class OfficeWorker : public Worker {
public:
   void work() const override {
       std::cout << "Working in the office..." << std::endl;
   }
};


class FactoryWorker : public Worker, public Eater {
public:
   void work() const override {
       std::cout << "Working in the factory..." << std::endl;
   }


   void eat() const override {
       std::cout << "Eating lunch..." << std::endl;
   }
};


int main() {
   OfficeWorker officeWorker;
   officeWorker.work();


   FactoryWorker factoryWorker;
   factoryWorker.work();
   factoryWorker.eat();


   return 0;
}

DIP

Принцип инверсии зависимостей (DIP) - это принцип объектно-ориентированного программирования, который утверждает, что зависимости внутри системы должны строиться на основе абстракций, а не на основе конкретных реализаций. Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба типа модулей должны зависеть от абстракций.

Примеры и сценарии применения DIP

Пример 1: Система управления заказами.

Плохой пример: Модуль управления заказами зависит от конкретной реализации модуля базы данных.

Хороший пример: Модуль управления заказами зависит от интерфейса базы данных, а конкретная реализация выбирается во время выполнения.

Пример 2: Обработка данных.

Плохой пример: Модуль обработки данных напрямую зависит от классов для чтения и записи данных.

Хороший пример: Модуль обработки данных зависит от абстрактного интерфейса для чтения и записи данных, а конкретные реализации могут быть выбраны динамически.

Плюсы и минусы

Плюсы:

• Уменьшение связанности между модулями.

• Повышение гибкости и расширяемости системы.

• Улучшение тестируемости и поддерживаемости кода.

Минусы:

• Дополнительная сложность внедрения зависимостей и настройки системы.

• Необходимость более тщательного проектирования архитектуры программы.

Предположим, у нас есть класс Light и класс Switch, который управляет светом. Согласно DIP, класс Switch не должен напрямую зависеть от класса Light, а должен зависеть от абстракции, например, интерфейса Switchable.

#include <iostream>


class Switchable {
public:
   virtual void turnOn() const = 0;
   virtual void turnOff() const = 0;
};


class Light : public Switchable {
public:
   void turnOn() const override {
       std::cout << "Light is on" << std::endl;
   }


   void turnOff() const override {
       std::cout << "Light is off" << std::endl;
   }
};


class Switch {
private:
   const Switchable& device;
public:
   Switch(const Switchable& s) : device(s) {}


   void toggle() {
       // Some logic to toggle the device
       if (isOn) {
           device.turnOff();
           isOn = false;
       } else {
           device.turnOn();
           isOn = true;
       }
   }
private:
   bool isOn = false;
};


int main() {
   Light light;
   Switch lightSwitch(light);


   lightSwitch.toggle();
   lightSwitch.toggle();


   return 0;
}

KISS

Введение

Принцип KISS (Keep It Simple, Stupid) подчеркивает, что в разработке программного обеспечения следует стремиться к максимальной простоте решений. Принцип возник из понимания того, что простые решения обычно легче понять, сопровождать и разрабатывать, чем сложные.

Значение "Простоты":

Простота проектирования: Отличительная черта простого дизайна - это отсутствие излишней сложности и лишних деталей. Простой дизайн легче понимать и изменять.

Простота кода: Простой код - это код, который написан ясно и лаконично. Он легко читается и понимается другими разработчиками.

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

Принцип KISS призывает к осмысленному подходу к проектированию и разработке программного обеспечения, чтобы достичь баланса между простотой и функциональностью, обеспечивая тем самым создание более эффективных и надежных решений.

Примеры и сценарии применения KISS

Пример 1: Проектирование класса.

Плохой пример: Класс с избыточным количеством методов и сложной логикой, которая трудно поддерживать и изменять.

Хороший пример: Класс, который решает только одну задачу и имеет четко определенную ответственность.

Пример 2: Выбор архитектуры приложения.

Плохой пример: Использование сложной многоуровневой архитектуры, когда для решения задачи достаточно простой клиент-серверной модели.

Хороший пример: Применение простой архитектуры, которая соответствует требованиям проекта без излишней сложности.

Плюсы и минусы

Плюсы:

• Улучшение понимания и читаемости кода.

• Уменьшение затрат на разработку и сопровождение программного обеспечения.

• Повышение эффективности и надежности решений.

Минусы:

• Риск упрощения до уровня, когда функциональность становится недостаточной для решения задачи.

• Не всегда легко определить, какая степень простоты является оптимальной для конкретного проекта.

Предположим, у нас есть задача по созданию простой программы для вычисления факториала числа. Мы хотим следовать принципу KISS и написать программу максимально простую и понятную.

#include <iostream>


// Директива для использования пространства имен std
using namespace std;


// Функция для вычисления факториала числа
unsigned long long factorial(int n) {
   unsigned long long result = 1;
   // Используем цикл для умножения чисел от 2 до n
   for (int i = 2; i <= n; ++i) {
       result *= i;
   }
   return result;
}


int main() {
   int num;
   cout << "Enter a number: ";
   cin >> num;


   // Проверка на отрицательные числа
   if (num < 0) {
       cout << "Factorial is not defined for negative numbers." << endl;
   } else {
       // Вывод результата вычисления факториала
       cout << "Factorial of " << num << " is: " << factorial(num) << endl;
   }


   return 0;
}

Этот пример демонстрирует простую и понятную реализацию задачи без излишних усложнений или сложных алгоритмов. Он следует принципу KISS, делая код легко читаемым и понятным для других разработчиков. Также используем директиву using namespace std, что позволяет не указывать std:: каждый раз и повышает читаемость программы, это является хорошим тоном для KISS. Можно указывать эту директиву и внутри методов или функций, это упростит работу, если проект будет масштабироваться и помимо std:: появятся и другие пространства имен.

YAGNI

Введение

Принцип YAGNI (You Aren't Gonna Need It) представляет собой методологию разработки программного обеспечения, которая призывает избегать добавления функциональности, которая не требуется на данный момент. Суть принципа заключается в том, чтобы не вносить излишнюю сложность в проект, предполагая, что эта функциональность может быть полезной в будущем. Вместо этого следует сосредоточиться на решении текущих задач и добавлять новую функциональность только при необходимости.

Основные принципы

Отсроченное решение проблемы: Решение проблемы откладывается до тех пор, пока она не станет актуальной для решения текущих задач.

Минимализм в решениях: Предпочтение отдается простым и минимальным решениям, которые решают текущую задачу, без лишней функциональности.

Реактивный подход: Решения разрабатываются в ответ на реальные потребности, а не на основе гипотетических ситуаций или возможных будущих требований.

Примеры и сценарии применения YAGNI

Пример 1: Разработка функциональности.

Плохой пример: Добавление сложной системы управления пользователями, когда проекту требуется только базовая аутентификация.

Хороший пример: Создание простого механизма аутентификации для удовлетворения текущих требований, с возможностью добавления дополнительной функциональности в будущем, если это потребуется.

Пример 2: Выбор технологий.

Плохой пример: Использование сложного фреймворка, когда для решения задачи достаточно простых инструментов.

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

Плюсы и минусы

Плюсы:

• Уменьшение сложности программного обеспечения.

• Улучшение производительности и эффективности разработки.

• Более гибкое и адаптивное решение проблем.

Минусы:

• Риск недооценки будущих потребностей и необходимости функциональности.

• Не всегда легко определить, какая функциональность является излишней в данный момент времени.

Предположим, у нас есть простая программа, которая должна показать приветствие пользователю. Вместо того, чтобы сразу добавлять директиву using namespace std, функциональность для разных языков, мы начнем с минимальной реализации только на английском языке.

#include <iostream>


int main() {
   std::cout << "Hello, world!" << std::endl;
   return 0;
}

Этот код соответствует принципу YAGNI, поскольку мы добавляем только минимально необходимую функциональность, а именно вывод приветствия на английском языке. Если в будущем потребуется поддержка других языков, мы можем добавить эту функциональность в программу в соответствии с реальными потребностями.

BDUF

Введение

Принцип BDUF (Big Design Up Front) - это методология разработки программного обеспечения, которая предполагает создание подробного и обширного дизайна до начала фактической разработки. Основная идея состоит в том, чтобы подробно спроектировать все аспекты системы, включая структуру, архитектуру, интерфейсы и т. д., прежде чем приступать к написанию кода.

Принцип BDUF может быть полезен в некоторых сценариях разработки, особенно при работе над крупными и сложными проектами, однако важно учитывать его ограничения и стремиться к балансу между предварительным проектированием и гибкостью в процессе разработки.

Основные принципы

Предварительное планирование: Весь дизайн системы выполняется до начала разработки, что позволяет выявить и учесть все аспекты проекта заранее.

Детальное специфицирование: Каждая часть системы детально описывается и проектируется, включая функциональные и нефункциональные требования, что обеспечивает ясное представление о том, как будет работать система.

Минимизация изменений: После завершения дизайна минимизируются изменения в архитектуре или функциональности системы, что позволяет избежать необходимости перепроектирования и изменения уже написанного кода.

Примеры и сценарии применения BDUF

Пример 1: Разработка большого корпоративного приложения.

 Плохой пример: Подробное специфицирование и дизайн всей системы заранее, не учитывая возможные изменения требований или технологий.

Хороший пример: Создание высокоуровневого общего дизайна системы, с последующим уточнением и дополнением дизайна по мере продвижения проекта.

Пример 2: Разработка мобильного приложения.

Плохой пример: Разработка подробного дизайна интерфейса и функциональности приложения до проведения пользовательских тестов или получения обратной связи от заказчика.

Хороший пример: Быстрое создание прототипов и MVP-версий приложения для получения обратной связи и определения реальных требований пользователей, а затем уточнение и дополнение дизайна на основе этой информации.

Плюсы и минусы BDUF

Плюсы:

• Полное понимание требований и архитектуры системы до начала разработки.

• Уменьшение риска возникновения проблем и ошибок в процессе разработки.

• Возможность более эффективного планирования и управления проектом.

Минусы:

• Риск недостаточной гибкости и адаптивности к изменяющимся требованиям.

• Затраты времени и ресурсов на создание подробного дизайна, который может потребовать переработки в процессе разработки.

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

#include <iostream>
#include <vector>
#include <string>


class Note {
private:
   std::string content;
public:
   Note(const std::string& content) : content(content) {}


   void display() const {
       std::cout << "Note: " << content << std::endl;
   }
};


class Notebook {
private:
   std::vector<Note> notes;
public:
   void add(const std::string& content) {
       notes.push_back(Note(content));
   }


   void displayAll() const {
       std::cout << "All Notes:" << std::endl;
       for (const auto& note : notes) {
           note.display();
       }
   }
};


int main() {
   Notebook notebook;
   notebook.add("First note");
   notebook.add("Second note");


   notebook.displayAll();


   return 0;
}

В этом примере мы начали с создания минимальной функциональности для приложения - добавления и просмотра заметок. Мы не тратим время на подробное проектирование всего приложения заранее, а постепенно дополняем его новыми функциями по мере необходимости.

APO

Введение

Принцип APO (Avoid Premature Optimization) призывает разработчиков избегать оптимизации кода до тех пор, пока это не станет необходимым. Преждевременная оптимизация может привести к излишнему усложнению кода, увеличению времени разработки и снижению его читаемости, не принося при этом существенного улучшения производительности.

Основные принципы

Фокус на функциональности: Главным приоритетом при разработке должна быть функциональность программного обеспечения и его соответствие требованиям, а не оптимизация кода для улучшения производительности.

Измерение производительности: Оптимизация кода должна основываться на реальных данных о производительности приложения, полученных в результате тестирования, а не на предположениях или догадках.

Разумный баланс: Важно найти баланс между производительностью и читаемостью кода. Преждевременная оптимизация может привести к усложнению кода и увеличению его сложности, что усложнит его сопровождение и разработку.

Примеры и сценарии применения APO

Пример 1: Оптимизация алгоритма.

Плохой пример: Проведение оптимизации сложного алгоритма до того, как будет установлено, что он является узким местом в производительности приложения.

Хороший пример: Проведение оптимизации алгоритма только после того, как будет установлено, что он является узким местом в производительности приложения, и оптимизация этого алгоритма принесет значительное улучшение производительности.

Пример 2: Использование структур данных.

Плохой пример: Выбор сложной структуры данных для хранения данных без анализа их использования и частоты доступа.

Хороший пример: Выбор структуры данных на основе реальных данных о ее использовании и частоте доступа, что позволит оптимизировать производительность приложения.

Плюсы и минусы

Плюсы:

• Уменьшение риска излишней сложности кода.

• Увеличение скорости разработки за счет сосредоточения на функциональности.

• Улучшение читаемости и поддерживаемости кода.

Минусы:

• Риск упустить возможности для оптимизации, которые могут быть важными для производительности приложения.

• Необходимость пересмотра и оптимизации кода в дальнейшем, если это станет необходимым.

Предположим, у нас есть задача по написанию программы для нахождения суммы элементов в массиве. Мы начнем с простой и понятной реализации, а затем, если это будет необходимо, проведем оптимизацию кода.

#include <iostream>
#include <vector>


// Функция для нахождения суммы элементов в массиве
int sum(const std::vector<int>& array) {
   int result = 0;
   for (int num : array) {
       result += num;
   }
   return result;
}


int main() {
   std::vector<int> array = {1, 2, 3, 4, 5};


   // Вывод суммы элементов массива
   std::cout << "Sum of elements: " << sum(array) << std::endl;


   return 0;
}

В этом примере мы начали с простой и понятной реализации функции для нахождения суммы элементов в массиве. Этот код соответствует принципу APO, так как мы не тратим время на оптимизацию кода, который работает правильно и удовлетворяет текущим требованиям. Если в будущем мы обнаружим, что эта функция становится узким местом в производительности программы, мы можем провести оптимизацию кода.

Бритва Оккама (Occam's Razor)

Введение

В программировании принцип бритвы Оккама подразумевает выбор наиболее простого и понятного решения для решения задачи. Это включает в себя написание чистого, понятного и эффективного кода, избегая излишних сложностей и избыточной функциональности.

Основные принципы

Простота кода: Программист должен стремиться к написанию простого и легко читаемого кода. Это делает код более поддерживаемым и понятным для других разработчиков.

Минимализм: Избегайте добавления избыточной функциональности или сложных алгоритмов там, где это необходимо. Лучше использовать простые решения, которые решают поставленную задачу.

Эффективность: Простой код обычно более эффективен и производителен. Сложные структуры и алгоритмы могут замедлить работу программы.

Примеры и сценарии применения

Пример 1: Выбор структуры данных.

Плохой пример: Использование сложной структуры данных, такой как дерево, когда для хранения данных достаточно массива.

Хороший пример: Использование простых структур данных, таких как массив или хэш-таблица, когда они соответствуют требованиям задачи.

Пример 2: Рефакторинг кода.

Плохой пример: Дублирование кода в разных частях программы, чтобы избежать небольшого увеличения сложности кода.

Хороший пример: Рефакторинг кода для удаления дублирования и создания более простых и поддерживаемых структур.

Плюсы и минусы

Плюсы:

• Более понятный и поддерживаемый код.

• Увеличение производительности и эффективности программы.

• Уменьшение вероятности ошибок и багов.

Минусы:

• Может потребоваться больше времени на проектирование и анализ, чтобы найти наилучшее простое решение.

• Не всегда простое решение является наилучшим в конкретном контексте.

Предположим, у нас есть программа для определения является ли введенное число простым. Мы можем использовать простой и эффективный алгоритм, который проверяет делится ли число на целые числа от 2 до корня из этого числа. Этот подход следует принципу Бритвы Оккама, так как мы используем наименьшее количество предположений для решения задачи.

#include <iostream>
#include <cmath>


// Функция для проверки, является ли число простым
bool isPrime(int num) {
   if (num <= 1) {
       return false;
   }
   int sqrtNum = sqrt(num);
   for (int i = 2; i <= sqrtNum; ++i) {
       if (num % i == 0) {
           return false;
       }
   }
   return true;
}


int main() {
   int num;
   std::cout << "Enter a number: ";
   std::cin >> num;


   if (isPrime(num)) {
       std::cout << num << " is a prime number." << std::endl;
   } else {
       std::cout << num << " is not a prime number." << std::endl;
   }


   return 0;
}

В этом примере мы используем простой алгоритм для определения, является ли число простым. Мы не используем более сложные или избыточные методы, так как они не нужны для решения поставленной задачи. Такой подход соответствует принципу Бритвы Оккама, который помогает нам выбирать наиболее простые и эффективные решения для задач.

DRY

Введение

Принцип DRY (Don't Repeat Yourself) подчеркивает важность избегания дублирования кода в программном обеспечении. Суть этого принципа заключается в том, что каждый фрагмент кода должен иметь единственное, неизменное представление в системе. Если у вас есть повторяющийся код, это может привести к проблемам с поддержкой, таким как необходимость внесения изменений в несколько мест при изменении требований.

Основные принципы

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

Переиспользуйте код: Используйте механизмы переиспользования кода, такие как функции, классы или библиотеки, чтобы избежать повторений. Это делает код более поддерживаемым и уменьшает вероятность ошибок.

Создавайте абстракции: Подумайте о том, как можно обобщить повторяющиеся конструкции, чтобы создать абстракции, которые можно использовать повторно в различных контекстах.

Примеры и сценарии применения

Пример 1: Функции для обработки данных.

Плохой пример: Повторение одних и тех же операций обработки данных в разных частях программы.

Хороший пример: Создание отдельной функции для обработки данных и вызов этой функции везде, где это необходимо.

Пример 2: Использование классов и наследования.

Плохой пример: Повторение аналогичной логики в разных классах.

Хороший пример: Создание базового класса с общей функциональностью и наследование от него в классах-потомках, чтобы избежать дублирования кода.

Плюсы и минусы DRY

Плюсы:

• Улучшение поддерживаемости кода.

• Сокращение вероятности ошибок и багов.

• Увеличение производительности разработки за счет повторного использования кода.

Минусы:

• Введение абстракций может усложнить понимание кода для новых разработчиков.

• Иногда стремление к DRY может привести к излишней сложности кода, особенно если вынесенная логика используется только в одном месте.

Предположим, у нас есть программа для обработки данных о студентах. У нас есть структура Student, представляющая каждого студента, и мы хотим вычислить средний балл для каждого студента на основе его оценок. Вместо того, чтобы дублировать код вычисления среднего балла для каждого студента, мы можем создать общую функцию для вычисления среднего балла и использовать ее для каждого студента.

#include <iostream>
#include <vector>


// Структура, представляющая студента
struct Student {
   std::string name;
   std::vector<int> grades;


   // Метод для вычисления среднего балла студента
   double calculateAverageGrade() const {
       if (grades.empty()) {
           return 0.0;
       }


       int sum = 0;
       for (int grade : grades) {
           sum += grade;
       }
       return static_cast<double>(sum) / grades.size();
   }
};


int main() {
   // Создаем объекты студентов
   Student student1 = {"Alice", {85, 90, 95}};
   Student student2 = {"Bob", {75, 80, 85, 90}};


   // Выводим средний балл для каждого студента
   std::cout << student1.name << "'s average grade: " << student1.calculateAverageGrade() << std::endl;
   std::cout << student2.name << "'s average grade: " << student2.calculateAverageGrade() << std::endl;


   return 0;
}

В этом примере мы определяем общий метод calculateAverageGrade() в структуре Student, который может быть использован для вычисления среднего балла для любого студента. Это позволяет избежать дублирования кода и обеспечивает единый подход к вычислению среднего балла для всех студентов. Таким образом, мы следуем принципу DRY, делая наш код более чистым и поддерживаемым.

LOD

Введение

Принцип LOD (Law of Demeter), также известный как принцип минимальной связности, представленный как "закон разума" или "закон золотого среднего", утверждает, что объект должен иметь доступ только к своим непосредственным "друзьям" (непосредственным членам класса), а не к "друзьям друзей" (через свои поля).

Основные принципы

Минимизация связей: Объект должен иметь доступ только к объектам, которые он непосредственно содержит, а не к объектам, к которым он имеет доступ через свои поля или методы.

Уменьшение зависимостей: Цель состоит в том, чтобы снизить уровень зависимостей между классами, что делает программу более гибкой и менее уязвимой к изменениям.

Использование интерфейсов: Важно использовать интерфейсы для взаимодействия между объектами, чтобы снизить зависимость от конкретной реализации.

Примеры и сценарии применения

Пример 1: Взаимодействие между объектами.

Плохой пример: Объект A напрямую вызывает метод объекта B, который в свою очередь вызывает метод объекта C.

Хороший пример: Объект A вызывает метод объекта B, который предоставляет ему необходимую информацию, не требуя непосредственного доступа к объекту C.

Пример 2: Чтение данных.

Плохой пример: Объект получает данные из базы данных и обрабатывает их напрямую, вместо того, чтобы использовать слой доступа к данным.

Хороший пример: Объект использует слой доступа к данным для получения необходимых данных, чтобы снизить связность с базой данных и упростить тестирование.

Плюсы и минусы

Плюсы:

• Уменьшение связности и зависимостей между классами.

• Увеличение гибкости и поддерживаемости программного обеспечения.

• Улучшение тестируемости кода за счет уменьшения зависимостей.

Минусы:

• Возможно увеличение количества классов и интерфейсов, что может усложнить структуру программы.

• Некоторые сценарии могут потребовать больше усилий для соблюдения принципа LOD

Предположим, у нас есть класс Person, который представляет человека, и класс Job, который представляет рабочую должность. Мы хотим, чтобы Person имел метод для установки рабочей должности, но мы не хотим, чтобы Person напрямую имел доступ к деталям класса Job. Вместо этого мы можем передать только необходимую информацию о должности.

#include <iostream>
#include <string>
// Класс для представления рабочей должности
class Job {
private:
   std::string title;
public:
   Job(const std::string& t) : title(t) {}


   const std::string& getTitle() const {
       return title;
   }
};
// Класс для представления человека
class Person {
private:
   std::string name;
   Job* job;
public:
   Person(const std::string& n) : name(n), job(nullptr) {}
   void setJobTitle(const std::string& title) {
       // Создаем объект Job с переданным названием должности
       Job newJob(title);
       // Передаем только необходимую информацию (название должности)
       setJob(&newJob);
   }
   void setJob(Job* newJob) {
       job = newJob;
   }
   void displayInfo() const {
       std::cout << "Name: " << name << std::endl;
       if (job) {
           std::cout << "Job title: " << job->getTitle() << std::endl;
       } else {
           std::cout << "No job assigned" << std::endl;
       }
   }
};


int main() {
   Person person("Alice");
   person.setJobTitle("Software Engineer");
   person.displayInfo();
   return 0;
}

В этом примере Person имеет метод setJobTitle, который позволяет устанавливать рабочую должность для человека. Однако Person не имеет прямого доступа к деталям класса Job. Вместо этого мы передаем только необходимую информацию о должности методу setJob, который устанавливает соответствующий объект Job. Это соответствует принципу LOD, так как Person имеет доступ только к необходимой информации для выполнения своих задач.

Каждый из принципов имеет свои преимущества и недостатки, и их выбор зависит от конкретных требований и контекста проекта. Однако следование этим принципам способствует созданию высококачественного и поддерживаемого программного обеспечения.

Исходя из проведенного анализа, можно сделать вывод о важности применения принципов проектирования и разработки программного обеспечения для создания эффективных и надежных программных систем.