Читать онлайн «Дефрагментация мозга. Софтостроение изнутри». Страница 25

Сложнее обстоит дело с теми, кто только начинает свой путь. Прочтение сего труда новичком, как мне кажется, является прямым аналогом попадания в прокрустово ложе диктуемой парадигмы. Потому что книга описывает набор решений, а неокрепшему за недостатком практики уму проектировщика надо научиться самому находить такие решения и пути к ним. Для чего гораздо эффективнее первое время «изобретать велосипеды», нежели сразу смотреть на готовые чужие. На чужие надо смотреть, когда придуман хотя бы один собственный, чтобы понять, насколько он несовершенен, и выяснить, каким же путём можно было бы прийти к лучшим образцам велосипедов данной модели.

Однако книга все-таки дала всплеск, и по воде пошли круги. А. Алексан-дреску в книге «Modern C++ design» начал экспериментировать с реализацией шаблонов на C++ и продвигать в массы свои велосипеды. Появились издания с достаточно абсурдными названиями. Например, «Шаблоны на C#». Постойте, коллеги, какие ещё шаблоны на C#? Оказывается, шаблоны сыграли с программистским сообществом злую шутку: они оказались ещё и зависимыми от языка программирования. То есть, прочитав «банду четырёх», писавших свой труд исходя из возможностей C++, срочно бегите за новой порцией информации, кто для Java, кто для C#. Хотя задумывались шаблоны с обобщающей практики целью.

Поясню на примере использования шаблона Visitor. У Александреску в самом начале описания шагов по применению шаблона на существующей иерархии классов документов, которую нужно наделить новыми функциональными возможностями (в примере шла речь о сборе статистики), в качестве отправной точки приводится следующий код:

Линейный способ

void DocStats::UpdateStats(DocElement& elem)

{

if (Paragraph* p = dynamic_cast<Paragraph*>(&elem))

{

chars_ += p->NumChars();

words_ += p->NumWords();

}

else if (dynamic_cast<RasterBitmap*>(&elem))

{

++images_;

}

else…

добавляем по одному оператору if для каждого типа инспектируемого объекта

}

Автором совершенно справедливо отмечается существенный недостаток этого фрагмента: преобразование типов делает его сложным для сопровождения, кроме того, нет никакой гарантии, что проверка для базового класса не выполнится раньше, чем для производного. Достаточно ошибиться в порядке следования операторов if, и на ветку производных классов программа никогда не попадёт.

Добавлю, что если разные классы элементов документов имеют полиморфные свойства, собираемые статистикой, то задача ещё более усложняется. Например, «параграф» и «формула» могут иметь одно и то же свойство NumChars.

После рассуждений о недостатках линейного кода выносится решение о необходимости виртуализации вызовов путём построения иерархии, аналогичной существующей иерархии классов, и добавления новых методов в неё. То есть реализации шаблона Visitor, описание которого на добрых двух десятках (!) страниц вы можете посмотреть в книжке. Если очень захотите.

Теперь представьте, что вы используете другой язык с развитым механизмом интроспекции типов времени выполнения. Например, отражение (reflection) для. NET. В этом случае «лобовое» решение может выглядеть примерно так:

Использование отражения

class DocStats

{

…

void UpdateStats(DocElement elem)

{

Type elemType = typeof(DocElement);

BindingFlags flags = BindingFlags.Public | BindingFlags.NonPublic |

BindingFlags.Instance;

if (elemType.GetMethod("NumChars")!= null)

chars += (int) elemType.InvokeMember("NumChars", flags | BindingFlags.

InvokeMethod,

null, elem, null);

if (elemType.GetMethod("NumWords")!= null)

words += (int) elemType.InvokeMember("NumWords", flags | BindingFlags.

InvokeMethod, null, elem, null);

if (elemType.GetProperty("Image")!= null)

images++;

…

обследуем все интересующие нас свойства классов

}

}

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

Более того, не требуется и сам шаблон! Можно пойти и другим путём несложной и безопасной реструктуризации: извлечь существующие в неявном виде интерфейсы элементов документа в явные определения и обследовать в методе сбора статистики передаваемый объект на предмет реализации классами интерфейсов. Например, if (elemType is IParagraph), is IImage, is IFormula и т. д. Тогда можно обойтись вообще без отражения.

Наконец, существует и другое специфичное для C++ решение: реализовать аналогичную иерархию с заданной виртуальной операцией и, далее, используя множественное наследование, «подмешать» эти реализации к существующей иерархии, используя в дальнейшем только полученные классы-миксты.

Весьма элегантное решение на основе class helpers есть в Delphi. Мы просто дописываем недостающие методы к существующим классам, причём их исходники для этого не требуются.

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

Несколько позднее я наткнулся в магазине на книгу с названием, претендующим на звание наиболее абсурдного из встречавшихся. Оно звучало как «Thinking in patterns». В переводе на русский язык – «Мыслить шаблонно». Ещё недавно привычка шаблонно мыслить считалась в инженерном сообществе признанием ограниченности специалиста, наиболее пригодного для решения типовых задач с 9 утра до 6 вечера. Теперь не стесняются писать целые книжки о том, как научиться шаблонному мышлению…

Серия коротких заметок была задумана, как некий противовес механистическому подходу к программированию, пропагандируемому различными учебниками шаблонов. Потому что думать надо не шаблонами, а головой. Начнём с того, что кажется очевидным.

Откажитесь от термина «наследование», который искажает смысл действий. Мы обобщаем. Обобщение (наследование) реализации или интерфейсов – весьма неоднозначный механизм в объектно-ориентированном программировании, его применение требует осторожности и обоснования.

ОСНОВНОЕ ПРАВИЛО

Обобщаемые классы должны иметь сходную основную функциональность.

Например, если два или более класса:

• порождают объекты, реализующие близкие интерфейсы;

• занимаются различающейся обработкой одних и тех же входных данных;

• предоставляют единый интерфейс доступа к другим данным, операциям или к сервису.

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

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

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

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

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

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

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

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

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