Pull to refresh

Применяем принцип KISS к самим принципам проектирования

Reading time 3 min
Views 15K

(Update: заменил картинку на более нейтральную)


Коллега упомянул в беседе принцип "Convention over configuration", и я подумал, блин, наверно это что-то крутое, нужно изучить, почитать статьи, а то отстану от жизни.


Каково было моё удивление, что вcё обьяснение помещается в одной фразе "Используй дефолты, которые можно при желании переопределять".


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


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


Значение Перевод
KISS
«Keep it short and simple»,
«Keep it simple, stupid!» и т.д.
Не усложняй код без веской причины
Инкапсуляция Нам не надо знать, что там у объекта внутри, просто используем публичные методы. Так мы упрощаем для понимания сложные системы и уменьшаем связанность объектов друг с другом
Convention over configuration Вместо конфига, описывающего всё, лучше использовать дефолты, которые при желании можно переопределять в конфиге.
Принцип подстановки Барбары Лисков
Оригинальная формулировка: "… Пусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T...")
Поведение класса-наследника не должно противоречить поведению, заданному классом-родителем.
Чтобы можно было без проблем подставить объект класса Dog туда, где ожидается объект класса Animal
Принцип единственной ответственности Класс должен делать что-то одно
Принцип разделения интерфейса
"...Клиенты не должны зависеть от методов, которые они не используют..."
В аргументах конструктора или метода не надо ожидать объект со множеством лишних деталей, если классу для работы нужен лишь маленький специфический объектик или вообще тупо один integer.
И точно не надо пихать во все классы контейнер зависимостей.
High Cohesion Класс должен делать что-то одно :). Если вы видите, что некоторые методы используются обособленно, отдельно от других, с какими-то своими данными, значит у вас не high cohesion. Возможно стоит разделить класс на части или перенести часть методов куда-то еще
Low coupling Классы должны быть как можно меньше завязаны на другие классы, особенно на их содержимое. Не управляйте лапами собаки, управляйте собакой
Принцип инверсии зависимостей
"… Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций..."
Классы должны быть как можно меньше завязаны на другие классы :)
Для гибкости кода в аргументах конструктора/метода нужно делать интерфейсы или абстрактные классы, а не конкретные классы.
Принцип открытости/закрытости
"… Программные сущности (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения..."
Новая функциональность должна добавляться путём добавления нового класса, а не добавлением новой ветки if в существующий класс, который делает всё на свете.
YAGNI
«You aren't gonna need it»,  «Вам это не понадобится»
Не надо делать того, что не просили. Подход «возможно в будущем понадобится» сильно усложняет код и поддержку

Если есть желание дополнить, исправить или поспорить — как обычно, пишите в комментариях

Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
+12
Comments 22
Comments Comments 22

Articles