GRASP: принцип Pure Fabrication.

Проблема. Какой класс должен обеспечить реализацию шаблонов High Cohesion и Low Coupling или других принципов проектирования, если шаблон Information Expert (например) не обеспечивает подходящего решения?

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

Решение. Присвоить группу обязанностей с высокой степенью зацепления искусственному классу, не представляющему конкретного понятия из предметной области, т. е. синтезировать искусственную сущности для поддержки высокого зацепления, слабого связывания и повторного использования. Такой класс является продуктом нашего воображения и представляет собой синтетику (fabrication). В идеале, присвоенные этому классу обязанности поддерживают высокую степень зацепления и низкое связывание, так что структура этого синтетического класса является очень прозрачной или чистой (pure). Отсюда и название: Pure Fabrication («чистая синтетика»).

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

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

§ класс Sale должен быть связан с интерфейсом реляционной базы данных (таким как JDBC для технологии Java). Поэтому возрастает степень связывания, причем даже не с другим объектом предметной области, а с интерфейсом базы данных;

§ хранение объектов в реляционной базе данных — это достаточно общая задача, решение которой необходимо для многих классов. Возлагая эту обязанность на класс Sale, разработчик не обеспечивает возможности повторного использования этих операций и вынужден дублировать их в других классах.

Поэтому, несмотря на то, что класс Sale является хорошим кандидатом для выполнения обязанности самосохранения в базе данных, согласно шаблону Information Expert, такое распределение обязанностей приводит к низкой степени зацепления, сильному связыванию и невозможности повторного использования кода. Естественным решением данной проблемы является создание нового класса, ответственного за сохранение объектов некоторого вида на постоянном носителе, например в реляционной БД. Его можно назвать PersistentStorage (Постоянное хранилище). Этот класс является продуктом нашего воображения, что полностью соответствует шаблону Pure Fabrication.

Обратите внимание на имя класса PersistentStorage, оно вполне понятно,

хотя объект с аналогичным названием отсутствует в модели предметной области. PersistentStorage — это не понятие из предметной области, а нечто, синтезированное для удобства разработчика программы.

Этот чисто синтетический объект решает следующие задачи.

§ класс Sale сохраняет высокую степень зацепления и слабое связывание;

§ класс PersistentStorage также обладает этими свойствами, выполняя единственную задачу: сохранение объектов на постоянном носителе;

§ класс PersistentStorage является достаточно общим и допускает повторное использование.

Этот пример — типичная ситуация для создания «чисто синтетического» класса. Он позволяет избежать проблем с зацеплением и связыванием и обеспечивает новые возможности для повторного использования.

Обратите внимание, что, подобно остальным, шаблонам GRASP, в данном шаблоне основное внимание уделяется распределению обязанностей. В нашем примере обязанности передаются от класса Sale (выбранного согласно шаблону Expert) новому «чисто синтетическому» классу.

Обсуждение. Проектируемые объекты делятся на две следующие группы:

1) создаваемые на основе декомпозиции представления;

2) создаваемые на основе декомпозиции поведения.

Например, программный класс Sale был создан на основе декомпозиции представления, поскольку он представляет понятие предметной области (или связан с ним). Декомпозиция представления — это типичная стратегия объектного проектирования, позволяющая сократить разрыв между реальными объектами и их программным представлением. Однако иногда возникает потребность распределить обязанности на основе однотипного поведения или реализации некоторого алгоритма, не привязываясь к понятиям реального мира.

Хорошим примером объекта-алгоритма является генератор оглавления TableOfContentsGenerator. Это вспомогательный класс, не имеющий аналога в словаре терминов из предметной области книг или документов. Он предназначен для удобства разработчиков, поскольку в нем сосредоточены методы, реализующие некоторое однотипное поведение. То есть этот класс создан на основе декомпозиции поведения.

Вспомогательный класс не обязательно должен быть «чисто синтетическим». Это название служит скорее целям обучения, поскольку отражает общую идею распределения обязанностей между программными классами: некоторые классы представляют понятия предметной области, а

другие создаются просто для удобства разработчиков. Эти вспомогательные классы зачастую объединяются в группы на основе общности поведения и соответствуют принципу декомпозиции поведения, а не представления. Другими словами, согласно шаблону Pure Fabrication, классы проектируются на основе общей функциональности и представляют собой поведенческие или функционально-ориентированные объекты.

Многие существующие шаблоны объектно-ориентированного проектирования являются примерами использования шаблона Pure Fabrication. К ним можно отнести шаблоны Adapter, Strategy, Command и т.д.

Назначение:

· При использовании шаблона Pure Fabrication реализуется шаблон High Cohesion, поскольку обязанности передаются отдельному классу, сконцентрированному на решении специфического набора взаимосвязанных задач.

· Повышается потенциал повторного использования, поскольку чисто синтетические классы можно применять в других приложениях.

Когда не следует применять шаблон. Новички в области объектно-ориентированного проектирования, имеющие опыт разработки программ в рамках структурного или функционального подхода, зачастую «злоупотребляют» использованием шаблона Pure Fabrication. В их трактовке функции просто превращаются в объекты.

Нет ничего предосудительного в создании функционально-ориентированных или алгоритмически-ориентированных объектов. Однако необходимо соблюдать пропорции между количеством таких объектов и объектов, созданных на основе декомпозиции представления, согласно шаблону Information Expert. Класс Sale тоже имеет право на существование и должен выполнять свои обязанности. Созданные на основе шаблона Information Expert объекты обладают информацией, необходимой для выполнения своих обязанностей и соответствуют принципу слабого связывания объектов. При «злоупотреблении» применением шаблона Pure Fabrication нарушаются требования к слабому связыванию объектов. Типичным симптомом такой ситуации является необходимость передачи данных одного объекта другим объектам для выполнения действий над ними.