AX2012. Цель атрибутов в расширении наследования классов

[mazzy]

Цитата:

Сообщение от Raven Melancholic

теперь много времени уходит на то, чтобы понять что же такое "ритейл".

велкам.

Цитата:

Сообщение от Raven Melancholic

Для начала, чтобы не тратить время, определимся что такое конструктор. На мой взгляд, конструктор это то, что создает класс. В Аксе это метод new. Принято создавать статический метод construct, но, несмотря на название это все-таки не конструктор в общем понимании, а метод фабрики.

да. согласен.

Цитата:

Сообщение от belugin

Никаких запускачей и нет. Есть не запускач, а создавач. Люди которые читали книжку GoF его называют фабрикой, просто потому, что не догадались до имени "создавач" .

да. фабрика. согласен, хороший стандартный термин. и уводит от путаницы с constructor.

Цитата:

Сообщение от belugin

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

Журнал - это сильно obsolete инструмент.
насколько я помню, это было еще до того, как научились сохранять параметры диалога для пакетных заданий.
сейчас скорее будет запущено что-то через главное меню или через меню в какой-то форуме.

Цитата:

Сообщение от Raven Melancholic

Понимаю, что mazzy ждет от поведения системы (то же что и другие люди, знакомые в Аксой, в том числе и я): привычные подходы, которые используются кучу лет, простые способы внесения изменений, ловлю любых зависимостей перекрестными ссылками и т.п.

не совсем так. пусть они будут непривычными.
но пусть будут такими, что покрывают множество сценариев использования. пусть они будут универсальными.

Цитата:

Сообщение от Raven Melancholic

Я не очень понимаю, почему mazzy считает, что изменение иерархии путем включения какого-то класса не в качестве последнего листа, а в середину иерархии отличается при использовании фабрики, основанной на атрибутах и фабрики, основанной на switsh-case?

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

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

Цитата:

Сообщение от belugin

Классы бывают не только вызываемые из непосредственно из UI, не только с методами main но и всякие другие. Использование контроля прав доступа нужно далеко не везде. (Я кстати не видел нигде ключевой атрибут по mеnuitem - тут ты ломишься в открытую дверь - если класс именно вызывается - то есть потомок runbase, и по меню айтем можно его однозначно определить, то он связывается с ним непосредственно).

может. бывают. можно однозначно определить.
не нужен UI - просто создай menuItem и ничего с ним не делай. понадобиться - просто продолжай использовать menuItem.
в отличие от атрибута.

вы снова говорите как это работает.
это работает.

я говорю о трудоемкости и стоимости работ на разобраться, добавить функционал, дать пользователю, поддерживать в дальнейшем.

технология на атрибутах требует двойных-тройных трудозатрат. я только об этом.
и да: большинство преимуществ атрибутов можно проявить только для решения внутренних МСовских задач и только в окружении МС, где атрибуты уже повсеместно используются. Там таки да - шикардос и позднее связывание рулит. остальным только усложнит жизнь.