Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Эээ… А зачем еще велосипеды-то?
DataAnnotations, DataContracts…
Универсальная фабрика тоже напрягает своей универсальностью и оверархитектурой.
А клонирование — вообще долгая и холиварная тема. Есть мнение, что если нужна тонкая настройка клонирования, то его лучше делать через сериализацию/маршаллинг.
DataAnnotations, DataContracts…
Универсальная фабрика тоже напрягает своей универсальностью и оверархитектурой.
А клонирование — вообще долгая и холиварная тема. Есть мнение, что если нужна тонкая настройка клонирования, то его лучше делать через сериализацию/маршаллинг.
Очень извиняюсь, но статья не об этом.
А о чем?
Статья не о велосипедах, не о том что вот у вас такойто велосипед, а его можно вот так то завелосипедить. Статья об унификации работы с атрибутами. В проектах где очень много атрибутов, поиск регистраторов и обработчиков усложняется. Атрибуты используются не только для сериализации и клонирования, в статье приведенны узнаваемые примеры для простоты.
В наших проектах атрибуты использовались для фабрик, агрегации, разметки данных, биндинга обработчиков, связи контекстов с функциями и т.п.
В наших проектах атрибуты использовались для фабрик, агрегации, разметки данных, биндинга обработчиков, связи контекстов с функциями и т.п.
В проектах где очень много атрибутов, поиск регистраторов и обработчиков усложняется.
А какая связь между атрибутами, регистраторами (это вообще что?) и обработчиками (и это что?)?
У нас в проекте атрибутов очень много, но никаких регистраторов и обработчиков не наблюдается вообще. Может, вы о какой-то конкретной задаче говорите?
Попробую примеры привести.
Предположим есть система конвертации типов, некий сервис. В нем любой компонент может зарегестрировать делегат для конвертирования типа. Для упрощения регестрирования мы делаем атрибут и метим им метод. Атрибут регестрирует метод в сервисе конвертирования.
В данном примере, метод это обработчик а код в атрибуте это регистратор.
Предположим есть система конвертации типов, некий сервис. В нем любой компонент может зарегестрировать делегат для конвертирования типа. Для упрощения регестрирования мы делаем атрибут и метим им метод. Атрибут регестрирует метод в сервисе конвертирования.
В данном примере, метод это обработчик а код в атрибуте это регистратор.
IConvertible, не?
Но даже если на это не смотреть, то у вас все равно обязанности распределены неверно, потому что сервис должен находить метод по атрибуту, а не атрибут регистрировать метод в сервисе.
Но даже если на это не смотреть, то у вас все равно обязанности распределены неверно, потому что сервис должен находить метод по атрибуту, а не атрибут регистрировать метод в сервисе.
Конвертейбл не подходит. Типы могут быть сложными, мы можем не иметь к ним доступ. Например могут быть агрегированые типы, могут быть типы без доступа к реализации. Так же присутсвуют различные среды, для каждой среды могут быть разные конверторы и объект не знает про эти среды.
Сервис не должен искать в системе все атрибуты, потому что сборки могут загружатся и выгружатся динамически. Он должен предоставить точку для регистрации. Обработчики могут иметь произвольный тип и форму, это не обязательно метод с атрибутом.
У нас везде где только можно используется IoC поэтому сервисы не знают систему и окружение, они знают только то от чего зависят.
Но мне кажется это уже совсем другая тема и далеко от сути статьи.
Сервис не должен искать в системе все атрибуты, потому что сборки могут загружатся и выгружатся динамически. Он должен предоставить точку для регистрации. Обработчики могут иметь произвольный тип и форму, это не обязательно метод с атрибутом.
У нас везде где только можно используется IoC поэтому сервисы не знают систему и окружение, они знают только то от чего зависят.
Но мне кажется это уже совсем другая тема и далеко от сути статьи.
Конвертейбл не подходит. Типы могут быть сложными, мы можем не иметь к ним доступ. Например могут быть агрегированые типы, могут быть типы без доступа к реализации. Так же присутсвуют различные среды, для каждой среды могут быть разные конверторы и объект не знает про эти среды.
Тут тоже атрибут не нужен, достаточно интерфейса на реализации.
Но мне кажется это уже совсем другая тема и далеко от сути статьи.
Вот именно. А по теме статьи — так и не понятно, зачем и кому нужен унифицированный обработчик атрибутов, учитывая, что задачи решаются разные. retran уже все написал об этом.
Ну вот например: зачем помечать фабрику атрибутом, если фабрики — это задача DI/SL (раз уж у вас везде IoC), и все штатные реализации прекрасно живут без атрибутов.
Об этом.
Любая универсализация должна строиться на базе некоего набора неуниверсальных решений и четкой оценки что даст такая универсализация.
Почти все решения, которые сразу делаются универсальными ради универсальности в итоге оказываются гораздо дороже в поддержке и ломаются, когда вы натыкаетесь на задачу о которой не подумали, во время проектирования. Классика же.
Соответственно, я сделал вывод, что вы универсализируете некий набор собственных велосипедов. А отсюда вопрос — а зачем понадобились эти велосипеды и не дешевле было бы все это выбросить сразу?
Любая универсализация должна строиться на базе некоего набора неуниверсальных решений и четкой оценки что даст такая универсализация.
Почти все решения, которые сразу делаются универсальными ради универсальности в итоге оказываются гораздо дороже в поддержке и ломаются, когда вы натыкаетесь на задачу о которой не подумали, во время проектирования. Классика же.
Соответственно, я сделал вывод, что вы универсализируете некий набор собственных велосипедов. А отсюда вопрос — а зачем понадобились эти велосипеды и не дешевле было бы все это выбросить сразу?
Поностью согласен. Любые решения универсальности ради универсальности обречены.
Данная схема была разработана очень давно для ммо проекта. Она позволяла универсально связывать атрибуты с действиями для которых эти атрибуты созданы. Например если разработчику было необходимо инициализаторовать поля зависимостями автоматически, то он добавлял в систему атрибут, а внутри него писал логику ожидания компонента и его привязку, все остальное делала система.
Это позволяло однообразно решать все задачи связаные с атрибутами и уменьшало порог вхождения для новых разработчиков.
Помимо этой системы были и другие, о которых будут другие статьи.
Данная схема была разработана очень давно для ммо проекта. Она позволяла универсально связывать атрибуты с действиями для которых эти атрибуты созданы. Например если разработчику было необходимо инициализаторовать поля зависимостями автоматически, то он добавлял в систему атрибут, а внутри него писал логику ожидания компонента и его привязку, все остальное делала система.
Это позволяло однообразно решать все задачи связаные с атрибутами и уменьшало порог вхождения для новых разработчиков.
Помимо этой системы были и другие, о которых будут другие статьи.
Например если разработчику было необходимо инициализаторовать поля зависимостями автоматически, то он добавлял в систему атрибут, а внутри него писал логику ожидания компонента и его привязку, все остальное делала система.
Типичный велосипед, да. Про Unity (и другие DI-контейнеры) вы ничего не слышали?
Про Unity и другие DI контейнеры слышали, но, к сожалению, на момент разработки, Unity не существовало. А так как, по мнению ms, огромный пласт реализаций имеет «существенный недостаток» многие реализации автоматически переходят в разряд велосипедов.
DI привел для примера, он уже был реализован во фреймворке изначально.
DI привел для примера, он уже был реализован во фреймворке изначально.
Про Unity и другие DI контейнеры слышали, но, к сожалению, на момент разработки, Unity не существовало.
Это, простите, когда было? И что, NInject тоже не существовало?
DI привел для примера, он уже был реализован во фреймворке изначально.
Вот понимаете, пока все ваши примеры «зачем это нужно» упираются в то, что это не нужно.
Я очень сильно извиняюсь, но статья не про DI, не про сериализаторы, не про байндинг, не конвертацию типов, не про клонирование. Статья про систему, которая однообразно позволяет работать с атрибутами. Если в вашем проекте есть много атрибутов (ваших) с разными задачами, вы можете использовать похожую систему, а можете не использовать.
Почему то, когда в статье упоминается сериализация или клонирование, многие думают что статья про новый сериализатор или новую систему клонирования.
Если внимательно посмотреть, то пример без системы и пример с системой функционально идентичны. Отсюда следует, что система не решает задачи примеров.
Почему то, когда в статье упоминается сериализация или клонирование, многие думают что статья про новый сериализатор или новую систему клонирования.
Если внимательно посмотреть, то пример без системы и пример с системой функционально идентичны. Отсюда следует, что система не решает задачи примеров.
Статья про систему, которая однообразно позволяет работать с атрибутами.
А зачем мне с ними однообразно работать?
Если в вашем проекте есть много атрибутов (ваших) с разными задачами
… особенно если у атрибутов разные задачи — зачем работать с ними однообразно?
Этот вопрос вам задают с самого начала.
А зачем мне с ними однообразно работать?
>> вы можете использовать похожую систему, а можете не использовать
Этот вопрос вам задают с самого начала.
Проcтите меня за новый виток упоминайний:
DI решает задачу однообразно
ICloneable решает задачу однобразно
Байндинг решает задачу однообразно
STL решает задачу однообразно
boost решает задачу однообразно
Любая библиотека любого языка решает задачу однообразно
Паттерны решают задачу однообразно
У атрибутов разные задачи, но они не решают эти задачи. Они позволяют наметить (описать) дейстивие. Система атрибутов тоже не решает задачи, она позволяет удобнее определить действие, удобнее его описать и сохранять для последующего его исполнения внешним кодом.
У атрибутов разные задачи, но они не решают эти задачи. Они позволяют наметить (описать) дейстивие.
Вы почему-то исходите из того, что атрибуты — это действия. А это утверждение как минимум спорно.
Проcтите меня за новый виток упоминайний:
Этот ваш виток упоминаний показывает список задач, из которых каждая решается однообразно, но все вместе они решаются по-разному. Иными словами, нет смысла решать задачи DI и клонирования единообразно (точно так же, как нет смысл везде применять один и тот же паттерн).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Система работы с атрибутами