Конспект POODR. Object-Oriented Design
Некоторые ребята уверены, что ООП — это про инкапсуляцию, наследование и полиморфизм, а сами объекты — просто такая обертка над данными. Это не так, ООП — это про сообщения, которые объекты отправляют друг другу. А лучше всего об этом рассказано в POODR, Practical Object-Oriented Design in Ruby Сэнди Метц.
Это настолько полезная книга, что я перечитываю ее каждый год. Чтобы перестать уже ее перечитывать, хочу закрепить знания с помощью конспекта. В этом посте — конспект первой главы, Object-Oriented Design.
Осторожно: это мой субъективный конспект. Не забудьте прочитать оригинал, книга того стоит.
Объектно-ориентированный дизайн
Объектно-ориентированный дизайн (ООД) рассматривает мир как серию сообщений, передаваемых между объектами.
Представим приложение. Если это приложение никогда не будет меняться, ему не нужен дизайн. Можно написать приложение как угодно, запустить и забыть про него.
К сожалению, что-то всегда меняется. Клиенты не знали, чего хотят на самом деле. Вы не поняли задачу. Вы узнали, как сделать приложение еще лучше. Клиенты хотят больше фич.
Изменений не избежать. Задача дизайна — снизить цену изменений.
Changing requirements are the programming equivalent of friction and gravity. They introduce forces that apply sudden and unexpected pressures that work against the best-laid plans. It is the need for change that makes design matter.
Agile processes guarantee change and your ability to make these changes depends on your application’s design. If you cannot write well-designed code you’ll have to rewrite your application during every iteration.
Приложения, которые легко менять, легко писать и дорабатывать. Приложения, которые сопротивляются изменениям, дорого развивать и поддерживать.
Почему тяжело вносить изменения
Объектно-ориентированные приложения состоят из объектов. Объекты взаимодействуют друг с другом, отправляя сообщения. Чтобы отправитель мог послать правильное сообщение, он должен что-то знать о получателе. Это знание создает зависимость между этими объектами, которая мешает изменениям.
ООД — это про управление зависимостями. Это набор техник программирования, которые помогают организовывать зависимости так, чтобы объекты было легко менять.
Без дизайна неуправляемые зависимости создают ад, потому что объекты знают слишком много друг о друге. Изменения в одном объекте приводят к изменениям в тех объектах, что работают с ним, и так до бесконечности. Простейшее изменение может разхерачить приложение целиком, заставляя программиста исправлять каждый модуль.
Кроме того, когда у объекта слишком много внешних зависимостей, его нереально использовать повторно и тяжело тестировать. (Вы хотели всего лишь банан, но в результате получаете гориллу, держащую этот банан, и все джунгли впридачу)
Практическое определение
Приложение состоит из кода. Организация (расстановка, разбиение) кода и есть дизайн. Два программиста с одинаковым взглядом на программирование, решая одну и ту же задачу, организуют код по-разному.
Design is not an assembly line where similarly trained workers construct identical widgets; it’s a studio where like-minded artists sculpt custom applications. Design is thus an art, the art of arranging code.
У дизайна есть свои инструменты: принципы и паттерны. Принципы (SOLID) — просто мнения, решения опытных чуваков, которые помогают писать код лучше.
Паттерны (GoF) — просто набор решений типовых задач дизайна. Популярность паттернов пошла им во вред: ребята решают ими неподходящие проблемы и получают запутанный код.
Технический долг
Иногда важность реализации фичи прямо сейчас перевешивает любые будущие проблемы с дизайном. Если фича настолько важна для бизнеса, что без нее можно завтра же закрываться, то лучше сделать ее, несмотря на то, что потом будет тяжело вносить изменения. Такой компромис — берем время в долг из будущего — называют техническим долгом.
P. S. Ещё больше постов о программировании, тестах и культуре разработки у меня в Телеграме.