Привет RSDN!

Представляю вам попытку номер два своих рассуждений об атрибутах.

Итак атрибуты по своей сути представляют собой некие сущности дополняющие объект информацией о его возможном поведении в различных ситуациях использования этого объекта. Иными словами метаинформация присущая всем экземплярам этого объекта в программе.
Первое знакомство с ними обычно во всех книжках, которые я читал и в MSDN приводится в виде аналогии с ключевыми словами public, private языка C++. Далее говорится, что теперь с помощью .Net можно создавать свои Атрибуты и дополнять свои объекты новыми свойствами, а точнее нотификациями как употреблять те или иные свойства объекта.
Для пояснения всего что хочу сказать приведу примеры атрибутов:

// Псевдо атрибуты, приведены для пояснения
1) [Public]
2) [Private]
3) [Security(/*Уровень доступа*/)]
4) [Serializable]
5) [OtherGlobalAttribute]
6) [OtherLocalAttribute]
7) [MyLocalAttributeUseInThisProgram]

1) и 2) глобальные атрибуты аналогичны соответсвующим ключевым словам языка С++ и должны выполнять аналогичную роль. То есть встретив такой атрибут у метода, тот кто хочет выполнить этот метод должен на основании этих атрибутов решить можно ли вызывать этот метод или нет. (Должен присутствовать у методов и классов)
3) тоже глобальный атрибут предназначенный для защиты некоторых методов и полей объекта от несанкционированного доступа. (Если объект нуждается в безопасности, то должен присутствовать, иначе может и отсутствовать)
4) Уже не столь явно глобальный аттрибут, но всё ещё отражающий некоторые свойства объекта. (Может быть, а может и не быть, но явно влияет на свойства объекта и его поведение в контексте других объектов)
5) В принципе аналогичен 4).
6) Локальный атрибут — атрибут который явно не оказывает влияние на свойства объекта, но отражает его поведение для некоторого ограниченного числа Других Объектов, которым известно про данный атрибут.
7) Минимальный локальный атрибут, написанный для употребления только в данной программе и отражающий поведение объекта относительно другого объекта, которому про данный атрибут известно.

Из вот такого рассмотрения можно я делаю примерно такой вывод:
Сам объект не управляет собой с помощью атрибутов, по большому счёту, это просто указание внешним объектам программы использовать его в соответсвии с указанными атрибутами, если внешний объект знаком с ними, иначе undefined behavior.

Теперь о нелогичности применения атрибутов в .Net.
Представим, что я проектирую некоторый объект, обладающий какой-то функциональностью, например считает вычисляет некоторое математическое выражение своих полей. Имеет функцию get_Result(), которая возвращает результат. Атрибуты в которых нуждается этот объект, например, что внутренние поля [Private], и заполняются только конструктором, а функция get_Result() доступна извне объекта ([Public]). Если тот кто решит использовать этот объект не станет обращать внимания на эти атрибуты, то соответственно может получить неправильный результат (например, если он кешируется).
Итак функциональность объекта создана, все свои функции он выполняет так как мне нужно. Теперь я его решил использовать в одной из своих программ, предположим, что программа должна быть защищённой, а значит придётся моему объекту навешивать на себя ещё и атрибуты безопасности, хотя к функциональности объекта эти атрибуты не имеют никакого отношения. Дальше мне его нужно сериализовывать по сети и там восстанавливать, естественно, что теперь мне придётся навесить и ещё пару тройку атрибутов для сериализатора, хотя опять же на функциональность объекта они никак не влияют, они влияют, только на то, сможет ли объект после восстановления оказаться идентичным исходному.
Дальше больше ...
Я в этой программе своему объекту решил дать ещё один атрибут [MyObject], чтобы затем использовать где-то для реализации некоторой функциональности ... Больше я нигде этот атрибут и не увижу и не услышу, и никто его использовать не будет, однако объект будет помечен этим атрибутом на всю его долгую жизнь в виде библиотеки ...

// Псевдо реализация спроектированного объекта
class MathExpression
{
    [Private]
    private int field1;

    [Private]
    private float field2;
    
    [Public]
    public MathExpression(int field1, float field2){/*Детали реализации скрыты*/}

    [Public]
    public int get_Result(){/*Детали реализации скрыты*/}

    /*Возможны ещё вспомогательные поля и структуры*/
}

// Псевдо реализация спроектированного объекта в конкретной программе
[MyObject]
class MathExpression
{
    [XmlIgnore]
    [Security("Nobody")]
    [Private]
    private int field1;

    [Security("Nobody")]
    [Private]
    private float field2;
    
    [Security("Administrator")]
    [Public]
    public MathExpression(int field1, float field2){/*Детали реализации скрыты*/}

    [Security("EveryOne")]
    [Public]
    public int get_Result(){/*Детали реализации скрыты*/}

    /*Возможны ещё вспомогательные поля и структуры*/
}

(Код приведён только для демонстрации).

Для сравнения мне приходит в голову ещё один аналог: Для того, чтобы сериализовывать объект, заводится статический константный массив в котором перечислены поля объекта предназначенные для сериализации + их названия (алиасы) ... Никем кроме как сериализатора этот массив не используется, но в каждом объекте(программе) присутствует ...

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

С Уважением, Andir!

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

VD>А кто тебе сказал, что атрибуты это ОО-парадигма? Атрибуты это декларативное программирование. К ОО особого отношения не имеет, но замечательно с ним сочетается.

Я нигде об этом не говорил, наоборот ... я говорю что они не сочетаются c ОО .

C Уважением, Andir!

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

A>Итак атрибуты по своей сути представляют собой некие сущности дополняющие объект

класс

A>информацией о его возможном поведении в различных ситуациях использования этого объекта.

Неверно. Какая это информация не специфицированно. Просто информацией. Точка.

A> Иными словами метаинформация присущая всем экземплярам этого объекта в программе.

Опять неверно. Всем экземплярам присуща информация статических полей. Информация атрибутов присуща классу.

A>теперь с помощью .Net можно создавать свои Атрибуты и дополнять свои объекты новыми свойствами,

Да.

A>а точнее нотификациями как употреблять те или иные свойства объекта.

Нет, уточнение неверное.

A>6) Локальный атрибут — атрибут который явно не оказывает влияние на свойства объекта, но отражает его поведение для некоторого ограниченного числа Других Объектов, которым известно про данный атрибут.

Какой же это тогда локальный атрибут? Это атрибут для самого себя или для своих предков/потомков. Если доступен извне значит глобальный.

A>[i]Сам объект не управляет собой с помощью атрибутов,

Почему нет?

A>по большому счёту, это просто указание внешним объектам программы использовать его в соответсвии с указанными атрибутами,

Неправильно. Это слишком узкое понимание.

Как ты понимаешь, дальнейшие рассуждения построены на неправильных предпосылках.

A>Итак функциональность объекта создана, все свои функции он выполняет так как мне нужно. Теперь я его решил использовать в одной из своих программ, предположим, что программа должна быть защищённой, а значит придётся моему объекту навешивать на себя ещё и атрибуты безопасности, хотя к функциональности объекта эти атрибуты не имеют никакого отношения.

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

[AccessDisk]
[AccessNet]
[AccessDB]
[AccessDBTable("my_table")]

А уж финальный уровень безопасности метода вычисляй сам. А то ты хочешь чтобы атрибуты решили сразу все твои проблемы. А такого не бывает.

A>Приёмы обойти такое великолепие нагромождения атрибутов я уже не раз приводил в этой ветке, но почти все они неприемлемы.

Тебе же сказали — ты неправильно применяешь атрибуты, нельзя их так применять. Приемы обхождения не нужны. Нужно вобще отказаться от атрибутов или использовать их только частично.

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

A>Представляю вам попытку номер два своих рассуждений об атрибутах.

Атрибуты это не религия что-бы о них рассуждать. Есть документация ей и надо следовать. :)

A>Итак атрибуты по своей сути представляют собой некие сущности дополняющие объект информацией о его возможном поведении в различных ситуациях использования этого объекта. Иными словами метаинформация присущая всем экземплярам этого объекта в программе.

Информация присуща классу, а не экземплярам (их в программе может и не быть).

A>Первое знакомство с ними обычно во всех книжках, которые я читал и в MSDN приводится в виде аналогии с ключевыми словами public, private языка C++. Далее говорится, что теперь с помощью .Net можно создавать свои Атрибуты и дополнять свои объекты новыми свойствами, а точнее нотификациями как употреблять те или иные свойства объекта.

Это приводится только для аналогии. Ставить между ними знак равенства нельзя.

A>Для пояснения всего что хочу сказать приведу примеры атрибутов:
A>

A>// Псевдо атрибуты, приведены для пояснения
A>1) [Public]
A>2) [Private]
A>3) [Security(/*Уровень доступа*/)]
A>4) [Serializable]
A>5) [OtherGlobalAttribute]
A>6) [OtherLocalAttribute]
A>7) [MyLocalAttributeUseInThisProgram]
A>

A>1) и 2) глобальные атрибуты аналогичны соответсвующим ключевым словам языка С++ и должны выполнять аналогичную роль. То есть встретив такой атрибут у метода, тот кто хочет выполнить этот метод должен на основании этих атрибутов решить можно ли вызывать этот метод или нет. (Должен присутствовать у методов и классов)
A>3) тоже глобальный атрибут предназначенный для защиты некоторых методов и полей объекта от несанкционированного доступа. (Если объект нуждается в безопасности, то должен присутствовать, иначе может и отсутствовать)
A>4) Уже не столь явно глобальный аттрибут, но всё ещё отражающий некоторые свойства объекта. (Может быть, а может и не быть, но явно влияет на свойства объекта и его поведение в контексте других объектов)

Как Serializable влияет на свойства объекта? На какие свойства он влияет, как?

A>5) В принципе аналогичен 4).
A>6) Локальный атрибут — атрибут который явно не оказывает влияние на свойства объекта, но отражает его поведение для некоторого ограниченного числа Других Объектов, которым известно про данный атрибут.
A>7) Минимальный локальный атрибут, написанный для употребления только в данной программе и отражающий поведение объекта относительно другого объекта, которому про данный атрибут известно.

A>Из вот такого рассмотрения можно я делаю примерно такой вывод:
A>Сам объект не управляет собой с помощью атрибутов, по большому счёту, это просто указание внешним объектам программы использовать его в соответсвии с указанными атрибутами, если внешний объект знаком с ними, иначе undefined behavior.

Естественно. атрибут это принадлежность класса. У объекта атрибутов нет.

A>Теперь о нелогичности применения атрибутов в .Net.
A>Представим, что я проектирую некоторый объект, обладающий какой-то функциональностью, например считает вычисляет некоторое математическое выражение своих полей. Имеет функцию get_Result(), которая возвращает результат. Атрибуты в которых нуждается этот объект, например, что внутренние поля [Private], и заполняются только конструктором, а функция get_Result() доступна извне объекта ([Public]). Если тот кто решит использовать этот объект не станет обращать внимания на эти атрибуты, то соответственно может получить неправильный результат (например, если он кешируется).

Как это не станет обращать внимание? Если метод класса помечен как private, то попытка обращения к нему из вне приведет к compiler error. В данном случае реализация видимости членов класса в .NET выглидит логичной.

A>Итак функциональность объекта создана, все свои функции он выполняет так как мне нужно.

Плохая реализация. Особенно если учесть, что "выполняет функции так как мне нужно". т.е. при использовании объекта сторонним разработчиком получим undefined behavior ("может получить неправильный результат"). И можно сразу сказать, что .NET позволяет писать надежное ПО. В данном случае на лицо проблемы с дизайном со стороны разработчика.

A>Теперь я его решил использовать в одной из своих программ, предположим, что программа должна быть защищённой, а значит придётся моему объекту навешивать на себя ещё и атрибуты безопасности, хотя к функциональности объекта эти атрибуты не имеют никакого отношения.

Толку защищать то, что и так не работает?

A>Дальше мне его нужно сериализовывать по сети и там восстанавливать, естественно, что теперь мне придётся навесить и ещё пару тройку атрибутов для сериализатора, хотя опять же на функциональность объекта они никак не влияют, они влияют, только на то, сможет ли объект после восстановления оказаться идентичным исходному.

Если разговор про XmlSerializer, то он предназначен для сохранения простых объектов. В более сложном случае это решается реализацией интерфейса.

A>Дальше больше ...

Надо было сразу нужный интерфейс реализовать :)

A>Я в этой программе своему объекту решил дать ещё один атрибут [MyObject], чтобы затем использовать где-то для реализации некоторой функциональности ... Больше я нигде этот атрибут и не увижу и не услышу, и никто его использовать не будет, однако объект будет помечен этим атрибутом на всю его долгую жизнь в виде библиотеки ...

Правильно хороший атрибут кашу не испортит.

A>

A>// Псевдо реализация спроектированного объекта в конкретной программе
A>[MyObject]
A>class MathExpression
A>{
A>    [XmlIgnore]
A>    [Security("Nobody")]
A>    [Private]
A>    private int field1;

A>    [Security("Nobody")]
A>    [Private]
A>    private float field2;
A>    
A>    [Security("Administrator")]
A>    [Public]
A>    public MathExpression(int field1, float field2){/*Детали реализации скрыты*/}

A>    [Security("EveryOne")]
A>    [Public]
A>    public int get_Result(){/*Детали реализации скрыты*/}

A>    /*Возможны ещё вспомогательные поля и структуры*/
A>}
A>

A>(Код приведён только для демонстрации).

Не пример а каша какая-то... Для в .NET Framework это в принципе не реализуемо.

A>Для сравнения мне приходит в голову ещё один аналог: Для того, чтобы сериализовывать объект, заводится статический константный массив в котором перечислены поля объекта предназначенные для сериализации + их названия (алиасы) ... Никем кроме как сериализатора этот массив не используется, но в каждом объекте(программе) присутствует ...

а если поля private. А если reflection не работает? пошла нафиг сериализация?

A>Приёмы обойти такое великолепие нагромождения атрибутов я уже не раз приводил в этой ветке, но почти все они неприемлемы.

Какие? Массивы городить?
Опять-таки чем вам дался XmlSerializer в документации ясно написано, что сериализует от только public члены.
Этот класс предявляет к объекту некоторые требования ( кого-нибудь удивляет необходимость поддержки ISerializable для сохранения объектов? ).

Получается что дали новый механизм (атрибуты) и теперь его надо вставлять куда попало?

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

[skip]

A>>информацией о его возможном поведении в различных ситуациях использования этого объекта.

AVK>Неверно. Какая это информация не специфицированно. Просто информацией. Точка.

Для чего нужна тогда эта информация? Известно ли объекту класса для чего он содержит эту информацию?

A>> Иными словами метаинформация присущая всем экземплярам этого объекта в программе.

AVK>Опять неверно. Всем экземплярам присуща информация статических полей. Информация атрибутов присуща классу.

Неправильно выразился -> имелось ввиду объекту класса в программе.


A>>6) Локальный атрибут — атрибут который явно не оказывает влияние на свойства объекта, но отражает его поведение для некоторого ограниченного числа Других Объектов, которым известно про данный атрибут.

AVK>Какой же это тогда локальный атрибут? Это атрибут для самого себя или для своих предков/потомков. Если доступен извне значит глобальный.

А есть атрибуты не доступные извне? Я имел ввиду, локальность атрибута в том смысле, что о нём ограниченное число типов.

A>>[i]Сам объект не управляет собой с помощью атрибутов,

AVK>Почему нет?

Как? Пример?
Хотя я наверно догадываюсь, но здесь по-моему уместнее статические данные.

A>>по большому счёту, это просто указание внешним объектам программы использовать его в соответсвии с указанными атрибутами,

AVK>Неправильно. Это слишком узкое понимание.

Как будет шире? Хочу достучаться до правды ...

AVK>Как ты понимаешь, дальнейшие рассуждения построены на неправильных предпосылках.

Ну ладно, вначале разберёмся с предпосылками ...

A>>Итак функциональность объекта создана, все свои функции он выполняет так как мне нужно. Теперь я его решил использовать в одной из своих программ, предположим, что программа должна быть защищённой, а значит придётся моему объекту навешивать на себя ещё и атрибуты безопасности, хотя к функциональности объекта эти атрибуты не имеют никакого отношения.

AVK>А теперь объясни пожалуйста — кто определяет — можно ли дать доступ к этому объекту или нет? Наверное все же объект.
AVK>Пойми простую вещь — атрибуты не реализуют безопасность, они лишь предоставляют дополнительную информацию для этого. Не устраивает явное указание уровня доступа? Так не указывай. На основании чего ты будешь вычислять текущий уровень безопасности? На основании доступа метода к внешним объектам? Ну тогда так и описывай в атрибутах куда он лезет.

Наверное всё же объект ... Жаль что это не имеет отношения к функционированию объекта, а только к безопасности его исполнения и работы ... Однако информацию, которая будет использоваться только в текущей программе мы всё же в объект запишем ... хотя в другой мы легко сможем эту информацию игнорировать ... А?
Плюс добавить ещё немного другой характерной для нового контекста исполнения.

AVK>[AccessDisk]
AVK>[AccessNet]
AVK>[AccessDB]
AVK>[AccessDBTable("my_table")]

AVK>А уж финальный уровень безопасности метода вычисляй сам. А то ты хочешь чтобы атрибуты решили сразу все твои проблемы. А такого не бывает.

Да я хочу чтобы атрибуты выполняли роль информации об объекте, а не служили для демонстрации навороченности объекта. В общем случае я легко обойдусь без атрибутов, как привык уже, но всё же хотелось бы найти им приемлемое применение раз уж они есть в средстве, которое я использую. Может они принесут довольно много пользы, пока же перед каждым атрибутом (ну кроме простейших) я хорошенько задумываюсь ... а нужен ли он здесь и не обойдётся ли его применение намного дороже собственной реализации.

A>>Приёмы обойти такое великолепие нагромождения атрибутов я уже не раз приводил в этой ветке, но почти все они неприемлемы.

AVK>Тебе же сказали — ты неправильно применяешь атрибуты, нельзя их так применять. Приемы обхождения не нужны. Нужно вобще отказаться от атрибутов или использовать их только частично.

Прекрасно, не получается правильно применять атрибуты, забудь про них нафиг .

С Уважением, Andir!

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

[skip]

A>>Представляю вам попытку номер два своих рассуждений об атрибутах.

TK>Атрибуты это не религия что-бы о них рассуждать. Есть документация ей и надо следовать.

Следовать то можно, но у меня пока только какая-то каша получается ...

A>>Итак атрибуты по своей сути представляют собой некие сущности дополняющие объект информацией о его возможном поведении в различных ситуациях использования этого объекта. Иными словами метаинформация присущая всем экземплярам этого объекта в программе.

TK>Информация присуща классу, а не экземплярам (их в программе может и не быть).

обшибся, речь про объект класса.

A>>Первое знакомство с ними обычно во всех книжках, которые я читал и в MSDN приводится в виде аналогии с ключевыми словами public, private языка C++. Далее говорится, что теперь с помощью .Net можно создавать свои Атрибуты и дополнять свои объекты новыми свойствами, а точнее нотификациями как употреблять те или иные свойства объекта.

TK>Это приводится только для аналогии. Ставить между ними знак равенства нельзя.

Совсем? Разве атрибуты не являются расширением этого типа "атрибутов" С++ ?

[skip]

A>>4) Уже не столь явно глобальный аттрибут, но всё ещё отражающий некоторые свойства объекта. (Может быть, а может и не быть, но явно влияет на свойства объекта и его поведение в контексте других объектов)

TK>Как Serializable влияет на свойства объекта? На какие свойства он влияет, как?

Для того, чтобы объект с таким атрибутом мог функционировать, его свойства должны быть реализованы так, чтобы их можно было подвергать сериализации. Где-то так.

A>>Из вот такого рассмотрения можно я делаю примерно такой вывод:
A>>Сам объект не управляет собой с помощью атрибутов, по большому счёту, это просто указание внешним объектам программы использовать его в соответсвии с указанными атрибутами, если внешний объект знаком с ними, иначе undefined behavior.

TK>Естественно. атрибут это принадлежность класса. У объекта атрибутов нет.
Речь опять про объекты класса, статические сущности.

A>>Представим, что я проектирую некоторый объект, обладающий какой-то функциональностью, например считает вычисляет некоторое математическое выражение своих полей. Имеет функцию get_Result(), которая возвращает результат. Атрибуты в которых нуждается этот объект, например, что внутренние поля [Private], и заполняются только конструктором, а функция get_Result() доступна извне объекта ([Public]). Если тот кто решит использовать этот объект не станет обращать внимания на эти атрибуты, то соответственно может получить неправильный результат (например, если он кешируется).

TK>Как это не станет обращать внимание? Если метод класса помечен как private, то попытка обращения к нему из вне приведет к compiler error. В данном случае реализация видимости членов класса в .NET выглидит логичной.

Разве compiler error это результат того, что поле имеет атрибут [Private]?

A>>Итак функциональность объекта создана, все свои функции он выполняет так как мне нужно.

TK>Плохая реализация. Особенно если учесть, что "выполняет функции так как мне нужно". т.е. при использовании объекта сторонним разработчиком получим undefined behavior ("может получить неправильный результат"). И можно сразу сказать, что .NET позволяет писать надежное ПО. В данном случае на лицо проблемы с дизайном со стороны разработчика.

Неадекватная какая-то реакция, написав какой-то объект я его, наверно, сперва задокументирую, описав какие ситуации могут привести к undefined behavior и как этого избежать (точнее чего не нужно делать, а что обязательно). Я про то и сказал, что здесь все кто используют этот объект обязаны смотреть на атрибуты [Public] и [Private].

[skip безаргументированные тирады]

A>>Дальше больше ...

TK>Надо было сразу нужный интерфейс реализовать

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

A>>Я в этой программе своему объекту решил дать ещё один атрибут [MyObject], чтобы затем использовать где-то для реализации некоторой функциональности ... Больше я нигде этот атрибут и не увижу и не услышу, и никто его использовать не будет, однако объект будет помечен этим атрибутом на всю его долгую жизнь в виде библиотеки ...

TK>Правильно хороший атрибут кашу не испортит.

Поэтому к объекту в рантайм не помешает ещё засунуть довольно хорошую документацию и свой framework безопасности, сериализации и т.д.

TK>Не пример а каша какая-то... Для в .NET Framework это в принципе не реализуемо.

Ничего нормального и маленького в голову не пришло

A>>Для сравнения мне приходит в голову ещё один аналог: Для того, чтобы сериализовывать объект, заводится статический константный массив в котором перечислены поля объекта предназначенные для сериализации + их названия (алиасы) ... Никем кроме как сериализатора этот массив не используется, но в каждом объекте(программе) присутствует ...

TK>а если поля private. А если reflection не работает? пошла нафиг сериализация?

Правильно, Своя реализация требуется ...

TK>Получается что дали новый механизм (атрибуты) и теперь его надо вставлять куда попало?

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

С Уважением, Andir!

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


A>Совсем? Разве атрибуты не являются расширением этого типа "атрибутов" С++ ?

Нет. Модишикаторы доступа сами по себе. Атрибуты сами. Они похожи, но и разница огромна.

TK>>Как Serializable влияет на свойства объекта? На какие свойства он влияет, как?

A>Для того, чтобы объект с таким атрибутом мог функционировать, его свойства должны быть реализованы так, чтобы их можно было подвергать сериализации. Где-то так.

Да, но сам атрибут Serializable это просто декларация.

A>>>Из вот такого рассмотрения можно я делаю примерно такой вывод:
A>>>Сам объект не управляет собой с помощью атрибутов, по большому счёту, это просто указание внешним объектам программы использовать его в соответсвии с указанными атрибутами, если внешний объект знаком с ними, иначе undefined behavior.

Не обязательно. атрибут AutoComplete относится к поведению объекта. ProxyAttribute тоже.

TK>>Как это не станет обращать внимание? Если метод класса помечен как private, то попытка обращения к нему из вне приведет к compiler error. В данном случае реализация видимости членов класса в .NET выглидит логичной.

A>Разве compiler error это результат того, что поле имеет атрибут [Private]?

Естественно, что атрибут Private не приведет к compiler error (для c#). В данном случае Private это пример не целевого использования атрибутов.

A>Неадекватная какая-то реакция, написав какой-то объект я его, наверно, сперва задокументирую, описав какие ситуации могут привести к undefined behavior и как этого избежать (точнее чего не нужно делать, а что обязательно). Я про то и сказал, что здесь все кто используют этот объект обязаны смотреть на атрибуты [Public] и [Private].

Что-же очень удобная реализация.

TK>>Надо было сразу нужный интерфейс реализовать :)

A>К такому решению я прихожу практически при использовании любого атрибута, если не знаю точно как далее мой объект будет использоваться.

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

A>Ничего нормального и маленького в голову не пришло :(

Жаль.

A>>>Для сравнения мне приходит в голову ещё один аналог: Для того, чтобы сериализовывать объект, заводится статический константный массив в котором перечислены поля объекта предназначенные для сериализации + их названия (алиасы) ... Никем кроме как сериализатора этот массив не используется, но в каждом объекте(программе) присутствует ...

TK>>а если поля private. А если reflection не работает? пошла нафиг сериализация?

A>Правильно, Своя реализация требуется ...

Не своя, а разумный подход к использованию существующих механизмов. зачем рассматривать надуманные примеры.
Если есть вопросы о том, как нужно реализовывать|использовать то, что есть то лучше об этом прямо и спросить.

TK>>Получается что дали новый механизм (атрибуты) и теперь его надо вставлять куда попало?

A>Тогда нужно бы послать меня туда где бы неплохо объяснилось, где атрибуты действительно дают, то что они должны давать (уменьшение сложности, более правильное выражение абстракций и т.д.). :crash:

1. Использование атрибутов в AOP подходе дает более простую реализацию, наглядность и т.п.
2. Использование декларативной безопасности дает уменьшение сложности.
3. Описательные атрибуты дают дополнительную информацию об объекте и позволяют судить в каких ситуациях и как его можно использовать (например атрибуты описывающие работу с объектом в Design time`е).

A>Пока мне это всё видется только увеличением оверкодинга для объекта и слишком большой привязкой объекта и программы которая его использует.

Если есть реальная программа, то может разобрать ее? А то с надуманными примерами плохо получается :)

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

Аттрибуты — сами по себе вспомогательные сущности.

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

Так если у тебя есть Serializator, то он должен не напрямую обращаться к сериализуемому классу, а получат данные для сериализации через интерфейс или хелперский класс.

А уже внутри этого интерфейса или хелперского класса ты будешь бегать по классу и смотреть у полей аттрибуты.

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

AVK>>Неверно. Какая это информация не специфицированно. Просто информацией. Точка.

A>Для чего нужна тогда эта информация?

Для расширения штатных метаданных класса.

A>Известно ли объекту класса для чего он содержит эту информацию?

Что значит "известно объекту класса"?

A>>> Иными словами метаинформация присущая всем экземплярам этого объекта в программе.
AVK>>Опять неверно. Всем экземплярам присуща информация статических полей. Информация атрибутов присуща классу.

A>Неправильно выразился -> имелось ввиду объекту класса в программе.

И так неверно. Метаданные присущи сгенерированному коду. Если атрибут применен к сборке — о каком классе вобще может идти речь?


A>>>[i]Сам объект не управляет собой с помощью атрибутов,
AVK>>Почему нет?
A>Как? Пример?

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

A>>>по большому счёту, это просто указание внешним объектам программы использовать его в соответсвии с указанными атрибутами,

AVK>>Неправильно. Это слишком узкое понимание.

A>Как будет шире? Хочу достучаться до правды ...

Шире будет — атрибуты это возможность расширять метаданные кода. Все.

A>Наверное всё же объект ... Жаль что это не имеет отношения к функционированию объекта, а только к безопасности его исполнения и работы ... Однако информацию, которая будет использоваться только в текущей программе мы всё же в объект запишем ...

Нельзя записывать в атрибуты классов библиотеки информацию, которая только текущей программе нужна. Это равносильно тому что ты будешь добавлять в библиотечный класс методы, которые нужны только в текущей программе. Только это тебя почему то не удивляет, зато удивляет что подобное же свойство имеют атрибуты. Атрибуты это такие же метаданные как и методы и являются неотемлемой частью метаданных класса, сборки и т.д. Т.е. они присущи только и исключительно классу или сборке, в котором они присутствуют и являют собой неотемлемые свойства этоко класса или сборки. Заметь — класса или сборки, а не объекта класса или экземпляра класса. Ты это никак понять не хочешь.

AVK>>А уж финальный уровень безопасности метода вычисляй сам. А то ты хочешь чтобы атрибуты решили сразу все твои проблемы. А такого не бывает.

A>Да я хочу чтобы атрибуты выполняли роль информации об объекте, а не служили для демонстрации навороченности объекта.

Ну так мало ли что ты хочешь. Атрибуты для этого не предназначены.

A>но всё же хотелось бы найти им приемлемое применение раз уж они есть в средстве, которое я использую.

Посмотри в каких случаях атрибуты применяются в фреймворке, янусе.

A> Может они принесут довольно много пользы, пока же перед каждым атрибутом (ну кроме простейших) я хорошенько задумываюсь ... а нужен ли он здесь и не обойдётся ли его применение намного дороже собственной реализации.

Если тебе нужна неизменяемая информация, присущая только коду то в этом случае можешь смело применять атрибуты. О, еще одна аналогия которая можете тебе помочь — атрибуты это как бы ресурсы, привязанные к сущностям внутри программы. Тебя ведь не удивляет невозможность менять ресурсы? Так почему удивляет невозможность менять атрибуты?
МС предлагает представлять атрибуты как экземпляры классов, создаваемые при компиляции и сериализуемые в генерируемый код в нужное место.

A>Прекрасно, не получается правильно применять атрибуты, забудь про них нафиг .

Ну коль не получается, то лучше забудь до лучших времен. Дизайн в котором изменяемые данные храняться в атрибутах никуда не годится.

Почти полностью согласен со всем изложенным. Несоответствий действительно много, и связаны они все же не с неправильным использованием. Если любое использование оказывается неправильным, то "что-то надо подправить в консерватории".

A>Итак атрибуты по своей сути представляют собой некие сущности дополняющие объект информацией о его возможном поведении в различных ситуациях использования этого объекта. Иными словами метаинформация присущая всем экземплярам этого объекта в программе.

Если подходить к аттрибутам как к указаниям "о его [объекта] возможном поведении в различных ситуациях использования", акцентируя на "возможном" и "в различных", то действительно получается слишком много аттрибутов, портящих инкапсуляцию.

A>Первое знакомство с ними обычно во всех книжках, которые я читал и в MSDN приводится в виде аналогии с ключевыми словами public, private языка C++. Далее говорится, что теперь с помощью .Net можно создавать свои Атрибуты и дополнять свои объекты новыми свойствами, а точнее нотификациями как употреблять те или иные свойства объекта.

Что я думаю. Аттрибуты неотделимы от .Net не только в том плане, что в другом месте они работать не будут, а в том плане, что они целиком ориентированы на .Net и без них уже она работать не станет. Хочу сказать, что это не столько идеология, сколько просто инструмент. И в этом нет ничего унизительного для них. Совершенно понятно нежелание разработчиков .Net вводить множество новых ключевых слов, тем более сразу во все языки. Никто бы их не понял. Это раз. Во вторых: использовать операторы, вроде typeof или dynamic_cast, подсвечивающиеся "сининьким", для нужд GC и сериализации очень неудобно и глупо. Ну почему язык, оперирующий классами, должен содержать в себе странные операторы с несколькими параметрами и общими префиксами.
к примеру:

singlethread method void Foo(in A, out B)
{
...
if (is_serializable(A))
{
  for(int i = 0; i < get_field_numbers(A)); i++)
    if(is_serializable(get_field(A,i))
       B.Buffer << get_field(A,i);
}
else
...
}

Такой вот код...
Не то, чтобы это было очень уж отвратительно (а оно так и есть), но использование классов для отражения внутренних сущностей системы намного приятнее, хотя и странно выглядит, особенно если есть доступ к их исходникам на том же языке (С#).

Сложный аттрибут становится нереальным выразить в виде одного слова, вроде "public". Нужен класс.
Эти соображения примитивны, но мне кажется, что так дело и обстоит. Аттрибут позволяет выразить такую дополнительную информацию о классе или поле, которую невозможно или сложно представить непосредственно в терминах языка. И созданы оны для среды исполнения, а не для самого объекта. Для компилятора, для загрузчика, для программы пользователя, в которой этот класс будет использоваться, и не может быть вырван из их лап без приключений. В конечном счете, аттрибуты нетранспортабельны. Они усиливают зависимости, портят инкапсуляцию, используют reflections и создают другие отклонения от чистого ООП единственно во благо программиста.

У аттрибутов действительно есть недостатки, произрастающие, как мне кажется, именно из-за того, что они не расширяют ООП, а синтаксически постулируют то, что уже давно используется (вроде свойств, которые и без того реализовывались через getField & setField). Если я не ошибаюсь, то прямыми методами нельзя добавить аттрибут к полю родителя в дочернем классе. Нельзя переопределеить аттрибут родителя. И это тоже проблемы, скорее синтаксиса, чем функционирования.


Почти все, все я здесь написал, уже сказали TK и AndrewVK. Они же приводили доводы к тому, чтобы не использовать аттрибуты там, где их применение не оправдано . Здесь мне их логика не ясна. Если средство не стоит применять там, где ему место, потому, что это некрасиво и усложняет вопрос, но ничего в корне другого применить нельзя, то что делать? Я не говорю, что невозможно иначе хранить и получать доступ к дополнительной информации. Ведь сами аттрибуты, неважно как, но реализованы! Я говорю, что обходной путь будет делать не только то же самое, но и тем же способом. За той единственной разницей, что информация о наличии аттрибута будет находиться не рядом с классом/полем, а в другом месте, что, вообще говоря, не хорошо и запутывает код.

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

Вроде все.

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

P>Почти полностью согласен со всем изложенным. Несоответствий действительно много, и связаны они все же не с неправильным использованием. Если любое использование оказывается неправильным, то "что-то надо подправить в консерватории".

Жаль. Мне казалось что я разжевал очень понятно.

P>И созданы оны для среды исполнения, а не для самого объекта. Для компилятора,

Забавно. А что же тогда называть временем компиляции, если копилятор стал средой исполнения?

P> В конечном счете, аттрибуты нетранспортабельны. Они усиливают зависимости, портят инкапсуляцию, используют reflections и создают другие отклонения от чистого ООП единственно во благо программиста.

Задумайся над таким фактом — чистоту языка Java блюдут очень сильно, но в следующей версии туда планируется атрибуты добавить. Теми самыми маньяками, которые заставляют явно прописывать возможно генерируемые исключения и не вводят свойства именно из за того чтобы не нарушать эти самые концепции.

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

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

P> Нельзя переопределеить аттрибут родителя.

А это при желании все таки можно. Только механизм переопределений придется реализорвать самому.

P>Здесь мне их логика не ясна. Если средство не стоит применять там, где ему место, потому, что это некрасиво

А кто сказал что там ему место? Нет, нельзя применять потому что там ему не место. Вы почему то упорно пытаетесь представлять атрибут как свойство экземпляров класса. Это ни в коем случае не так. Атрибут это свойство кода. Изменение атрибута равносильно изменению кода. Часто необходимо менять в процессе работы код?


P>Применение аттрибута и правда портит класс, т.к. он становится тяжело переносим (нужно везде вырезать аттрибут)

Зачем нужно? Только ты не сразу отвечай, а сперва подумай.

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

A>Давненько меня мучает вопрос о небольшой нелогичности аттрибутов и ООП.

Давненько хотел влезть в вашу дискуссию, но почему-то робел.

ИМВХО, атрибуты в .НЕТ — это явление "отраженного" света некоторых служб (или подсистем), когда эта служба (или подсистема) работает с объектами приложения единообразно, опираясь на метаданные. Она сама атрибуты не навешивает, а только производит их чтение. Причем это делается в рамках класса объектов, потому как метаданные хранятся для всего класса.

Чтобы подстроить эту службу (или подсистему) под себя, класс (с ним вместе и проектировщик этого класса) должен установить атрибуты как дополнение к метаданным именно для этой службы (подсистемы). Должен "отразить" отсвет этой службы (подсистемы).

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

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

А потому атрибут где-либо в классе определяется не самим классом или его функциональностью, как в случае методов и свойств, а чем-то внешним по отношению к классу. Класс может только использовать или не использовать атрибут, но введение атрибута — это прерогатива внешней службы (или подсистемы), услугами которой намеревается воспользоваться этот класс.

ИМВХО, не стоит думать, что, вводя и применяя свои атрибуты, класс может изменить поведение некоей службы (подсистемы). Особенно такой глобальной, как предоставляемой самой Микрософт. Только своей локальной.

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

A>Я нигде об этом не говорил, наоборот ... я говорю что они не сочетаются c ОО .

Они прекрасно сочетаются с ОО. Впрочем как и другие (например, структурное программирование). Одно другое не отменяет. Иногда удобнее решать проблему в ОО-стиле, иногда в декларативном.

Надо воспринимать атрибуты как дополнительную информацию о типе, а не как заменую ОО-механизмам. Часто пробему можно решить и декларативно и в ОО-стиле. Какой способ предпочтительнее нужно определять в каждом конкретном случае.

Декларативный подход резко уменьшает количество ошибок. Он так же доступен внешним утилитам. Причем им не придется создвать экземпляры классов и т.п. Хорошим примером использования атрибутов является регистрация COM+-объектов. Программист может задать нужную информацию не лазяя по диалогам и меню визуальной утилиты, а задав необходимые атрибуты. Причем остается возможность изменить настройки визуельно.

Или предположим та же сериализация. Если нужно смапить структуру на таблицу БД, то могут возникнуть пробемы. Типы данных SQL не совпадают с типами языка. Атрибуты в этом случае могут дать подсказку парсеру какой конкретный тип БД использовать для поля.

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

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

A>>Я нигде об этом не говорил, наоборот ... я говорю что они не сочетаются c ОО .

VD>Они прекрасно сочетаются с ОО. Впрочем как и другие (например, структурное программирование). Одно другое не отменяет. Иногда удобнее решать проблему в ОО-стиле, иногда в декларативном.

Слишком ...
Я не вижу приемлимого способа их сочетать, дело в том, что если проблему решаешь в ОО парадигме, то (мне например) намного удобнее её решать всё таки в рамках этой парадигмы, не разбавляя её некоторыми новинками, неприемлимыми в этих рамках. Я понимаю, что отличия Структурного программирования и ОО — это отличия только характера представления тех или иных сущностей (абстракций), при этом ни один из способов не является лидирующим в той или иной области, но попытка смешать эти стили приведёт скорее к полному краху, хотя, безусловно, сделать это можно, но выглядеть это всё будет как замешанный бетон с древесиной ... Так вот с декларативным программированием примерно та же фигня, используя одну парадигму я не могу приемлимо вместить в неё атрибуты, ибо не получается сделать это с полным соответствием оной, а нарушения влекут за собой нелогичность и далее за собой показывают возможность возникновения и иных проблем, и уровень абстрагирования уменьшается в несколько раз, так как вместо того, чтобы описать объект, описываю его применение в конкретной программе.

VD>Надо воспринимать атрибуты как дополнительную информацию о типе, а не как заменую ОО-механизмам. Часто пробему можно решить и декларативно и в ОО-стиле. Какой способ предпочтительнее нужно определять в каждом конкретном случае.

.Net попыталась совместить оба этих способа, отсюда и проблемы.

VD>Декларативный подход резко уменьшает количество ошибок. Он так же доступен внешним утилитам. Причем им не придется создвать экземпляры классов и т.п. Хорошим примером использования атрибутов является регистрация COM+-объектов. Программист может задать нужную информацию не лазяя по диалогам и меню визуальной утилиты, а задав необходимые атрибуты. Причем остается возможность изменить настройки визуельно.

С Com+ знаком только поверхностно, особенно в .Net ... Я абсолютно согласен, что атрибуты облегчают программирование, но насколько они облегчают одно настолько утяжеляют другое ... и не видно способа, который бы мог привести всё это к сочетабельности .

VD>Или предположим та же сериализация. Если нужно смапить структуру на таблицу БД, то могут возникнуть пробемы. Типы данных SQL не совпадают с типами языка. Атрибуты в этом случае могут дать подсказку парсеру какой конкретный тип БД использовать для поля.

Даже этот пример выглядит некорректно, насколько лучше выглядит всё таки, если Парсер всё таки будет ознакомлен с типами соостветствий данных языка и данных SQL, и будет сам решать, что и где использовать, иначе остальную информацию должен будет рассказать объект ... но и тут неприемлимо использование атрибутов, особенно если парсер кроме Sql использует и иные языки общения с СУБД (свои внутренние), не использовать же кучу атрибутов на все случаи жизни ...
Атрибуты (во многих случаях) вешают на объект функциональность, которой он не должен обладать, или, по крайней мере, обеспечивать. Делают сильную привязку к тем или иным объектам, используются только в конкретной программе (я не говорю о глобальных атрибута типа Security), сильно нарушают уровень абстракции.

С Уважением, Andir!

Ты не прав.
Атрибуты ничего не говорят про объекты. Они говорят про классы. Точка. Они не вешают на объект никакую функциональность.
Я не понимаю, каким образом они нарушают уровень абстракции. Я согласен с тем, что можно применить их совершенно противоестественным образом. Я не понимаю, зачем.
Атрибуты, используемые только в данной программе — архитектурный бред. Они должны позволять передать в 3rd-party библиотеку дополнительную информацию о сущностях, разработанных после ее компиляции. В конкретной программе все классы известны на стадии компиляции. Вся информация уже есть, и не нужно приседаний для ее передачи.

В Delphi разработчик компонентов вызывал функцию VCL RegisterComponent, чтобы среда узнала о его трудах. Совсем не для того, чтобы обеспечить какую-то полезную функциональность в рантайме! Эта функция не является частью "конкретной программы". С точки зрения .net это несовершенное процедурное выражение декларативных концепций типа "этот класс суть компонент".

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

S>Ты не прав.

Давай по-конкретнее, ладно?

S>Атрибуты ничего не говорят про объекты. Они говорят про классы. Точка. Они не вешают на объект никакую функциональность.

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

S>Я не понимаю, каким образом они нарушают уровень абстракции.

Привязывают один объект к тем условиям в которых он работает.

S>Атрибуты, используемые только в данной программе — архитектурный бред. Они должны позволять передать в 3rd-party библиотеку дополнительную информацию о сущностях, разработанных после ее компиляции. В конкретной программе все классы известны на стадии компиляции. Вся информация уже есть, и не нужно приседаний для ее передачи.

Пример в студию, где атрибуты используются во всех программах, где используется данный объект; кроме как атрибутов используемых самим объектом для себя же я таких атрибутов не знаю, но это ещё больший архитектурный бред.

S>В Delphi разработчик компонентов вызывал функцию VCL RegisterComponent, чтобы среда узнала о его трудах. Совсем не для того, чтобы обеспечить какую-то полезную функциональность в рантайме! Эта функция не является частью "конкретной программы". С точки зрения .net это несовершенное процедурное выражение декларативных концепций типа "этот класс суть компонент".

Не уверен, что правильно понимаю. Но насколько я понял ты говоришь о несовершенной абстракции "регистратор компонента" в визуальной среде, более правильным было бы для регистрации компонента, реализовать класс, который бы своим способом регистрировал бы компонент в визуальной среде (например реализовывая интерфейс IRegisterObject). И что? Здесь как раз с точки зрения абстракций всё правильно и удобно, на объект не вешается никаких дополнительных функциональностей, а теперь представим, что для того чтобы реализовать регистрацию приходилось бы вызывать статическую функцию RegisterComponent, которая должна была бы быть в каждом компоненте, бред ... Или написать атрибут компоненту [ThisIsVisualComponentForDelphi] ... Принцип именно такой.

С Уважением, Andir!

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

[skip]

A>>Для чего нужна тогда эта информация?

AVK>Для расширения штатных метаданных класса.

Я не имею ввиду способ кодинга и представления. Ну расширяют они эту информацию и что ... документация тоже в принципе расширяет метаданные класса, но не используется ведь другими объектами ...
Ставлю вопрос так: Зачем нужна эта информация объекту, если он её не использует? И какое ограничение в таких расширениях метаданных, где нужно остановится, а где нужно ещё добавить?

A>>Известно ли объекту класса для чего он содержит эту информацию?

AVK>Что значит "известно объекту класса"?

Управляет ли он своим поведением с помощью этой информации? Если да, то как ...

A>>>> Иными словами метаинформация присущая всем экземплярам этого объекта в программе.
AVK>>>Опять неверно. Всем экземплярам присуща информация статических полей. Информация атрибутов присуща классу.

A>>Неправильно выразился -> имелось ввиду объекту класса в программе.

AVK>И так неверно. Метаданные присущи сгенерированному коду. Если атрибут применен к сборке — о каком классе вобще может идти речь?

Странная вообще говоря, ты говоришь, что метаданные присущи только сгенерированному коду, а отношения к объектам не имеют ... глупый вопрос наверно, но зачем они тогда нужны в программе? По твоему получается, что они нужны, только чтобы из куска кода можно было получить некоторую информацию о том какую роль этот коды выполняет, а в большинстве случаев это будет сводится к простой документации кода, например так [Programmer("Вася Пупкин"), Date("12.01.2003")] ...

Шире посмотри, я не про кодинг и не про бинарный формат экзешников ...

A>>>>[i]Сам объект не управляет собой с помощью атрибутов,
AVK>>>Почему нет?
A>>Как? Пример?
AVK>Ну например можно разметить атрибутами методы класса, и в каком нибудь диспетчере не явно прописать вызов метода, а вызвать его в соответствии с атрибутом.

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

A>>>>по большому счёту, это просто указание внешним объектам программы использовать его в соответсвии с указанными атрибутами,

AVK>>>Неправильно. Это слишком узкое понимание.

A>>Как будет шире? Хочу достучаться до правды ...

AVK>Шире будет — атрибуты это возможность расширять метаданные кода. Все.

Зачем? Документирование кода — тоже расширение метаданных кода. Заполнение нулевыми байтиками бинарников для выравнивания по параграфам — тоже расширение метаданных ...

A>>Наверное всё же объект ... Жаль что это не имеет отношения к функционированию объекта, а только к безопасности его исполнения и работы ... Однако информацию, которая будет использоваться только в текущей программе мы всё же в объект запишем ...

AVK>Атрибуты это такие же метаданные как и методы и являются неотемлемой частью метаданных класса, сборки и т.д. Т.е. они присущи только и исключительно классу или сборке, в котором они присутствуют и являют собой неотемлемые свойства этоко класса или сборки. Заметь — класса или сборки, а не объекта класса или экземпляра класса. Ты это никак понять не хочешь.

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

int myIntegerNumber=17; // Угадай с трёх раз почему там 17

[MyAttribute(false)];   // И почему здесь false и почему здесь MyAttribute ...
class MyClass {/* Мой объект */};

A>>Да я хочу чтобы атрибуты выполняли роль информации об объекте, а не служили для демонстрации навороченности объекта.

AVK>Ну так мало ли что ты хочешь. Атрибуты для этого не предназначены.

Супер! Здесь не хватает фразы "AVK> Для расширения метаданных кода.". Всё я просто в ауте, теперь я действительно не понимаю зачем нужны атрибуты.

A>>но всё же хотелось бы найти им приемлемое применение раз уж они есть в средстве, которое я использую.

AVK>Посмотри в каких случаях атрибуты применяются в фреймворке, янусе.

Видел, конфиги трогать не буду, а более нигде хорошего применения в Янусе я не видел. Там такой монолит сейчас уже сложился, что я только двумя руками за Janus2. В фреймворк не лазил давненько, но тоже не припоминаю там корректного применения атрибутов, а может просто глубоко не влез.

A>> Может они принесут довольно много пользы, пока же перед каждым атрибутом (ну кроме простейших) я хорошенько задумываюсь ... а нужен ли он здесь и не обойдётся ли его применение намного дороже собственной реализации.

AVK>Если тебе нужна неизменяемая информация, присущая только коду то в этом случае можешь смело применять атрибуты. О, еще одна аналогия которая можете тебе помочь — атрибуты это как бы ресурсы, привязанные к сущностям внутри программы. Тебя ведь не удивляет невозможность менять ресурсы? Так почему удивляет невозможность менять атрибуты?
AVK>МС предлагает представлять атрибуты как экземпляры классов, создаваемые при компиляции и сериализуемые в генерируемый код в нужное место.

Хорошая аналогия, за это и оценку поставить не грех! Так я и говорю о том, что они тогда просто применяются неправильно, зачем они приписываются тогда к классам и методам/полям, сборкам ... Я же говорю, что они не в том месте выставляются для объектов, насколько лучше было бы делать вот так:

// Сборка с объектом
class MyObject
{   
   private int field;    
/* Остальные данные класса*/
};

// Новая сборка, например основная для программы
declare class MyObject /*for А здесь например указать для каких конкретных типов доступны данные аттрибуты */
{
  [XmlIgnore]
  [Default(17)]
  private int field; 
  /* Остальные данные класса*/
}

Понимаю, что оверкодинг наблюдается, зато сохраняется абстракция объекта как класса.

AVK>Ну коль не получается, то лучше забудь до лучших времен. Дизайн в котором изменяемые данные храняться в атрибутах никуда не годится.

А неизменяемые данные для объектов, годятся только в качестве документации.

С Уважением, Andir!

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

DG>Аттрибуты — сами по себе вспомогательные сущности.

DG>Сторонние объекты не должны напрямую работать с аттрибутами.
DG>С аттрибутами должен работать либо сам класс, либо вспомогательные классы для данного класса.

Если я правильно тебя понял, то получается с твоей точки зрения атрибуты не должны быть видны "внешним" объектам для данного объекта, кроме тех кто напрямую связан с объектом и без него объект теряет свою функциональность. Тогда не понятно почему атрибуты — это глобальные метаданные, а не локализованные областью видимости.

DG>Так если у тебя есть Serializator, то он должен не напрямую обращаться к сериализуемому классу, а получат данные для сериализации через интерфейс или хелперский класс.

Это и так понятно, не понятно тогда из каких соображений созданы XmlIgnoreAttribute и ему подобные в стандартной библиотеке.

DG>А уже внутри этого интерфейса или хелперского класса ты будешь бегать по классу и смотреть у полей аттрибуты.

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

С Уважением, Andir!

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

A>>>Для чего нужна тогда эта информация?

AVK>>Для расширения штатных метаданных класса.

A>Я не имею ввиду способ кодинга и представления.

Это не способ кодинга и представления, это их сущность.

A>Ставлю вопрос так: Зачем нужна эта информация объекту, если он её не использует?

Затем чтобы ее использовать. Для чего — не определено. Для чего удобно — для того и используют.

AVK>>Что значит "известно объекту класса"?

A>Управляет ли он своим поведением с помощью этой информации? Если да, то как ...

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

A>>>Неправильно выразился -> имелось ввиду объекту класса в программе.

AVK>>И так неверно. Метаданные присущи сгенерированному коду. Если атрибут применен к сборке — о каком классе вобще может идти речь?

A>Странная вообще говоря, ты говоришь, что метаданные присущи только сгенерированному коду, а отношения к объектам не имеют ...

К объектам? Не имеют. Они только связаны с сборкой, классом, методом, параметром.

A> глупый вопрос наверно, но зачем они тогда нужны в программе? По твоему получается, что они нужны, только чтобы из куска кода можно было получить некоторую информацию о том какую роль этот коды выполняет,

Опять ты пытаешься сузить определение. Просто информацию. Любую. Не важно какую, никаких ограничений на это нет.

A>а в большинстве случаев это будет сводится к простой документации кода, например так [Programmer("Вася Пупкин"), Date("12.01.2003")] ...

Непонятно из чего ты сделал такой вывод.


A>Шире посмотри, я не про кодинг и не про бинарный формат экзешников ...

Это ты шире посмотри. Ты все пытаешься добиться чтобы тебе сказали что атрибуты нужны чтобы сделать то и то. Ты попробуй сказать для чего нужен класс. Как его использовать? Что, тяжело? А чем атрибуты лучше? Это элемент платформы. А уж как его использовать нигде не определено.
Так что я не про кодинг и бинарный формат. То что атрибут привязан к коду это его сущность, а не конкретика. Вобще очень тяжело тебе объяснять — ты постоянно катишься по накатанной колее. Попробуй забыть все что ты знаешь про атрибуты и начать по новой.

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

A>Соответственно здесь получается явная привязка объекта и его диспетчера, если это двухсторонняя связь, то есть объект без этого диспетчера нефункционирует, тогда здесь атрибуты просто облегчают кодинг,

Во, в самую точку.

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

Могут. Иногда так и делают — и атрибуты и интерфейс. Только интерфейс уже кодинг усложняет.

AVK>>Шире будет — атрибуты это возможность расширять метаданные кода. Все.

A>Зачем?

Пофигу.

A> Документирование кода — тоже расширение метаданных кода. Заполнение нулевыми байтиками бинарников для выравнивания по параграфам — тоже расширение метаданных ...

Правильно мыслишь. Кастомизация поведения компилятора (#pragma в C++, {$?} в паскале и т.д.) это тоже расширение метаданных.

A>Да понимаю я это! Но их применение уменьшает и намного абстракцию объекта, как объекта класса, потому что наделяют объект функциональностью никак не присущей этому объекту ...

Я все таки предлагаю задуматься о том что атрибуты прицепляются не только к классам. Orangy очень хорошо сказал — атрибуты ортогональны ОО механизмам. Т.е. независимы друг от друга. Поэтому атрибуты увеличат или уменьшат параметры класса только если ты это сделаешь сам. Применение же атрибутов вобще автоматически к этому не приводит.
Пойми простую вещь — чем более универсальна и абстрактна вещь, тем менее она эффективна. Поэтому не только атрибуты, но и каждое наследование, добавление каждого свойства или метода уменьшает абстрактность класса. Так почему тебя возмущают только атрибуты?

Еще один образный пример. Представь себе некую молодую планету. Она покрыта однородной средой, эдаким океаном с однородной концентрацией и температурой (только начинаем разрабатывать программу, ТЗ еще не определено совсем). В этом бульоне плавают одинаковые (абстрактные, неопределенные) протоклассы (object в дотнете). У них есть какие то минимальные свойства — умеют жрать и размножаться (object обладает небольшим набором методов, очень универсальных). Тем не менее все протоклассы одинаковы и способны скрещиваться между собой.
И все бы было хорошо, но климат на планете начал меняться, и в связи с этим стала меняться внешняя среда (началась первая проработка ТЗ). Теперь океан уже не так однороден. А наши протоклассы уже не могут оставаться столь абстрактными — из-за своей абстрактности они не могут бороться эффективно с меняющимися условиями и массами гибнут (вот такая вот она абстрактность — вроде бы ничто не мешает применять везде, а на деле оказывается что нельзя применять почти нигде). Однако часть протоклассов начинает мутировать (мы начинаем наследоваться от object). В результате у кого то появляется толстая шкура или панцирь, а у кого то когти и зубы (добавляем методы, поля, свойства). Протоклассы становятся менее абстрактными и уже не могут произвольно скрещиваться между собой. Зато теперь они намного лучше приспособлены к окружающей среде, т.е. куда эффективнее протоклассов. Нервная система их усложняется (пишем код) и их поведение становиться все более сложным.
Среда обитания продолжает меняться и продолжает идти эволюция. Фауна нашей планеты продолжает меняться, ее представители становяться все сложнее и сложнее. Но в какой то момент наступает ледниковый период, причем очень быстро. Настолько быстро что эволюция не успевает менять организмы и фауне планеты грозит полное вымирание. Однако некоторые наиболее продвинутые классы научились делать то что не предусмотрено природой — надевать поверх шкуры, разжигать костер, сообща делать жилища (вот они, атрибуты. Не предусмотренное долго и тяжело меняемой структурой программы, а ложащееся как бы сеткой поверх. Решение тех проблем, ради которых нет возможности или желания менять объектную структуру программы).
Вот такое вот примерно текущее состояние у дотнета. Можно продолжить эволюцию дальше и посмотреть к чему развитие атрибутов может привести. Очевидно что постепенно роль и сложность атрибутов будет возрастать, они станут позволять делать все больше и больше, и в какой то момент атрибуты станут важнее врожденных, биологических особенностей класса. Наверное со временем часть функционала ООП будет отмирать и упрощаться. Атрибуты стабилизируют внешнюю среду класса и фактически обеспечат стабильные условия (тут на самом деле надо рассматривать не столько атрибуты, сколько механизм рефлекшена в целом). Эволюция пойдет в обратном направлении, к абстрактным протоклассам. В прямом направлении будет развиваться только нервная система (собственно код). Итог — мощнейшее разнообразие атрибутов и абстрактные классы с большим количеством и высокой сложностью кода. Т.е. уже даже фактически не классы, а хорошо структурированный код, вся метаинформация уйдет в атрибуты.

A>Ты явно не хочешь услышать о чом я говорю, я про одно ты мне про другое, но с теми же намерениями.

Я то услышал и постоянно пытаюсь тебе объяснить что те ограничения, которые ты на них накладываешь, не правомерны.

A>Приведи явный пример использования атрибутов как расширения метаданных объекта класса, который явно покажет преимущество применения атрибутов.

Я тебе уже сказал — в фреймворке их масса, в янусе много.

A> Я не могу понять почему в коде неприменимы так называемые магические значения, а в атрибутах можно всё ...
A>

A>int myIntegerNumber=17; // Угадай с трёх раз почему там 17

А вот так - int myIntegerNumber = MyEnum.Seventeen;
Ась? Атрибуты то все таки типизированны. 


AVK>>Посмотри в каких случаях атрибуты применяются в фреймворке, янусе.

A>Видел, конфиги трогать не буду, а более нигде хорошего применения в Янусе я не видел. 

Как минимум еще разметка плагинов.

A>Там такой монолит сейчас уже сложился, что я только двумя руками за Janus2.

К атрибутам это отношение не имеет. В Janus2 атрибутов еще больше.

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

Я тебе так скажу - использование атрибутов в янусе очень сильно упростило часть кода. А все остальное - от лукавого. Класс затачивать под конкретное применение все равно нужно. Вопрос в том чем это делать - изменением интерфейса и кода класса или добавлением атрибутов и написанием внешнего кода. Первое сложнее, но имеет меньший перфоманс хит и более гибкое.

A>насколько лучше было бы делать вот так:
A>[cs]
A>// Сборка с объектом
A>class MyObject
A>{   
A>   private int field;    
A>/* Остальные данные класса*/
A>};

A>// Новая сборка, например основная для программы
A>declare class MyObject /*for А здесь например указать для каких конкретных типов доступны данные аттрибуты */
A>{
A>  [XmlIgnore]
A>  [Default(17)]
A>  private int field; 
A>  /* Остальные данные класса*/
A>}
A>

A>Понимаю, что оверкодинг наблюдается, зато сохраняется абстракция объекта как класса.

Да все в общем то так и есть, за исключением того что ты предлагаешь указывать для кого атрибуты. Зачем это нужно непонятно — лишняя головная боль программеру.

AVK>>Ну коль не получается, то лучше забудь до лучших времен. Дизайн в котором изменяемые данные храняться в атрибутах никуда не годится.

A>А неизменяемые данные для объектов, годятся только в качестве документации.

Ну что я могу сказать? Главное чтобы в итоге исходный код оказался меньше и понятнее. Атрибуты позволяют этого достигнуть, значит применять их можно и нужно. А псевдокрасоты лучше оставить ученым-теоретикам.

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

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

DG>>Аттрибуты — сами по себе вспомогательные сущности.

DG>>Сторонние объекты не должны напрямую работать с аттрибутами.
DG>>С аттрибутами должен работать либо сам класс, либо вспомогательные классы для данного класса.

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

Лучше скажу так:
Есть объект A, который предоставляет информацию через аттрибуты.
Есть объект B, который пользуется информацией из объекта A.
Объект B не должен напрямую работать с аттрибутами из объекта A, объект B должен работать через вспомогательный класс C.

Пример.
Возьмем тот же Serializer и посмотрим логику его работы.
Когда Serializer-у дают сохранить объект A, то он пытается получить интерфейс ISerializable, если не получается, то создается объект C, который реализует интерфейс ISerializable и который, уже разбирается с аттрибутами.
Сам класс Serializer работает только с интерфейсом ISerializable.

Вообще, аттрибуты удобны при написании большого числа однотипных классов (например, контролы) или однотипных частей классов (например, сериализация).

Пример
Пишем мы свою систему, и на определенном этапе поняли, что у нас есть однотипные классы C1..C10 и если мы разработаем систему аттрибутов, то написание функциональности классов C11..C20 у нас сведется к объявлению нескольких переменных и привязывание аттрибутов к ним. Разворачивать же аттрибуты в нужную нам функциональность будут вспомогательные классы

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

A> Тогда не понятно почему атрибуты — это глобальные метаданные, а не локализованные областью видимости.

Не надо забывать, что аттрибуты, да и как весь .Net — еще молоды, поэтому не сделаны еще полностью "правильно", а сделаны, как было проще.
В дальнейшем может появится разделение (если конечно будет востребовано) на открытые, закрытые аттрибуты.

Да и если посмотреть на выше приведенный пример, то станет видно, что обычно классы C11..C20 будут находится, скорее всего в других сборках, чем вспомогательные классы, т.к. вспомогательные классы обычно разрабатывает, например, поставщик библиотеки, а классы C11..C20 разрабатываются конечным разработчиком. Поэтому в этом случае сложно говорить, о какой-то локализации аттрибутов.


DG>>Так если у тебя есть Serializator, то он должен не напрямую обращаться к сериализуемому классу, а получат данные для сериализации через интерфейс или хелперский класс.

A>Это и так понятно, не понятно тогда из каких соображений созданы XmlIgnoreAttribute и ему подобные в стандартной библиотеке.

Так сделан только XmlSerializator, и я бы не сказал, что он в данном случае сделан правильно.
Но у XmlSerializator-а и сама ниша очень узкая, это быстрое сохрание каких-либо настроек в config-файл.

Нормальные Serializator-ы сделаны удобнее. Если тебя не устраивают аттрибуты(не хватает функциональности или еще что-то), ты можешь реализовать интерфейс ISerializable, в котором уже можешь реализовать более гибкую схему сериализации или что-то еще.

DG>>А уже внутри этого интерфейса или хелперского класса ты будешь бегать по классу и смотреть у полей аттрибуты.

A>Самое логичное применение атрибутов, там где без них и так можно обойтись, заручившись поддержкой интерфейса или хелпера.

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

Возьмем, для примера, показ объекта в PropertyGrid-е.

С аттрибутами это делается так:

class A
{
  [DisplayName("Значение")]
  [Category("Моя категория")]
  [DefaultValue (10)]
  public int Value {get{return 10;} set{}}
}

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

Использование стандартного подхода — эту инкапсуляцию рушит:

class A:
  IProperties
{
  public int Prop {get {return 10;} set{}}

  public Property[] Properties
  {
    Property prop = new Property();
    prop.DisplayName = "Значение";
    prop.Category = "Моя категория";
    prop.DefaultValue = 10;
    return new Property[]{prop};
  }
}

Теперь при добавлении, изменении, удалении свойств класса мы должны бегать по всему классу (особенно если у нас таких интерфейсов несколько) и править код сразу в нескольких местах.
При использовании аттрибутов вся нужная информация — локализована.