Здравствуйте, Andir, Вы писали:

A>Давай по-конкретнее, ладно?
Я тебе конкретно и пишу.
S>>Атрибуты ничего не говорят про объекты. Они говорят про классы. Точка. Они не вешают на объект никакую функциональность.

A>Да не говорю я про экземпляры объектов и не говорю про классы, я говорю про абстрактные объекты, которые затем воплощаются в объекты класса на конкретном языке.
Что такое "абстрактные объекты"? Первый раз встречаю этот термин.
A>Атрибуты задают эту функциональность, как и любые другие виды выражения функциональности объекта (свойства, методы).
Нет, это не так.
A>То, что у объекта есть атрибут, уже требует к этому объекту другого отношения, совершенно иного, чем без оного. Под функциональностью объекта я имею ввиду не действия выполняемые объектом, а то каким образом будут выполнятся эти действия.
Это, конечно, странно. Но я тебе еще раз говорю: никакого отношения к объектам атрибуты не имеют. Это способ передать информацию, проассоциированную с, грубо говоря, кодом.

A>Привязывают один объект к тем условиям в которых он работает.
Это так, но никакого нарушения абстракции не происходит. Наследование от библиотечного класса нарушает абстракцию? Наличие ссылок на другие объекты нарушает абстракцию? Вот и атрибуты ничего не нарушают. Они обогащают концепцию окружающй среды, а не сужают ее.

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

A>Не уверен, что правильно понимаю. Но насколько я понял ты говоришь о несовершенной абстракции "регистратор компонента" в визуальной среде, более правильным было бы для регистрации компонента, реализовать класс, который бы своим способом регистрировал бы компонент в визуальной среде (например реализовывая интерфейс IRegisterObject).
Нет, я говорю о том, что нет такого действия "регистрация компонента".

A>И что? Здесь как раз с точки зрения абстракций всё правильно и удобно, на объект не вешается никаких дополнительных функциональностей, а теперь представим, что для того чтобы реализовать регистрацию приходилось бы вызывать статическую функцию RegisterComponent, которая должна была бы быть в каждом компоненте, бред ...
A>Нет, и где здесь правильно и удобно?
Или написать атрибут компоненту [ThisIsVisualComponentForDelphi] ... Принцип именно такой.
Вот. Именно это и было бы правильно и удобно! Потому, что это именно визуальный компонент для Delphi. Не потому, что в какой-то момент была вызвана какая-то процедура, или куда-то передан какой-то интерфейс. А потому что мы назвали вещи свиоми именами. И от компонента дельфи неотделим тот факт, что это компонент дельфи, а не хрень собачья.

Ага. Понятно. Надо мне было попроще и пояснее свои мысли излагать.

Собственно две посылки имеются:
+ сомнительно, чтобы аттрибуты были придуманы на кончике пера. Кажется, что это инженерное решение.
+ будучи настолько синтаксически удобными, аттрибуты заманчивы для "неправильного использования". Встает вопрос: поскольку уточнение намерений в виде метаинформации к классу другими способами немного утомительно, то можно ли ипользовать аттрибуты "не совсем неправильно", добившись этим разной степени открытости объекта для различных подсистем, а еще лучше, разного представления.

Еще одна задачка:
Допустим, что мы хотим иметь для некоторых методов их русские названия. Можно завести hashtable в специальном сервере, но тогда переводы отделены от имен и могут возникать ошибки просто при наборе текста и нельзя быстро узнать, имеет данный метод перевод или нет.
А можно добавить аттрибут. И тогда вроде все неплохо выглядит — наглядно и цельно.

Пример, конечно, убогий, ну и ладно. Пока мы просто думаем о переводе, проблем с аттрибутами нет. Мне так очень кажется. Если нет, то это уже будет интересно.

Так вот, пока это просто перевод, все в порядке. А как только появляется какая-нибудь система отображения названий на экран, система, которая вызывает из объекта только методы, имеющие русские названия, система, которая кладет в определенную таблицу только поля, имеющие русские названия и т.д., то все это начинает попахивать. Потому как классы данных начинают беспокоиться об интерфейсе и еще черт знает о чем. Возникает желание их порезать, отделить данные от особых методов и от особых данных. Появляется много групп классов, очень любящих друг друга, о чем явно в программе ничего не сказано (ну, может, кроме префиксов).