97 этюдов для программистов. Опыт ведущих экспертов

Пишите код на языке предметной области Дэн Норт

Представьте себе текст двух программ. В одной вы встречаете такое:

if (portfolioIdsByTraderId.get(trader.getId())

  containsKey(portfolio.getId())) {…}

Вы чешете затылок, пытаясь осмыслить, что делает этот код. Похоже, он получает идентификатор объекта трейдера, и по этому идентификатору находится ассоциативный массив в, э-э-э… очевидно, ассоциативном массиве ассоциативных массивов; затем проверяется, есть ли в этом внутреннем массиве еще один идентификатор — из объекта портфеля. Вы снова чешете затылок. Ищете объявление переменной portfolioIdsByTraderId и обнаруживаете следующее:

Map> portfolioIdsByTraderId;

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

В тексте другой программы вы видите:

if (trader.canView(portfolio)) {…}

Никаких головоломок. Вам не нужно знать, как объект трейдера определяет доступность портфеля. Где-то в недрах программы, наверное, все же зарыт ассоциативный массив ассоциативных массивов. Но это заботы объекта trader, а не ваши.

Внимание, вопрос. Над кодом какой из программ вы предпочли бы работать?

Давным-давно у нас были только самые элементарные структуры данных: биты, байты и символы (на самом деле, те же байты, но мы делали вид, что это буквы и специальные символы). С десятичными числами выходило посложнее, ведь счисление по основанию 10 плохо вписывается в двоичную систему, так что у нас было несколько размеров для чисел с плавающей запятой. Затем появились массивы и строки (по сути, разновидность массивов). Потом в нашем распоряжении оказались стеки и очереди, хеши, связные списки, списки с пропусками и масса других замечательных структур данных, которых нет в реальном мире. Термин «компьютерная наука» тогда означал в основном трудоемкое отображение реального мира на наши ограниченные структуры данных. Настоящие гуру могут даже вспомнить, как именно удавалось решать задачу.

Затем появились пользовательские типы! Ладно, это ни для кого не новость, но они несколько меняют правила игры. Если в вашей предметной области есть такие понятия, как «трейдер» и «портфель», вы можете моделировать их с помощью типов, назначив типам такие имена, как Trader и Portfolio. Но, что еще важнее, и отношения между типами можно моделировать через термины из той же предметной области.

Если вы не используете в коде термины предметной области, значит вы формируете подразумеваемое (читай: секретное) правило, что вот эта переменная типа int в этом месте обозначает трейдера, а вон то int в том месте обозначает портфель. (И лучше их не путать!) А если вы реализуете некоторое бизнес-правило («некоторым трейдерам нельзя просматривать некоторые портфели — это незаконно») с помощью нетривиального алгоритма в коде, — например поиска существования значения в ассоциативном массиве, — вы вряд ли облегчаете жизнь ребятам, которые будут проводить аудит и проверку на соответствие законодательству.

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

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

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