Учебник для начинающих по основам принципа SOLID и тому, как реализовать его в программировании на JavaScript.

Эта статья познакомит вас с основной концепцией принципа SOLID в языке JavaScript. У нас будет свой способ следовать этому принципу с каждым языком. Однако в JavaScript очень сложно применить этот принцип в коде.

Чтобы упростить вам задачу, я показал способ реализации кода. В примере я смешал 2 метода (класс и функцию), чтобы применить код по принципу SOLID.

Этот принцип помогает нам создавать программное обеспечение. Вот ключевые особенности принципа SOLID:

  • Повторное использование кода.
  • Легко изменить код функции.
  • Облегчает поддержку кода.
  • Легко написать тест для кода.

Что означает SOLID?

Мы подробно расскажем о каждом символе в слове «SOLID».

S: Единственная ответственность

Класс (метод) должен иметь только одну ответственность

Пример кода:

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

Цель этого принципа: разделить поведение класса (метода) на одно точечное действие. Разбейте код (класс, функцию) на как можно более мелкие компоненты.

Вместо создания суперинструментов с большим количеством (n) инструментов в одном. Просто разбейте инструмент поддержки на несколько инструментов, и каждый инструмент должен будет отвечать за все свои действия. Это помогает кодовой базе быть ясной: когда в классе SwordTool (или BowTool) изменяется новая функция, мы не затрагиваем другой инструмент.

O: открыто-закрыто

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

Этот принцип связан с обслуживанием кода и изменением нового кода. Для простоты понимания принципиального примера в системе у нас есть существующий класс Person (у него есть все атрибуты, методы человеческого прыжка, бега, еды… и т.д.). новая функция хочет добавить в нашу систему SwordMan или Wizard, и у них также есть все атрибуты и поведение, как у класса Person. Однако, если мы изменим текущее поведение класса person, чтобы удовлетворить пример требования, человек может прыгнуть на 1 м в высоту, а SwordMan может прыгнуть на 100 м по земле. мы должны изменить существующую функцию класса person. Это может иметь побочные эффекты в системе, в которой вы используете этот класс.

Пример кода:

Цель этого принципа:Новое изменение кода должно максимально избегать влияния на существование класса. Это помогает новой функции (новому изменению кода) не вызывать ошибок и не влиять на исходный класс. Вместо этого, чтобы изменить класс Person, мы можем расширить класс Person из класса SwordMan и класса Wizard и обрабатывать функциональность этого персонажа самостоятельно, и не беспокоиться о том, где использовать класс Person и новые классы, используемые для новой функции. без влияния на что-либо из старой функции.

Замена Лискова

Объекты в программе должны заменяться экземплярами их подтипов без изменения правильности этой программы. -Википедия

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

Пример кода:

#Q1: Является ли BlindSwordMan человеком? -> Да

# Q2: Может ли человек (суперкласс) просматривать облако? -> Да, я могу

# Q3: Может ли BlindSwordMan (подкласс) просматривать облако? -› Нет, я не могу

Неизвестная проблема может возникнуть в системе из первого примера, вы можете вызвать действие «просмотр» на BlindSwordMan. Поэтому, чтобы решить эту проблему, мы должны правильно определить абстрактные классы, а BlindSwordMan не должен реализовывать метод `view`, как обычный человек.

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

Разделение интерфейса

«Многие клиентские интерфейсы лучше, чем один интерфейс общего назначения. -Википедия»

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

Цель этого принципа: следуетразбить набор действий на более мелкие наборы, чтобы класс выполнял ТОЛЬКО требуемый набор действий. Это помогает нам уменьшить зависимости, менее связанные между классами в системе и более повторно используемые между интерфейсами.

Инверсия зависимости

Следует «полагаться на абстракции, [а не] на конкреции». -Википедия

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

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

Заключение

SOLID не для всего. С каждым языком у вас будет способ конкретно решить проблему. Некоторые принципы придерживаются ООП (классы, интерфейсы, абстракции), которые вы не можете применить к программированию с графическим интерфейсом (функциональное программирование).

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

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn и Discord.