Принципы разработки. DRY KISS YAGNI SOLID

Question 1

Don’t Repeat Yourself – DRY

Answer 1

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

Question 2

Keep it simple, stupid – «Придерживайся простоты»

Answer 2

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

Question 3

You Aren’t Gonna Need It – «Тебе это не понадобится»

Answer 3

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

Question 4

Избегай преждевременной оптимизации

Answer 4

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

Question 5

SOLID

Answer 5

SOLID - это принципы проектирования классов в объектно-ориентированном программировании.

1. Single responsibility (Принцип единственной ответственности). Каждый модуль или класс должен отвечать за единственную часть функционала. Эта часть должна быть полностью инкапсулирована в этом классе.
   SRP предлагает разделять универсальные классы на конкретные, что сделает их простыми и лёгкими в обслуживании.
2. Open-closed (Принцип открытости-закрытости). Сущности программы (классы, модули, функции и т. д.) должны быть открыты для расширения, но закрыты для изменения.
   Открыты для расширения: означает, что поведение сущности может быть расширено путём создания новых типов сущностей.
   Закрыты для изменения: в результате расширения поведения сущности, не должны вноситься изменения в код, который эту сущность использует.
3. Liskov substitution (Принцип подстановки Барбары Лисков). Наследующий класс должен дополнять, а не заменять поведение базового класса.
   Более простыми словами можно сказать, что поведение наследующих классов не должно противоречить поведению, заданному базовым классом.
   В том месте где в программе используется базовый класс, должен подходить любой из его child-ов классов.

4.Interface segregation (Принцип разделения интерфейса). Клиентский интерфейс не должен зависеть от методов, которые он не использует.
Принцип разделения интерфейсов говорит о том, что слишком «толстые» интерфейсы необходимо разделять на более маленькие и специфические.
Интерфейс является принадлежностью клиента, а не сервера.

5. Dependency inversion (Принцип инверсии зависимостей). Программист должен работать на уровне интерфейса, а не на уровне реализации.
   A. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
   B. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.