ofdax: Dynamics AX 7 Codebase Architecture

[trud]

ну а вообще конечно согласен с автором. т.е. в 2012 у вас было какое-нибудь маленькое решение с минимумом пересечений со стандартом(например один измененный не очень популярный енум или evenhandler на какой-нибудь private метод). вы его спокойненько поставляли клиентам как модель, не особо заботясь какие у клиента хотфиксы в основном приложении.
Сейчас же на енумы добавили сво-во IsExtensible которое по умолчанию везде False, создание event на методы помеченные как private запретили (что вообще выше моего понимания) и вы вынуждены делать overlaying, что автоматически приведет к тому, что в пакет с вашим решением добавляется чуть ли не все приложение целиком.
в общем из разряда хотели как лучше, а получилось как всегда

[belugin]

Цитата:

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

создание event на методы помеченные как private запретили (что вообще выше моего понимания)

Если метод private - это деталь реализации, от деталей реализации зависеть нехорошо.

[S.Kuskov]

Цитата:

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

Если метод private - это деталь реализации, от деталей реализации зависеть нехорошо.

А без создания event как можно откастомизировать эту самую реализацию? По старинке?

[gl00mie]

Цитата:

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

Если метод private - это деталь реализации, от деталей реализации зависеть нехорошо.

Это все верно, вот если бы еще разработчики стандарта всегда умели отделять "детали реализации" от возможных точек расширения реализуемых классов. Стопятсот раз на проектах были модифы, в рамках которых приходилось private-метод стандартного класса переделывать в protected. А то понашлепают private-методов, и думаешь - чего было сразу не сделать класс final?..

[belugin]

Цитата:

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

Это все верно, вот если бы еще разработчики стандарта всегда умели отделять "детали реализации" от возможных точек расширения реализуемых классов. Стопятсот раз на проектах были модифы, в рамках которых приходилось private-метод стандартного класса переделывать в protected. А то понашлепают private-методов, и думаешь - чего было сразу не сделать класс final?..

У меня мысль такая.

По идее надо различать API и детали реализации, API это то, изменения чего можно хоть как-то контроллировать (т.е. разделять ломающие изменения и не ломающие).

Если выставлять все методы в API проще плюнуть и париться с ломающими изменениями. Т.е. объявление метода protected должно быть неким ответственным шагом.

С другой стороны, если потребитель принял решение поменять метод с private на protected, это вполне его право - он знает, что берет решение о поддержке этого куска на себя.

Сейчас пока не все готово для того, чтобы полностью отделить API от деталей реализации (Например нет InternalsVisibleTo что делает невозможным юниттестинг), но как-мне кажется, направление в уелом правильное - разделить поддерживаемые и неподдерживаемые модификации.