Здравствуйте, remark, Вы писали:

R>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, remark, Вы писали:

R>>>Решение для типовой задачи, когда есть интерфейс, реализации интерфейса, и реализации создаются фабрикой по некоторому значению (типу реализации). В решении обеспечивается саморегистрация классов реализаций интерфейса в фабрике, т.о. отпадает необходимость в switch'е в фабрике, и решение становиться максимально открытым для расширения.
R>>>Может кому будет полезно. Или кто выскажет конструктивные замечания.

А>>См. Александреску "Современное проектирование...". ИМХО там реализация лучше. А в последних версиях Loki аффтар "творчески переработал" этот кусок.

R>Нет, там другое.
R>Часть функциональности, о которой я говорю там есть. Но только часть, причём не главная. Там нет саморегистрации.
ИМХО, как раз основое (оно же главное) там есть. Добавлена только саморегистрация, что есть довольно сомнительное приобретение. В "классической" реализации фабрики классов есть возможность собрать вызовы Register в одном месте, что очень удобно при большом количестве "продуктов". В твоём же случае, когда тебе понадобиться добавить очередной продукт, придётся обшарить все модули с целью узнать следующее незанятое значение TYPE. А их может быть несколько больше, чем один.
R>Там нет возможности нагружать эту инфроструктуру дополнительной функциоанльностью. То о чём я говорю — своего рода метаинформация или рефлекшн — и соответственно код на более высоком уровне.
Вот тут хотелось бы поподробнее. Смысл фабрики — сокрытие типов. Откуда возьмётся информация?

    IHeader::Ptr h1 = HeaderFactory::create(48);
    h1 ... что дальше? IS_SIMPLE? как?

R>Хотя, возможно, мой класс фабрики можно относледовать от класса Loki::Factory, что бы заюзать часть функциональности.
))))

R>Плюсы:
R>1. Практически нулевое дублирование, что важно для сопровождаемого кода

R>2. Инрастуктура функциональная, расширяемая и "умная"
Loki::Factory
R>3. Сами классы реализаций интерфейсов абсолютно самодостаточные, самоописываемые, т.е. высокая локальность данных и R>функций
Это уж как их реализует пользователь этой фабрики.
R>4. Чтобы добавить новый класс реализации надо просто его описать и его поддержка автоматически появиться везде где R>она должна быть. Чем не может похвастаться традиционный подход — саму реализацию добавил, добавил её поддержку в R>фабрику, добавил её поддержку в интерфейс пользователя, а при загрузке из БД забыл.
Про обратную сторону медали этого удобства я уже писал.

Резюмируя: к Loki::Factory добавлено две примочки, одна из которых может быть полезна при условии, что реализация продуктов сконцентрирована в очень небольшом числе модулей, а вторая просто бессмыслена.


Это при условии, что я всё правильно понял.