Какой это паттерн проектирования

Question

[Валерий Семенов]

Есть несколько сущностей
категория, статья, событие (особая статья), шаблон страницы

несмотря на то, что они сущности совсем разные, у них есть общие свойства — «текстовое содержание», «картинка», «краткое содержание», «время обновления». Так же у них есть индивидуальные свойства — «дата наступления события», «ссылка на событие» (для статьи) и пр…

к каждому свойству принадлежат ряд методов для работы с ними. Например ряд методов для работы с изображением, ряд методов для работы с текстом. и пр.

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

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

Answer 1

[Тимур Шемсединов]

… несмотря на то, что они сущности совсем разные, у них есть общие свойства… Так же у них есть индивидуальные свойства...

Паттерн этот называется ООП :) А именно — использование абстрактных классов и наследование. Советую почитать хорошую старую литературу типа Гради Буча.

к каждому свойству принадлежат ряд методов для работы с ними. Например ряд методов для работы с изображением, ряд методов для работы с текстом. и пр.

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

возникла мысль написать архитектуру сущностей, как набор примитивных классов-параметров

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

Comments

[Валерий Семенов]

в обычном ООП я получил общий абстрактный класс включающий в себя достаточно много методов, а так же наличие в конкретных реализациях методов которые не нужны (наследуемые от родителя). Ухудшилась читаемость. По видимому пришло время поменять архитектуру. Ваша идея создать классы «изображение», «тексты» и их методы использовать в конкретных реализациях — мне понравилась.

[Тимур Шемсединов]

Это не моя идея, это классический подход. Например класс Image имеет метод Invert. А класс Book имеет свойство Thumbnail класса Image. Код инвертирования не принадлежит Book, а принадлежит Image и когда нам нужно нам нужно инвертировать этот тумбнейл, то пишем Book.Thumbnail.Invert(); Еще есть способ сделать статический класс с утилитами по обработке графики и тогда вызов будет в импорвизированном псевдокоде (я ж не знаю на чем Вы пишете) такой: ImageUtils::Invert(Book.Thumbnail); Задача в том, чтобы не смешать служебное и прикладное и чтобы код группировался по классам и файлам не вызывая перегруженности, и при этом не накрутить сложности.

Answer 2

[gl00k]

Похоже это паттерн компоновщик, хотя я могу ошибаться.

Comments

[Валерий Семенов]

и да и нет. Потому как в компоновщике речь идет о том, что бы компонент рассматривать не только как компонент, но и как объединение компонентов. Мне кажется что здесь что-то среднее между компоновщиком и декоратором.

Answer 3

[Weageoo]

Похоже на обычное наследование.

Comments

[Weageoo]

И как-то всё абстрактно, тяжело вникнуть в мыслю.

[Валерий Семенов]

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

Answer 4

[Ололёша Ололоев]

Либо наследование от абстрактных классов (c++), от интерфейсов (java, C#), или duck typing в скриптовых языках (python, groovy, etc).

А вообще, есть принципы SOLID (http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29), в котором буква I означает ISP — interface segregation principle (http://en.wikipedia.org/wiki/Interface_segregation_principle). Это оно самое и есть.