Понемногу вы начинаете понимать, что это как-то связано с наличием у трейдера доступа к определенному портфелю. Конечно, вы найдете такой же фрагмент поиска — а скорее похожий, но немного отличающийся код, — когда в другом месте понадобится узнать, есть ли у трейдера доступ к некоторому портфелю.
В тексте другой программы вы видите:
if (trader.canView(portfolio)) {…}
Никаких головоломок. Вам не нужно знать, как объект трейдера определяет доступность портфеля. Где-то в недрах программы, наверное, все же зарыт ассоциативный массив ассоциативных массивов. Но это заботы объекта trader, а не ваши.
Внимание, вопрос. Над кодом какой из программ вы предпочли бы работать?
Давным-давно у нас были только самые элементарные структуры данных: биты, байты и символы (на самом деле, те же байты, но мы делали вид, что это буквы и специальные символы). С десятичными числами выходило посложнее, ведь счисление по основанию 10 плохо вписывается в двоичную систему, так что у нас было несколько размеров для чисел с плавающей запятой. Затем появились массивы и строки (по сути, разновидность массивов). Потом в нашем распоряжении оказались стеки и очереди, хеши, связные списки, списки с пропусками и масса других замечательных структур данных, которых нет в реальном мире. Термин «компьютерная наука» тогда означал в основном трудоемкое отображение реального мира на наши ограниченные структуры данных. Настоящие гуру могут даже вспомнить, как именно удавалось решать задачу.
Затем появились пользовательские типы! Ладно, это ни для кого не новость, но они несколько меняют правила игры. Если в вашей предметной области есть такие понятия, как «трейдер» и «портфель», вы можете моделировать их с помощью типов, назначив типам такие имена, как Trader и Portfolio. Но, что еще важнее, и отношения между типами можно моделировать через термины из той же предметной области.
Если вы не используете в коде термины предметной области, значит вы формируете подразумеваемое (читай: секретное) правило, что вот эта переменная типа int в этом месте обозначает трейдера, а вон то int в том месте обозначает портфель. (И лучше их не путать!) А если вы реализуете некоторое бизнес-правило («некоторым трейдерам нельзя просматривать некоторые портфели — это незаконно») с помощью нетривиального алгоритма в коде, — например поиска существования значения в ассоциативном массиве, — вы вряд ли облегчаете жизнь ребятам, которые будут проводить аудит и проверку на соответствие законодательству.
Следующему программисту, который будет работать с этим кодом, ваше тайное знание может быть недоступно, так почему не описать все явно? Применение одного ключа для поиска другого, используемого в проверке существования, не слишком очевидная штука. Можно ли рассчитывать, что кто-нибудь догадается, что таким образом реализуются бизнес-правила, препятствующие конфликту интересов?
Явное применение понятий предметной области в коде дает возможность другим программистам понять его назначение со значительно меньшими усилиями, чем при попытках сопоставить алгоритм с тем, что им известно о предметной области. Кроме того, при совершенствовании модели предметной области, которое происходит по мере расширения ваших знаний о ней, вам будет легче дорабатывать код. Если правильно организовать инкапсуляцию, велики шансы, что правило будет располагаться в одном-единственном месте, и вы сможете менять его так, что никакой вызывающий код этого не заметит.
Программист, который спустя несколько месяцев продолжит работу над вашим кодом, будет вам благодарен. И этим программистом можете оказаться вы сами.
Код — это проектирование
Райан Браш
Представьте себе, вы утром просыпаетесь и узнаете, что в строительной промышленности произошел эпохальный прорыв. Теперь миллионы дешевых и невероятно быстрых роботов умеют создавать различные материалы буквально из воздуха, почти не расходуя энергии, и сами себя чинят. Но это еще не все: если есть четкие чертежи, роботы построят по ним здание без всякого вмешательства человека, и стоимость этой работы будет пренебрежимо мала.
Можно представить себе, как это преобразит строительную промышленность, но какие изменения произойдут на более высоком уровне? Как поведут себя архитекторы и проектировщики, когда стоимость строительства станет пренебрежимо мала? Сегодня дорогостоящему строительству обязательно предшествует создание и тщательное тестирование физических и компьютерных моделей. Станем ли мы так утруждать себя, если строительство будет фактически бесплатным? Что за проблема, если здание развалится? Найдем, в чем ошибка, и наши чудо-роботы построят нам новое.