Почему объектно-ориентированное программирование по-прежнему остается лучшим из того, что у нас есть, и как оно может помочь нам создавать хорошо спроектированные микросервисы?
На дворе 2022 год, ИТ уже съели почти весь мир, а мы разработали инструменты, которые делают парадигмы из 60-х, такие как ООП, серьезно устаревшими, верно? Ну не совсем.
По крайней мере, в общем, объектно-ориентированный дизайн предлагает наиболее выгодный подход к разработке программного обеспечения от кода до системной архитектуры. Однако только при правильном выполнении.
Просто используя ключевые слова object или class мы не создаем объектно-ориентированный код. Можно легко написать полностью необъектно-ориентированный код даже на таких в значительной степени объектно-ориентированных языках программирования, как Java или C#, но только применяя принципы ООП, мы можем сделать наши программы действительно объектно-ориентированными.
Хотя эти принципы были хорошо известны на протяжении десятилетий, они плохо понимаются большинством разработчиков даже в 2022 году. Я все больше и больше наблюдаю постоянный переход к структурному программированию, методу, намного более древнему, чем само ООП.
Результатом являются неоптимально спроектированные системы, которые трудно поддерживать, расширять и анализировать. Склонные к ошибкам, хрупкие, распределённые монолиты — лишь один пример, знакомый многим из нас.
Знания, полученные в школе, являются хорошей основой, но их недостаточно. Мы должны сосредоточиться на понимании, а не просто знании, мы должны изучать принципы, а не практику.
Принципы объектно-ориентированного проектирования и программирования
Хорошо, тогда каковы самые фундаментальные принципы?
Объект определяется своим контрактом.
Контракт объекта определяет что объект может делать, а не как он это делает. Взгляд на объект со стороны не должен давать никакого представления о его реализации. Контракт не должен быть нарушен; задача объекта — защищать свои инварианты. Деловая цель – прочная основа для стабильного контракта.
Объекты автономны.
Вы никогда не должны просить объект предоставить информацию, необходимую для конкретного действия. Вместо этого попросите объект выполнить действие за вас. Ни один объект не может делать что-либо с другим объектом. Объекты являются активными сущностями, а не пассивными марионетками.
Все данные являются частными.
Объекты должны скрывать все данные и другие детали, необходимые им для решения конкретной бизнес-задачи. Если данные не являются частными, они становятся частью контракта. В этом разница между объектами и структурами данных: объекты сплошные, структуры данных прозрачные. Более формально мы говорим о понятиях инкапсуляция и сокрытие информации.
Эти принципы могут показаться простыми, но простота часто не является легкой целью. Программисты предпочитают «умные» решения, а не простые; они, например, осваивают методы ООП, такие как инкапсуляция с использованием частных атрибутов, но нарушают принцип сокрытия информации, раскрывая ее через геттеры и сеттеры.
Список, конечно, не окончательный, мы можем добавить много других, таких как компонуемость, все принципы SOLID и т. д.
Однако три упомянутые концепции имеют первостепенное значение, превосходят все остальные и в то же время их труднее всего реализовать. Поэтому их часто полностью игнорируют.
Самое главное, они универсально полезны на всех уровнях разработки программного обеспечения.
Объектно-ориентированные микросервисы
В настоящее время ни один технический пост не будет полным без упоминания микросервисов, чрезвычайно популярного шаблона архитектурного проектирования для построения распределенных систем.
Как объектно-ориентированный дизайн применяется в архитектуре микросервисов? Прежде всего, давайте вспомним определение (микро)сервиса:
Служба — это технический орган для конкретной бизнес-возможности.
Теперь, что такое бизнес-возможности? Это выражение того, что бизнес делает и может сделать. Бизнес-возможности являются ключом к определению высокосвязных границ обслуживания.
Это особая функциональность, реализующая бизнес-возможности. Функциональность определяет поведение системы.
Служба автономна; его способность функционировать не контролируется и не блокируется другими службами.
Сервисы независимы, автономны, свободны от внешнего контроля и ограничений. Службы могут принять решение самостоятельно. Чем более автономны наши сервисы, тем более слабо они связаны.
Любая часть данных или правило должны принадлежать только одной службе.
Другими словами, служба должна инкапсулировать все данные и детали реализации, с которыми она работает. Мы говорим об архитектуре без общего доступа, в которой каждый запрос удовлетворяется одним узлом.
Подводя итог в нескольких пунктах, сервис:
- определяется его возможностями,
- владеет своими данными и правилами,
- находится под полным контролем.
Это звучит знакомо? Конечно, это так! Концептуально служба — это просто объект на системном уровне. Технические детали различаются, но здесь применяются одни и те же идеи.
Понимание принципов объектно-ориентированного проектирования поможет вам создавать микросервисы так, чтобы их было легко поддерживать, они были высоко связанными и слабо связанными.
Вывод
На дворе 2022 год, а у нас до сих пор нет ясного понимания того, как разрабатывать наше программное обеспечение. ИТ-индустрия быстро растет, и требования меняются слишком быстро, чтобы мы успевали за ними.
Пять десятилетий назад были определены великие принципы объектно-ориентированного проектирования и программирования, которые и сегодня могут многому научить нас. Мы просто должны изучить и принять их правильно.
Объектно-ориентированный дизайн — это целостный подход. Его можно успешно применять ко всему спектру проблем разработки программного обеспечения.
В общем, принципы объектно-ориентированного проектирования и программирования — лучшее, что у нас есть. И это не собирается меняться в ближайшее время.
