Открытость для расширений, закрытая для изменений: давайте углубимся в принцип "открыт-закрыт", один из 5 твердых принципов.

Принципы SOLID - это «первые пять принципов» объектно-ориентированной разработки программного обеспечения, описанные Робертом К. Мартином. Это слово является аббревиатурой, придуманной Майклом Си Фезерсом, которая служит напоминанием об этих принципах.

Здесь, в частности, я хочу написать о втором принципе, Открыто / Закрыто.

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

Конкретный пример

Например, представим себе класс Report, у которого есть два метода: DisplayReport и PrintReport; этот класс не закрывается, потому что при каждом новом просмотре отчета класс придется изменять.

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

Самый сложный из твердых принципов

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

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

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

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

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

Однако мы хотим подчеркнуть идею Plugin-Ability, концепцию, которая утверждает, что наш код должен иметь готовые точки привязки в своем дизайне. Что это могло значить?

Как и в примере с отчетом, это означает, что нам необходимо четко понимать концепцию ответственности, особенно ЕДИННУЮ ответственность, первый из ТВЕРДЫХ принципов. Если мы решим, что назначенная ответственность - это представление отчета, мы должны знать, что, когда представлений станет больше одного, это будет слишком много: оно не масштабируется. Если вместо этого мы углубимся в детали и определим как ответственность за определенный тип представления для этого отчета, станет ясно, что ответственность теперь может оставаться ограниченной даже масштабированием количества просмотров.

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

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

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