25 вопросов, сколько вы будете
- Как понять принцип единой ответственности?
- Как судить, является ли ответственность достаточно разовой?
- Обязанности должны быть максимально простыми?
- Что такое принцип открытого-закрытого?
- Обязательно ли изменение кода означает нарушение принципа открытого-закрытого?
- Какие изменения кода определяются как расширения или модификации?
- Как открыть для расширения и закрыть для модификации?
- Как гибко применять принцип открытого-закрытого в проекте?
- Что такое принцип инверсии зависимостей (инверсии)?
- Каково сознание модулей высокого уровня и модулей низкого уровня?
- Как понять перевернутые два слова?
- Какие зависимости были изменены?
- Что такое инверсия управления
IOC
(Inversion Of Control
)? - Что такое внедрение зависимостей
DI
(Dependency Injection
)? -
IOC
а такжеDI
Какая разница? - Не проще ли иметь меньше строк кода?
- Логика кода сложна и нарушает
KISS
принцип? - Как написать удовлетворение
KISS
Кодекс принципов? - Как судить, удовлетворено ли оно
KISS
в общем? - Повторяющийся код должен нарушать
DRY
? - Как улучшить повторное использование кода?
- Что такое Закон Деметры?
- Какое сознание высокой сплоченности и свободного муфта?
- Как понять высокую сплоченность и слабую связанность?
- Как использовать Закон Деметры?
После прочтения этих вопросов, это волнение?Если вы взволнованы, это означает, что вы собираетесь прогрессировать и расти снова.
стиль письма
Начнем с нескольких слов, чтобы активировать атмосферу. Затем, задавая вопросы, отвечая на вопросы, а затем комбинируя примеры из жизни и код, всесторонне объясняется знание принципов проектирования.
Зачем изучать принципы дизайна
Это дает вам свободу после пожара
Людям нужны принципы. Когда вы пишете код, вы говорите о принципах?
По обычному сюжету в это время начнут выступать некоторые друзья:
Гао Цзань ответил:Плохое сознание, у меня нет принципов в жизни.
Хахахаха, тогда я могу только сказать, что ты свет, ты электричество, ты единственный миф.
Чем ниже по течению, тем больше свободы
Неважно, если вы так считаете, я приведу вам несколько примеров, и вы поймете.
Примеры следующие:
- Менеджер по продукту пишет документ по планированию продукта и показывает его разработке и тестированию, хотя бы немного по-человечески.
- Дизайн взаимодействия Пишите документы по дизайну взаимодействия для разработки продуктов, хотя бы немного по-человечески
-
ui
Дизайнеры производят эскизы дизайна для разработки продуктов, по крайней мере, они должны быть человекоподобными
Прочитав приведенный выше пример, скажем:
Когда гордый фронтенд-инженер закончит писать код, тогдаtwo days later
. Приятно удивился, обнаружив, что сам писать код не встречал, что очень смущает. Однако сердце едва скрывало удовольствие, ведь мы находимся в самом нижнем течении, кому нет чтения кода говорит, что вверх внизcode review
.
Это чувство очень опасно, когда мы очень движемся вниз по течению, это также означает, что мы очень свободны, и это имеет много негативных последствий.
Так как же ограничить эту свободу? Этот ответ - то, что эта статья хочет уточнить:
Эта свобода идти за борт ограничена принципами дизайна.
Каковы принципы проектирования?
Пожалуйста, посмотрите на картинку ниже:
Столбец «Принципы проектирования» на диаграмме охватывает все важные принципы проектирования, такие какSOLID
,KISS
,YANGI
,DRY
,LOD
.
Нечего сказать, давайте следовать за мной ниже и шаг за шагом осваивать принципы дизайна!
Цель правильного использования принципов дизайна
Выше упоминалось, почему нам нужно изучать принципы дизайна, а затем подумать об этом еще раз, какова цель правильного использования принципов дизайна?
Цель такова: Пусть код или проект имеют:
- удобочитаемость
- Масштабируемость
- возможность повторного использования
- ремонтопригодность
Если резюмировать одним предложением:Уменьшите сложность разработки программного обеспечения, позволяя сложности итерации оставаться в разумном интервале.
OK
, Поговорив о цели, мы начинаем вводить эти принципы дизайна один за другим. Пожалуйста, читайте дальше.
Примечание. Упомянутый ниже класс также относится к модулю, поэтому я не буду писать модуль отдельно.
SOLID
Это первое знакомство и самое важное.
Главное сказано трижды:
Помните: среди принципов дизайнаSOLID
это точка, иSO
является фокусом.
S
имя
- Рекомендуемая розничная цена: Single Responsibility Principle
- Китайский: принцип единой ответственности
QUESTION
Как понять принцип единой ответственности?
Класс отвечает только за выполнение одной обязанности или функции.Вместо того, чтобы разрабатывать большой и всеобъемлющий класс, вы должны разработать класс с небольшой степенью детализации и одной функцией.Короче говоря, он должен быть маленьким и красивым. Целью принципа единой ответственности является достижение высокой связности кода и низкой связанности, а также улучшение возможности повторного использования, удобочитаемости и ремонтопригодности кода.
Как судить, является ли ответственность достаточно разовой?
здесь есть5
Трюк:
- Слишком много приватных методов в классе
- Сложнее дать классу правильное имя
- Слишком много строк кода, функций или свойств в классе
- Большое количество методов в классе сосредоточено на работе с определенными свойствами в классе.
- Класс зависит от слишком многих других классов или слишком много других классов зависит от класса
Обязанности должны быть максимально простыми?
Принцип единой ответственности улучшает сплоченность классов, избегая разработки больших всеобъемлющих классов и объединения несвязанных функций. При этом ответственность класса едина, и другие классы, от которых он зависит и зависит, также будут снижены, за счет чего достигается высокая связность и слабая связанность кода.
Уведомление:Если разделение слишком тонкое, оно на самом деле будет контрпродуктивным, но снизит связность и повлияет на удобство сопровождения кода.
Примеры из жизни
Общественное разделение труда:Те, кто пишет код, не будут одновременно писать документы по планированию.
показать код
Пример 1: Соблюдение единой ответственности
useFuncA()
useFuncB()
Вышеуказанная функция может рассматриваться какhooks
, функция (hooks
) для завершения функции.
Пример 2: Различные уровни бизнеса могут отвечать или не отвечать одной ответственности
const userInfo = {
userId: '',
username: '',
email: '',
telephone: '',
createTime: '',
lastLoginTime: '',
avatarUrl: '',
provinceOfAddress: '',
cityOfAddress: '',
regionOfAddress: '',
detailedAddress: ''
}
- С пользовательского уровня бизнес удовлетворяет единственному принципу ответственности.
- На более детальном бизнес-уровне отображения информации о пользователе, информации об адресе и информации для аутентификации входа принцип единой ответственности не выполняется.
Пример 3: Соблюдение единой ответственности
Как видно из приведенного выше рисунка, функция завершается только одним каталогом модуля.
Пример 4: Единая ответственность не соответствует требованиям
function bindEvent(elem, type, selector, fn) {
if (fn == null) {
fn = selector
selector = null
}
}
bindEvent(elem, 'click', '#div', fn)
bindEvent(elem, 'click', fn)
мы обнаруживаем,bindEvent
Функции могут передавать множество параметров, что не соответствует принципу единой ответственности, это воплощение идеи режима внешнего вида.
PS:Режим внешнего вида показан на следующем рисунке:
Сводка SRP
На приведенные выше вопросы даны ответы и обобщены, и вот дополнительное предложение:
SRP
Смотреть надо в комплексе с бизнес-сценариями, и результаты разные с разных сторон.
O
- OCP: Open Closed Principle
- Китайский: принцип открытого-закрытого
QUESTION
Что такое принцип открытого-закрытого?
Программные сущности (классы, модули, функции) должны быть открыты для расширения, но закрыты для модификации.
То есть: добавление новой функции должно заключаться в расширении кода на основе существующего кода (добавление модулей, классов, методов и т. д.), а не в изменении существующего кода.
Обязательно ли изменение кода означает нарушение принципа открытого-закрытого?
Не обязательно, мы должны быть гибкими в этом:
- Во-первых: принцип открытого-закрытого означает не полное исключение модификации, а завершение разработки новых функций за счет минимальной модификации кода.
- Во-вторых: одно и то же изменение кода может рассматриваться как модификация при грубой детализации кода и может рассматриваться как расширение при мелкой детализации кода.
- Третье: постарайтесь, чтобы основная и наиболее сложная часть логического кода соответствовала принципу открытости-закрытости.
Какие изменения кода определяются как расширения или модификации?
Обычно, если это не нарушает нормальную работу исходного кода,без нарушения исходных модульных тестов, мы можем думать, что это соответствует принципу открытого-закрытого. Если он сломан, то можно считать, что он не соответствует принципу открыто-закрыто.
Как открыть для расширения и закрыть для модификации?
- Сохранять функции, классы и модули в их текущем состоянии или приближении к их нормальному состоянию (т. е. неизменяемость).
- Расширьте существующие классы, функции или модули, используя композицию (избегая наследования), чтобы они могли предоставлять новые функции или функции под другими именами.
Как гибко применять принцип открытого-закрытого в проекте?
Всегда имейте сознание расширения, абстракции и инкапсуляции.
Примеры из жизни
Бумага Гаокао:Например, завтра состоится вступительный экзамен в колледж, но учитель считает, что нет никакого способа отличить студентов с высокими баллами от студентов с низкими баллами, поэтому в контрольную работу необходимо добавить еще два сложных вопроса, но Вступительные экзамены в колледж будут завтра Явно неразумно. Поразмыслив над этим, лучший способ — добавить дополнительный вопрос в экзаменационный билет для поступления в колледж [вы можете добавить дополнительные вопросы, но вы не можете изменить исходный документ, который открыт для расширения и закрыт для изменения].
code
Пример 1: ПО промежуточного слоя
app.use(A).use(B).use(C)
Пример 2:function optional
fn(f1(),f2(),f3())
Пример 3: Штекер
Vue.use(PluginA)
Vue.use(PluginB)
Пример 4: Декоратор
@get('/hello')
async hello() {
// ...
}
Суммировать
Есть два момента:
- Принцип «открыто-закрыто» является наиболее важным принципом проектирования, и многие шаблоны проектирования основаны на принципе «открыто-закрыто».
- его ядро состоит в том, чтобыУлучшить масштабируемость кода
L
- ЛСП: Liskov Substitution Principle
- Английский: Принцип замещения Лискова
Эм, как тебе эта аббревиатура, а?
QUESTION
Что такое принцип замещения Лисков?
Когда создается подкласс, он должен соблюдать соглашение о поведении (или протокол) родительского класса. Родительский класс определяет соглашение о поведении функции, а подкласс может изменить внутреннюю логику реализации функции, но не может изменить исходное соглашение о поведении функции.
Поведенческие соглашения здесь включают: то, что функция объявляет для реализации, соглашения о вводе, выводе, исключениях и даже любые специальные инструкции, перечисленные в комментариях.
Как определить, выполняется ли принцип подстановки Лисков?
Используйте модульный тест родительского класса для проверки кода дочернего класса. Если некоторые модульные тесты не запускаются, это может указывать на то, что дизайн и реализация подкласса не полностью соответствуют контракту родительского класса, и подкласс может нарушать принцип подстановки Лискова.
Примеры из жизни
Пиратские диски:Оригинальный компакт-диск был подлинным, но теперь у вас есть пиратский компакт-диск.У нас есть два компакт-диска, и мы вставили их вDVD
Внутри вы можете запустить его в одиночку [пиратские диски поставить все оригинальные дискиcopy
Приходите, поведение подкласса и родительского класса должно быть одинаковым]
code
Пример 1: выполнение кода повторяется, не соответствует
LSP
в общем
class People {
constructor(name, age) {
this.name = name
this.age = age
}
eat() {
// ...
}
}
class Student extends People {
constructor(name, age) {
super(name, age)
}
eat() {
// ...
}
}
const kuangXiangLu = new Student('KuangXiangLu', 10)
kuangXiangLu.eat()
почему бы нетLSP
Шерстяная ткань? Есть две причины:
Первый:Student
класс наследуетPeople
класс, при измененииPeople
Категорияeat
метод, который нарушаетLSP
в общем
Второе: не следил за дизайном родительского класса, изменил вывод
Суммировать
Суть принципа подстановки Лискова — это принцип, используемый для определения того, как следует проектировать подклассы в отношениях наследования, то естьdesign by contract
(оформление согласно протоколу).
I
- Интернет-провайдер: Interface Segregation Principle
- Китайский: принцип разделения интерфейса
QUESTION
Что такое принцип разделения интерфейсов?
Вызывающий или пользователь интерфейса не должен быть вынужден полагаться на интерфейс, который ему не нужен.
Что такое интерфейс в принципе разделения интерфейсов?
Под интерфейсом можно понимать следующие три вещи: наборAPI
коллекция интерфейсов, одиночнаяAPI
интерфейс или функция,OOP
Концепции интерфейса в
Примеры из жизни
Автомобильный USB-разъем:В машине много розеток, а втыкать хочетсяusb
интерфейс, вы хотите, чтобы он имелusb
функцию, а хотеть, чтобы она имела функцию трехпроводной вилки, это ненаучная вещь [каждый интерфейс должен иметь свою роль, только отвечающую за свою роль].
code
Код 1:
const obj = {
login() {
// 用户登录
},
delete() {
// 删除用户信息
}
}
delete
Не является распространенной и опасной операцией, и еслиlogin
Собраны, нет необходимости настраиватьdelete
возможность неправильной настройки бизнеса, вопрекиISP
в общем.
Код 2:
function main() {
// 处理加法
// 处理减法
// 处理乘法
// 处理...
}
В функции обрабатывается много логики, что также нарушаетISP
в общем.
Суммировать
Братья, берегите себя и сосредоточьтесь на изоляции.
D
- ОКУНАТЬ: Dependency Inversion Principle
- Китайский: принцип инверсии зависимостей (инверсии)
QUESTION
Что такое принцип инверсии зависимостей (инверсии)?
модули высокого уровня (high-level modules
) не зависят от низкоуровневых модулей (low-level
). Модули высокого уровня и модули низкого уровня должны быть абстрагированы через (abstractions
) Зависит друг от друга. Кроме того, абстрактный (abstractions
) не полагайтесь на конкретные детали реализации (details
), конкретные детали реализации (details
) зависит от абстракции (abstractions
).
Каково сознание модулей высокого уровня и модулей низкого уровня?
В цепочке вызовов вызывающий абонент принадлежит к верхнему уровню, а вызываемый абонент — к нижнему уровню.
Как понять перевернутые два слова?
Инверсия относится к тому факту, что программист сам контролирует выполнение всей программы до того, как будет использован фреймворк. После использования фреймворка поток выполнения всей программы может контролироваться фреймворком.
Управление процессом передается от программиста к фреймворку.
Какие зависимости были изменены?
Модули высокого уровня меняются местами.
Что такое инверсия управленияIOC (Inversion Of Control)
?
Инверсия управления, управление относится к управлению потоком выполнения программы.До отсутствия инверсии управление находится в руках программиста.После инверсии управление находится в руках фреймворка.
Инверсия управления — это не конкретный метод реализации (кодирования), а более общая идея дизайна, которая обычно используется для управления дизайном на уровне фреймворка.
Что такое внедрение зависимостейDI (Dependency Injection)
?
Потерпеть неудачуnew()
Вместо этого после того, как объект зависимого класса создан извне, он передается (или внедряется) в класс через конструкторы, параметры функции и т. д.
Внедрение зависимостей — это конкретная (реализация) техника кодирования.
IOC
а такжеDI
Какая разница?
IOC
это дизайн-мышление,DI
являются конкретными (реализация) методами кодирования.
Примеры из жизни
- Три монаха черпают воду:Обычной операцией является прямое использование ведра для забора воды из колодца, но теперь нам нужно добавить ссылку, сначала используйте ведро, чтобы перекачать воду из колодца в большое ведро, а затем набрать воду из большого ведра [ никаких промежуточных операций не требуется, просто используйте нижний слой напрямую].
-
CPU
ОЗУ:Жесткий диск предназначен для интерфейса, если он предназначен для реализации, то память должна соответствовать конкретной марке материнской платы, что явно неразумно.
code
Код и интерпретация показаны на следующем рисунке:
Суммировать
DIP
является абстрактным и непостижимым принципом проектирования, начиная сIOC
а такжеDI
Китайское имя видно. все используютDIP
, понимать доскональнообратныйслово. Не забудьте передать процесс элементу управления фреймворком перед его реализацией.
Твердое резюме
Следующая таблица вернаSOLID
При сравнении различных измерений вы можете взглянуть, а затем скомбинировать содержимое, описанное выше, чтобы тщательно его попробовать.
в общем | Связь | Сплоченность | Расширяемость | избыточность | ремонтопригодность | Тестируемость | приспособляемость | последовательность |
---|---|---|---|---|---|---|---|---|
SRP | - | + | o | o | + | + | o | o |
OCP | o | o | + | - | + | o | + | o |
LSP | - | o | o | o | + | o | o | + |
ISP | - | + | o | - | o | o | + | o |
DIP | - | o | o | - | o | + | + | o |
+
представляет увеличение,-
представляет собой уменьшение,o
Представляет собой квартиру.
KISS
- Английский:Keep It Simple and Stupid
- Китайцы: Держите простую глупость
- Миф: делайте свой код простым
QUESTION
Не проще ли иметь меньше строк кода?
Не обязательно, например, некоторые более длинные регулярные выражения, трехзначные операторы, которые противоречатKISS
в общем.
Логика кода сложна и нарушаетKISS
принцип?
Не обязательно, если это сложная проблема, решать ее комплексно, не нарушаяKISS
в общем.
Как написать удовлетворениеKISS
Кодекс принципов?
- Не внедряйте код с использованием технологий, которые могут быть непонятны вашим коллегам.
- Не изобретайте велосипед, хорошо используйте существующие библиотеки инструментов
- Не переоптимизируйте
Как судить, удовлетворено ли оноKISS
в общем?
KISS
является субъективным суждением, которое может быть определеноcode review
Сделайте это, если у большинства ваших коллег много вопросов по вашему коду, в принципе недостаточноKISS
.
code
Как показано в следующем коде: не соответствуетKISS
в общем
let a = b ? c : d ? e : f
Суммировать
- Следите за тем, как
- Когда мы занимаемся разработкой, мы не должны перепроектировать и не думать, что простые вещи не имеют технического содержания. На самом деле, чем больше простых методов можно использовать для решения сложных проблем, тем больше это может отражать способности человека.
YANGI
- Английский:Вам это не понадобится
- Китайский: он вам не понадобится
- Миф: не переусердствуйте
Примеры из жизни
Двойной 11 手:Святое дерьмо, это так дешево, делай заказ, делай заказ, делай заказ, а потом... представьте себе.
Суммировать
- Никогда не пишите фрагмент кода только потому, что вы ожидаете, что он будет использован.
- Скорее: внедряйте его только тогда, когда вам это действительно нужно.
DRY
- Английский:
Don’t Repeat Yourself
- Русский:не повторяться
- Миф: не пишите повторяющийся код
QUESTION
Повторяющийся код должен нарушатьDRY
?
Повторяющийся код не обязательно нарушаетDRY
В принципе, есть три типичных случая дублирования кода, а именно:
- Реализовать логическое повторение
- функционально-смысловой повтор
- Выполнение кода повторяется
Как улучшить повторное использование кода?
Сокращение связанности кода, соблюдение принципа единой ответственности, модульность, разделение бизнес-логики и небизнес-логики, абстрагирование общего кода, абстрагирование и инкапсуляция, а также использование шаблонов проектирования.
code
Пример 1: Реализация логического повторения
Код 1:
function isValidUserName() {
// 内容一样
}
function isValidPassword() {
// 内容一样
}
function main() {
isValidUserName()
isValidPassword()
}
Код 2:
function isValidUserNameOrPassword() {
// 内容一样
}
function main() {
isValidUserNameOrPassword()
}
смотри, код1
Код двух функций в один и тот же, поэтому мы превращаем его в функцию, удаляя повторение и становимся кодом2
. Вопрос ко всем, считаете ли вы, что это нарушаетDRY
Шерстяная ткань?
- результат: код
1
не нарушаетDRY
, код2
противDRY
первоначальное намерение. - Причина: Хотя логика повторяется, семантика не повторяется. Функционально они делают две совершенно разные вещи. После слияния функция делает две вещи, нарушая
SRP
а такжеISP
. - Улучшение: абстрагирование более мелких функций.
Пример 2: Функциональное семантическое дублирование
function sayHello() {
//
}
function speakHello() {
//
}
все выраженияhello
сознании, хотя код не повторяется, но повторяется семантика, что нарушаетDRY
.
Пример 3: Повторение выполнения кода
function isLogin() {
//
}
function main() {
if (xxx) {
isLogin()
}
// 代码省略...
if (yyy) {
isLogin()
}
}
В функции многократное выполнение одной и той же функции нарушаетDRY
.
Суммировать
Неповторение не означает возможность повторного использования, но требуется диалектическое мышление и гибкое применение.
LOD
Английский:Law of Demeter
Английский: Закон Деметры
Общая интерпретация: высокая сплоченность, слабая связанность.
QUESTION
Что такое Закон Деметры?
Не должно быть зависимостей между классами, у которых не должно быть прямых зависимостей. Между классами с зависимостями старайтесь полагаться только на необходимые интерфейсы
Что такое сознание высокой сплоченности и слабой связанности?
- Высокая связность означает, что похожие функции должны быть помещены в один и тот же класс, а разные функции не должны помещаться в один и тот же класс. Поскольку подобные функции часто изменяются одновременно и помещаются в один и тот же класс, модификации будут более концентрированными.
- Слабая связанность означает: в коде зависимости между классами просты и понятны. Даже если два класса имеют зависимости, изменения кода в одном классе не приведут или редко приведут к изменениям кода в зависимом классе.
Как понять высокую сплоченность и слабую связанность?
Объедините следующий рисунок, чтобы понять:
Это общая идея дизайна, которую можно использовать для руководства проектированием и разработкой различных кодов детализации, таких как системы, модули, классы и даже функции, а также применять к различным сценариям разработки, таким как микросервисы, фреймворки, компоненты. и классы, библиотека и т. д.
Как использовать Закон Деметры?
Уменьшите связанность кода, соблюдайте принцип единой ответственности и используйте модули.
Примеры из жизни
Объекты в реальности: Вы должны много знать о своем объекте, но если вы много знаете об объектах других людей, это большая проблема [объект должен знать как можно меньше о других объектах].
code
Как показано выше: мы используемlerna
Чтобы разработать фреймворк, поместите разные функции фреймворка в разныеpackage
Поддержание итераций в соответствии сLOD
.
Суммировать
Высокая связность и слабая связанность — очень важные дизайнерские идеи, которые могут эффективно улучшить читабельность и удобство сопровождения кода, а также уменьшить объем изменений кода, вызванных функциональными изменениями.
Краткое изложение принципов проектирования
Что ж, увидев это, принципы дизайна в основном закончены. Я объяснил основные принципы дизайна. Вы обнаружите, что, хотя некоторые принципы дизайна имеют разные названия, их цели схожи и одинаковы. Изучение и освоение основных принципов проектирования может помочь нам лучше проектировать, разрабатывать и улучшать программное обеспечение. Это также закладывает прочную основу для изучения и освоения шаблонов проектирования.
общаться с
В изложении принципов проектирования в этой статье должна быть какая-то неуместность, если есть какие-то ошибки, можете указать и пообщаться друг с другом в комментариях. Вы также можете добавить меня в WeChat для технического обмена.
Вы также можете зайтиГруппа звукозаписи Front-end RhapsodyПроведите мозговой штурм вместе.