LINUX.ORG.RU

[ООП головного мозга] посоветуйте паттерн


0

1

Дорогие друзья,

Подскажите пожалуйста стандартное ООП решение следующей задачи:

есть множество продуктов, разделенных на классы. И должны быть возможности:

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

Как такая типичная задача решается с помощью ООП и паттернов?

Поясню где у меня затык: поскольку продукты разделены на классы, то само собой напрашивается ввести для каждого класса продукта свой class, который содержал бы уникальные для этого класса продукта свойства:

class Hammer
  - size
  - weight
  - material

class Mug
  - color
  - photo

class Cat
  - age
  - tail length

Но как быть дальше? Например, чтобы администрировать продукт, логично было бы определить интерфейс для генерации админ. формы и применения ее результатов к объекту:

interface IEditable
    - getAdminForm() : Form
    - applyChangesFromForm(Form form)

и сказать, что каждый класс реализовает этот интерфейс.

class Hammer implements IEditable ...

В этом случае где-то в админской части будет код вида

       drawAdminForm(IEditable item)
, через который все продукты будут администрироваться.

Но в этом случае получается что Hammer:
1. будет содержать какой-то низкоуровневый код для генерации формы;
2. будет привязка к конкретной реализации формы.

Другой вариант вынести код из Hammer:

class HammerConcreteAdminForm implements IHammer
         /*ctor*/ HammerConcreteAdminForm(Hammer hammer) {...}
Но, поскольку HammerConcreteAdminForm очень тесно связана с Hammer, то хочется как-то его инкапсулировать в него. Иначе, например, добавили новое свойство в Hammer, забыли исправить HammerConcreteAdminForm и получили баг.

Как быть?

UPDATE: предполагается, что логика генераций форм для разных типов продуктов разные, то есть вариант «возвращать список полей и генерить форму внешним генератором форм» не подходит



Последнее исправление: LORd (всего исправлений: 1)

будет содержать какой-то низкоуровневый код для генерации формы

Зачем? Пусть форму генерирует интерфейс по набору свойств (заданных например в виде массива структур (<тип>, <комментарий>, <значение по-умолчанию>).

anonymous
()

вообще для сих целей надо factory, и memento, в принципе если ЯП поддерживает RTTI по просту говоря это ява или шарп, то нахре ни один из этих паттерном нинужен - благодаря рефлешкену пишется генератор форм и orm.

anonymous
()
Ответ на: комментарий от anonymous

В сишечке тоже есть RTTI, как бы typeid и dynamic_cast.

hippi90 ★★★★★
()

Все эти варианты предполагают что для генерации формы/ клиентского окошка достаточно знать список полей. Но если между полями есть сложные зависимости итд, которые сложно выразить какими-то универсальными средствами.

Или, например, для клиентской части: разные формы для GUI и Web, логика отображения у продуктов разная.

LORd
() автор топика

Нормальное решение это сделать на каждый класс продукта класс-форму + класс ассемблер формы из объекта.

Иначе, например, добавили новое свойство в Hammer, забыли исправить HammerConcreteAdminForm и получили баг.

Не вижу здесь бага. Гораздо отстойней вижу вариант, что добавил я вот для каких-то своих целей поле объекту Hammer, а оно хренак - вылезло на UI.

Если хотите схему Date - View то проще всего забить вообще на все классы - они лишь будут мешающей прослойкой и нахреначить интерфейс работы прямо с нужными таблицами в БД.

dizza ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.