Не только бессмысленно но и плохо. При поддержке, рефакторинге, фиксинге, вместо одной измененной строки, получается много. Это касается любого выравнивания по длине чеголибо.
Статические поля инициализируются ДО любого использования класса. Статический конструктор вызывается ДО использования класса и ПОСЛЕ инициализации статических полей.
Все остальное сильно зависит от реализации и условий. Обычно статический констурктор вызывается после компиляции класса, класс компилирируется тогда, когда до него «дотронутся». Дотронутся до него, это не только вызов метода, но и компиляция метода, где этот класс используется.
Напомню, старкрафт был 256 цветов. Прибавить к этому неизометрический мир, который экономил место на карте, в отличии, например от Ege of Empares. В итоге, это та игра, из за которой я начал серьезно заниматься разработкой игр.
В слабосвязаной архитектуре не всегда есть центральный компонент. Я бы даже сказал такого нужно избегать. В каждом слое может быть несколько ключевых сервисов, каждый из которых выполняет только свои роли.
Очень жалко что нет четкого промышленного стандарта. Например, такого как XPath. Поэтому многие сразу юзают связку XPath + XML. Стремление объеденить все форматы для однообразного применения шаг к абстракции, но рождает такие «костыли» как <xmlattr>.
>> вы можете использовать похожую систему, а можете не использовать
Этот вопрос вам задают с самого начала.
Проcтите меня за новый виток упоминайний:
DI решает задачу однообразно
ICloneable решает задачу однобразно
Байндинг решает задачу однообразно
STL решает задачу однообразно
boost решает задачу однообразно
Любая библиотека любого языка решает задачу однообразно
Паттерны решают задачу однообразно
У атрибутов разные задачи, но они не решают эти задачи. Они позволяют наметить (описать) дейстивие. Система атрибутов тоже не решает задачи, она позволяет удобнее определить действие, удобнее его описать и сохранять для последующего его исполнения внешним кодом.
Я очень сильно извиняюсь, но статья не про DI, не про сериализаторы, не про байндинг, не конвертацию типов, не про клонирование. Статья про систему, которая однообразно позволяет работать с атрибутами. Если в вашем проекте есть много атрибутов (ваших) с разными задачами, вы можете использовать похожую систему, а можете не использовать.
Почему то, когда в статье упоминается сериализация или клонирование, многие думают что статья про новый сериализатор или новую систему клонирования.
Если внимательно посмотреть, то пример без системы и пример с системой функционально идентичны. Отсюда следует, что система не решает задачи примеров.
Про Unity и другие DI контейнеры слышали, но, к сожалению, на момент разработки, Unity не существовало. А так как, по мнению ms, огромный пласт реализаций имеет «существенный недостаток» многие реализации автоматически переходят в разряд велосипедов.
DI привел для примера, он уже был реализован во фреймворке изначально.
Поностью согласен. Любые решения универсальности ради универсальности обречены.
Данная схема была разработана очень давно для ммо проекта. Она позволяла универсально связывать атрибуты с действиями для которых эти атрибуты созданы. Например если разработчику было необходимо инициализаторовать поля зависимостями автоматически, то он добавлял в систему атрибут, а внутри него писал логику ожидания компонента и его привязку, все остальное делала система.
Это позволяло однообразно решать все задачи связаные с атрибутами и уменьшало порог вхождения для новых разработчиков.
Помимо этой системы были и другие, о которых будут другие статьи.
Конвертейбл не подходит. Типы могут быть сложными, мы можем не иметь к ним доступ. Например могут быть агрегированые типы, могут быть типы без доступа к реализации. Так же присутсвуют различные среды, для каждой среды могут быть разные конверторы и объект не знает про эти среды.
Сервис не должен искать в системе все атрибуты, потому что сборки могут загружатся и выгружатся динамически. Он должен предоставить точку для регистрации. Обработчики могут иметь произвольный тип и форму, это не обязательно метод с атрибутом.
У нас везде где только можно используется IoC поэтому сервисы не знают систему и окружение, они знают только то от чего зависят.
Но мне кажется это уже совсем другая тема и далеко от сути статьи.
Предположим есть система конвертации типов, некий сервис. В нем любой компонент может зарегестрировать делегат для конвертирования типа. Для упрощения регестрирования мы делаем атрибут и метим им метод. Атрибут регестрирует метод в сервисе конвертирования.
В данном примере, метод это обработчик а код в атрибуте это регистратор.
Все остальное сильно зависит от реализации и условий. Обычно статический констурктор вызывается после компиляции класса, класс компилирируется тогда, когда до него «дотронутся». Дотронутся до него, это не только вызов метода, но и компиляция метода, где этот класс используется.
<xmlattr>.>> DI – это набор принципов и паттернов
DI не привязан к языку.
>> вы можете использовать похожую систему, а можете не использовать
Проcтите меня за новый виток упоминайний:
DI решает задачу однообразно
ICloneable решает задачу однобразно
Байндинг решает задачу однообразно
STL решает задачу однообразно
boost решает задачу однообразно
Любая библиотека любого языка решает задачу однообразно
Паттерны решают задачу однообразно
У атрибутов разные задачи, но они не решают эти задачи. Они позволяют наметить (описать) дейстивие. Система атрибутов тоже не решает задачи, она позволяет удобнее определить действие, удобнее его описать и сохранять для последующего его исполнения внешним кодом.
Почему то, когда в статье упоминается сериализация или клонирование, многие думают что статья про новый сериализатор или новую систему клонирования.
Если внимательно посмотреть, то пример без системы и пример с системой функционально идентичны. Отсюда следует, что система не решает задачи примеров.
DI привел для примера, он уже был реализован во фреймворке изначально.
Данная схема была разработана очень давно для ммо проекта. Она позволяла универсально связывать атрибуты с действиями для которых эти атрибуты созданы. Например если разработчику было необходимо инициализаторовать поля зависимостями автоматически, то он добавлял в систему атрибут, а внутри него писал логику ожидания компонента и его привязку, все остальное делала система.
Это позволяло однообразно решать все задачи связаные с атрибутами и уменьшало порог вхождения для новых разработчиков.
Помимо этой системы были и другие, о которых будут другие статьи.
Сервис не должен искать в системе все атрибуты, потому что сборки могут загружатся и выгружатся динамически. Он должен предоставить точку для регистрации. Обработчики могут иметь произвольный тип и форму, это не обязательно метод с атрибутом.
У нас везде где только можно используется IoC поэтому сервисы не знают систему и окружение, они знают только то от чего зависят.
Но мне кажется это уже совсем другая тема и далеко от сути статьи.
Предположим есть система конвертации типов, некий сервис. В нем любой компонент может зарегестрировать делегат для конвертирования типа. Для упрощения регестрирования мы делаем атрибут и метим им метод. Атрибут регестрирует метод в сервисе конвертирования.
В данном примере, метод это обработчик а код в атрибуте это регистратор.