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


R>>Нет, там другое.
R>>Часть функциональности, о которой я говорю там есть. Но только часть, причём не главная. Там нет саморегистрации.
А>ИМХО, как раз основое (оно же главное) там есть. Добавлена только саморегистрация, что есть довольно сомнительное приобретение.

Ну нет же, совсем нет так. В Loki есть только фабрика. Да она хорошо и удобно сделана. Но это давно известная и так сказать простая вещь. Всё что она делает создаёт по идентификатору типа объект типа. И не более.
Я же говорю, о более высокоуровневой функциональности, о метаклассах. Т.е. появляется возможность делать такие вещи как перебрать все типы, получить какие-то их свойства, получить название типа, которое можно вывести пользователю. И всё это удобно для пользователей инфраструктуры. Ничего даже рядом нет в Loki, там есть только создание объектов.
Создание объектов, конечно, важная функциональноть. Но не главная. Если бы я решил только эту задачу, то я бы не стал заводить топик.


А>В "классической" реализации фабрики классов есть возможность собрать вызовы Register в одном месте, что очень удобно при большом количестве "продуктов".

Вопрос спорный. То, о чём говоришь ты, как раз называют плохо расширяемым дизайном. Когда в одном месте много чего-то и это место надо постоянно править. А когда данные распределены и локализованы, это называют расширяемым дизайном. Добавил класс в одном месте и всё заработало. Не надо править в нескольких местах, не надо трогать старый отлаженный код, как предлагаешь ты.


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

Это зависит от идентификатора класса. Если это например название элемента в XML-файле, то не придётся лазить, что бы найти следующий неиспользованный идентификатор. Потомучто это уже проектировщик решит, что элемент называется, например, "person".
Или, если например, если идентификаторы связаны с каким-то протоколом. То тоже не придётся лазить, уже известно, что поддерживаем новый тип с кодом, например, 47.



R>>Там нет возможности нагружать эту инфроструктуру дополнительной функциоанльностью. То о чём я говорю — своего рода метаинформация или рефлекшн — и соответственно код на более высоком уровне.
А>Вот тут хотелось бы поподробнее. Смысл фабрики — сокрытие типов. Откуда возьмётся информация?

А>

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

IS_SIMPLE относится не к экземпляру, а к типу. Не путай это. Т.е это должно выглядеть как:

bool IsSimple = HeaderFactory::IsSimpleType(48);

Хотя, конечно, метод IsSimpleType() можно вынести в IHeader, а его реализацию в Header<>, тогда будет работать как ты хочешь.



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

Не понимаю, чего смешного


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

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

Мне лично, она не кажется бессмысленной. Я применял такое решение на практике. И получал от него вполне практическую выгоду.