Сергей Тарасов - Дефрагментация мозга. Софтостроение изнутри
ВОЗЬМИТЕ ЗА ЭМПИРИЧЕСКОЕ ПРАВИЛО
Глубина более двух уровней при моделировании объектов предметной области, вероятнее всего, свидетельствует об ошибках проектирования.
Для построения устойчивой глобальной иерархии необходим серьёзный анализ предметной области, ведь не случайно создание таксономии – сложная научно-исследовательская работа, которой в крупных компаниях занимаются аналитики. Но и такой работы будет недостаточно, если, например, предполагается использование модуля (библиотеки, компонента, службы) в нескольких смежных областях. Класс «Книга» для библиотеки, магазина и читателя – это три разных взгляда на одну и ту же сущность с отличающимися ассоциациями и обобщениями. Ещё сложнее дело обстоит с классом «человек». Поэтому не спешите наследовать «менеджера» и «охранника» от класса «сотрудник» вне рамок учёта кадров, ведь они ещё и материально-ответственные лица, руководители или участники проектов, контактные лица, граждане, родители своих чад, налогоплательщики, собственники, вкладчики, заёмщики, автомобилисты…
Про сборку мусора и агрегацию
Достаточно широко известна проблема принадлежности объектов как друг другу, с образованием соответствующей иерархии, так и графу вызовов функций (подпрограмм). По словам М. Донского [11], наличие в некоторых языках механизма сборки мусора, является примером отказа от самой идеи справиться с этими проблемами и молчаливым признанием возможности присутствия в среде объектов, не принадлежащих ни подпрограммам, ни другим объектам.
Итак, сборщик мусора, он же GC – garbage collector в средах программирования с автоматическим управлением памятью. Наиболее очевидное преимущество – программисту не надо заботиться об освобождении памяти. Хотя при этом все равно нужно думать об освобождении других ресурсов, но сборщик опускает планку требуемой квалификации и тем самым повышает массовость использования среды. Но за все приходится платить. С практической стороны недостатки сборщика известны, на эту тему сломано много копий и написано статей, поэтому останавливаться на них я не буду. В ряде случаев недостатки являются преимуществами, в других – наоборот. Черно-белых оценок здесь нет. В конце концов, выбор может лежать и в области психологии: например, я не люблю, когда компьютер пытается управлять, не оставляя разработчику достаточных средств влияния на ход процесса.
Рассмотрим типовой пример, когда сборщик мусора спасает от ошибки программирования, но не спасает от ошибки проектирования. Речь о контейнере, являющемся владельцем своих объектов. Наиболее распространённой ошибкой является сохранение ссылок на эти объекты в другом объекте вне контейнера. При этом часто оказывается, что ссылки ещё живы, но указывают в пустоту, потому что контейнер уже удалён. В случае «ручного» управления в традиционных языках, таких как C++, при обращении по ссылке возникнет ошибка, ведущая к сбою или отказу. При наличии сборщика мусора программа продолжит работу, хотя объекты так и останутся висеть в памяти. Конечно, приятно осознавать, что программа не свалится с ошибкой, а продолжит работу. Особенно если это относительно критичное серверное приложение. Но проблема-то остаётся. Например, «висящие» объекты могут продолжать использовать или даже блокировать системные ресурсы. А могут и просто занимать недопустимо много памяти.
Решение здесь достаточно простое.
НУЖНО ВЗЯТЬ ЗА ПРАВИЛО, ЧТО
контейнер всегда управляет своими объектами. Поэтому обращаться к его внутренним объектам нужно только через интерфейс самого контейнера.
При этом быть готовым к обработке ситуации, когда контейнер говорит: «Извини, но такой объект уже удалён или пока недоступен». Если же объект переходит во владение к другому контейнеру, то он перестаёт управляться прежним. И процесс передачи объекта и управления также не может быть реализован простым присваиванием полученной ссылки.
Метафора из жизни. Вам нужна цитата из книги, библиотечный код которой вы знаете. Пусть цитата занимает одну страницу в книге, её номер вы знаете. Библиотека – контейнер книг. Книжный магазин – тоже. Варианты взаимодействия:
1. Пойти в библиотеку и взять книгу на время. У контейнера остаётся ссылка на вас, если потом книгу будут снимать с учёта (удалять), то о вас вспомнят и попросят вернуть.
//Правильно:
читатель. Книги. Добавить(библиотека. Выдать(код, читатель));
//Ошибка:
читатель. Книги. Добавить(библиотека. Книги(код));
Кстати, ошибка в данном примере означает, что книгу, между нами говоря, вы попросту спёрли, а интерфейс библиотеки позволяет это легко сделать.
2. Обратиться в справочную службу библиотеки и попросить их прислать копию нужной страницы.
//Правильно:
читатель. Реферат. Цитаты. Добавить(библиотека. КопироватьСтраницу(код,
номер_страницы));
//Ошибка:
читатель. Реферат. Цитаты. Добавить(библиотека. Книги(код). Страницы(номер_
страницы));
3. В библиотеке книги не оказалось, купить книгу в магазине.
//Правильно:
покупатель. Книги. Добавить(магазин. Продать(код, покупатель));
//Ошибка:
покупатель. Книги. Добавить(магазин. Книги(код));
Ошибка в данном примере снова означает, что книгу вы украли.
Два совпадения. Случайные ли?
В случае явного управления памятью возникнет системная ошибка: библиотека или магазин полезут без спросу в ваше отсутствие в квартиру за объектом и заберут его назад. Придя домой, вы не обнаружите на полке нужной книги.
В случае же со сборщиком мусора факт кражи книги не вызовет внешних проблем. В самом простом случае библиотека просто удалит ссылку на пропавшую книгу из своих каталогов. Сама книга при этом продолжит занимать место на вашей полке. Но может статься, например, без вашего ведома из книги будут удалены подцензурные страницы, ведь ссылка-то известна.
Оба случая являются логической ошибкой проектирования интерфейсов, но сборщик мусора на некоторое время скроет их от вас. В этой ипостаси сборка мусора, позволяющая программистам избавиться от назойливых ошибок обращения к памяти (access violation), является лишь фиговым листочком, прикрывающим до некоторого момента всё те же старые проблемы. Искренне всем желаю, чтобы этот момент не проявился во время приёмки.
Журнал хозяйственных операций
Отвлечёмся ненадолго от общих концепций и рассмотрим более конкретные проблемы разработки учётных приложений. Вопросы, подобные «почему нельзя хранить остатки в форме текущих величин», «зачем нужна история операций», «зачем там нужна транзакция в режиме «сериализация» (что такое режим serialized можно прочитать в статье [20]), не раз всплывали в дискуссиях, поэтому я кратко расскажу об этом в рамках отдельной главы, чтобы в следующий раз просто ссылаться.
Довольно сжатое изложение статьи «Как проектировать бухгалтерию»[19] в терминах абстракций может быть не очень понятным начинающим. Напротив, статья «Введение в складской учёт»[18] рискует показаться излишне упрощённой и «заточенной» на складскую бухгалтерию с отраслевой спецификой. И в обоих случаях не хватает конкретики, разъясняющей вышеназванные вопросы.
Начнём с первого антишаблона «Таблица остатков», на которые я вдоволь насмотрелся во времена буйного расцвета торгово-складского софтостроения в 1990-х годах. Начинающий проектировщик рассуждает так: мне нужно текущее количество товара в наличии, а все движения, в результате которых эта цифра и появилась, можно оставить в стороне, а то и прямо в первичных документах.
Представьте, что в документ недельной давности вкралась ошибка. Её исправили, причём пересчитанные текущие остатки по-прежнему неотрицательны. Значит ли, что они неотрицательны и на каждый день прошедшей недели? Разумеется, нет. Приходит клиент и говорит: «Мне выписали 10 штук, а на складе только 8, я на вас, жуликов, в суд подам». Парадокс? Никакого парадокса. За товаром он пришёл сегодня, но продали ему товар вчера. А на состояние «вчера» после корректировки остаток был бы отрицательным. Вот ему и не хватило.
Если не верите, что такое возможно, вот схема движения.
Теперь откорректируем приход 2012-04-01 с 12 утюгов на 10. Получаем, что на сегодня их 0. Вроде бы все в порядке. Всё, да не совсем: сегодняшняя закупка ещё не поступила на реализацию. Поэтому вчерашний «минус 2» пока действителен.
Почесав свой мыслительный орган, проектировщик приходит к неутешительному выводу: даже для фактических операций нужно считать остаток по истории (журналу). Не говоря уже о резервировании товара, где ситуация меняется гораздо быстрее: то тут отменили, то там подтвердили.
Но считать по журналу:
• может быть долго;
• необходимо защитить считанные значения, чтобы при последующей записи не возникло «минусов».
