Стать старшим среди миллионов программистов!

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

  • Абстракция
  • Инкапсуляция
  • Наследование
  • Полиморфизм

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

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

SOLID означает «жесткий», более применимо; вы будете кодировать «жестко». Шучу, это набор из следующих 5 принципов:

  1. Принцип единой ответственности
  2. Открытый/закрытый принцип
  3. Принцип подстановки Лисков
  4. Принцип разделения интерфейсов
  5. Принцип инверсии зависимостей

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

1. Принцип единой ответственности

Первый принцип соответствует букве S в слове SOLID. Основное содержание:

Класс должен иметь только 1 ответственность
(класс может быть изменен только по 1 причине)

Чтобы понять этот принцип, давайте возьмем пример с классом, который нарушает этот принцип. У нас есть 1 класс следующим образом:

public class ReportManager()
{
   public void ReadDataFromDB();
   public void ProcessData();
   public void PrintReport();
}

Этот класс выполняет до трех функций: чтение данных из БД, обработка данных, печать результатов. Следовательно, пока мы меняем БД, меняем способ вывода результатов… нам придется модифицировать этот класс. Позже класс пополнится. По принципу мы должны разделить этот класс на 3 отдельных класса. В то время как количество классов выше, чем исправления будут проще, в более коротком классе также должно быть меньше ошибок.

2. Принцип открыт/закрыт

Второй принцип, соответствующий букве O в слове SOLID. Основное содержание:

открыт для расширения, но закрыт для модификации.

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

3. Принцип подстановки Лисков.

Третий принцип, соответствующий букве L в слове SOLID. Основное содержание:

В программе объекты подкласса могут заменить родительский класс без изменения корректности программы.

Несколько запутанно? Никаких проблем, когда я впервые прочитал это тоже. Представьте, что у вас есть родительский класс с именем Duck. Классы DabblingDuck, Eider могут наследовать этот класс, программа работает нормально. Однако, если мы напишем класс ElectricDuck, батарею нужно запустить. Когда этот класс наследует класс Duck, из-за того, что никакая батарея не может работать, это вызовет ошибку.Это нарушение этого принципа.

4. Принцип разделения интерфейса

Четвертый принцип, соответствующий букве I в слове SOLID. Основное содержание:

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

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

5. Принцип обращения зависимостей

Последний принцип соответствует букве D в слове SOLID. Принципиальное содержание:

  1. Модули высокого уровня не должны зависеть от модулей низкого уровня.
    Оба должны зависеть от абстракции.
  2. Интерфейс (абстракция) не должен зависеть от деталей, а наоборот.
    (Классы общаются друг с другом через интерфейсы,
    не через реализацию.)

Этот принцип довольно умен; Я возьму практический пример. Все мы знаем 2 типа ламп: круглые лампы и люминесцентные лампы. Все они имеют круглые хвосты, чтобы легко заменить круглые лампочки флуоресцентными лампами друг для друга.

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

В коде тоже при применении Dependency Inverse нам нужно заботиться только об интерфейсе. Чтобы подключиться к базе данных, нам нужно вызвать функцию Get, Save… интерфейса IDataAccess. При замене базы нам нужно изменить реализацию этого интерфейса.

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