Прямо и просто

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

Сегодня мы обсудим, почему это важное различие.

Что такое Принципы?

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

Что такое паттерны?

Шаблоны — это просто то, что повторяется предсказуемым образом.
Наш мозг отлично справляется с выявлением закономерностей. Мало того, они хорошо предсказывают, что означают эти шаблоны, используя индуктивное мышление.
Примеры Паттернов также можно найти в любой сфере жизни:

Почему вы должны полагаться на Принципы

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

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

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

Принципы разработки программного обеспечения

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

Возьмите инверсию зависимостей в качестве примера. Это часть 5 основных принципов SOLID. В двух словах — это означает, что мы должны полагаться на абстракции, а не на конкретные реализации. Этот принцип помогает нам разрабатывать надежное и удобное в сопровождении программное обеспечение. Нет контекста, который заставит нас предпочесть конкретные реализации абстракциям, поскольку стоимость использования абстракций незначительна, тогда как стоимость изменения конкретной реализации потенциально неограничена.

Шаблоны в программной инженерии

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

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

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

Шаблоны проектирования — хорошее, плохое и возможное

Существует множество примеров шаблонов проектирования, но, как правило, хороший шаблон проектирования основывается на принципах проектирования.
Например, внедрение зависимостей — это отличный шаблон проектирования, который позволяет нам отделить создание от использования. Он уменьшает связанность, улучшает тестирование и основан на принципах проектирования — это реализация принципа инверсии зависимостей.

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

Однако некоторые люди считают это антипаттерном. Распространенным утверждением является то, что шаблон нарушает принцип единой ответственности (S в SOLID), поскольку он контролирует свой жизненный цикл и применяет к себе поведение единственного экземпляра. На мой взгляд, это не совсем точно, поскольку управление экземплярами ортогонально функциональности, а SRP относится к функциональности. Более правильное утверждение состоит в том, что синглтоны нарушают принцип инверсии зависимостей, поскольку вы зависите от конкретной реализации — доступ к синглтону через его конкретные статические методы вместо того, чтобы полагаться на абстракции. Это приводит к жесткой связи, что делает наш код менее удобным для сопровождения и более подверженным ошибкам, если происходят изменения.
Это не означает, что шаблон Singleton по своей сути плох, но если он выглядит так, как будто шаблон нарушает принципы, вы следует проявлять осторожность перед его реализацией.

Что мы сегодня узнали

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

В следующий раз, когда вы обнаружите, что изучаете новый шаблон проектирования или даже хотите реализовать существующий, спросите себя: основан ли этот шаблон на твердых (каламбур) принципах проектирования? Или это может потенциально вызвать непредвиденные проблемы в будущем?

Я надеюсь, что вы нашли эту статью полезной, и до следующего раза, чтобы она была прямолинейной и простой!