Дефрагментация мозга

Взгляните, три примера, и уже несколько шаблонов оказались ненужными: (1) – «фабричный метод» (factory method), (2) – «стратегия» (strategy), «шаблон метода» (template method) и (3) – «адаптер» (adapter). В принципе, можно для случая (1) ещё и «прототип» (prototype) записать: если в среде нет развитой поддержки метаинформации типа отражения (reflection), то реализовать клонирование, скорее всего, придётся в потомках общего предка. Далее, в большинстве случаев (если не во всех) вместо «посетитель» (visitor) можно использовать все тот же «шаблонный метод» или вызов метода через reflection, как уже было описано в предыдущей главе. Ещё один исключаем.

Почему шаблоны «вдруг» стали ненужными? Потому что требуется только обобщение, причём в перечисленных случаях необходимость операции более чем очевидна. Требования же исходят напрямую из вашей задачи. Корректно проведя обобщение вы автоматически получите код и структуру, близкую к той, что вам предлагают зазубрить и воспроизводить авторы разнообразных учебников шаблонов.

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

Основная ошибка – обобщение по неосновному функциональному признаку. Например, когда обобщают сотрудников и пользователей. Или заказы на поставку и накладные на отгрузку. Или яблоки с теннисными мячиками. Почему нет, они же разноцветные, круглые и продаются в магазинах?

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

Не увлекайтесь обобщением. Ошибки тоже обобщаются и уже в прямом смысле этого слова наследуются. Исправление по новому требованию может привести к необходимости сноса старой иерархии, содержащей ошибки.

ВОЗЬМИТЕ ЗА ЭМПИРИЧЕСКОЕ ПРАВИЛО

Глубина более двух уровней при моделировании объектов предметной области, вероятнее всего, свидетельствует об ошибках проектирования.

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

Про сборку мусора и агрегацию

Достаточно широко известна проблема принадлежности объектов как друг другу, с образованием соответствующей иерархии, так и графу вызовов функций (подпрограмм). По словам М. Донского [11], наличие в некоторых языках механизма сборки мусора, является примером отказа от самой идеи справиться с этими проблемами и молчаливым признанием возможности присутствия в среде объектов, не принадлежащих ни подпрограммам, ни другим объектам.

Итак, сборщик мусора, он же GC – garbage collector в средах программирования с автоматическим управлением памятью. Наиболее очевидное преимущество – программисту не надо заботиться об освобождении памяти. Хотя при этом все равно нужно думать об освобождении других ресурсов, но сборщик опускает планку требуемой квалификации и тем самым повышает массовость использования среды. Но за все приходится платить. С практической стороны недостатки сборщика известны, на эту тему сломано много копий и написано статей, поэтому останавливаться на них я не буду. В ряде случаев недостатки являются преимуществами, в других – наоборот. Черно-белых оценок здесь нет. В конце концов, выбор может лежать и в области психологии: например, я не люблю, когда компьютер пытается управлять, не оставляя разработчику достаточных средств влияния на ход процесса.