Идеология Аттрибутов. - Философия программирования

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

TK>Да уж какой есть

Ну и на этом спасибо

TK>Ведь никого не смущает, что у класса есть методы, а методов аргументы... атрибут в данном случае такая-же характеристика класса как и все остальное (ни кого-же не смущает, что у поля есть имя или тип и атрибут для него будет просто небольшим уточнением). Естественно, что в наше тяжелое время находятся индивидуумы которые стараются использовать атрибуты не по назначению (примеры можно найти и в этом форуме). Кстати кроме декларативных функций атрибуты могут нести и нек. логическую нагрузку (например ThreadStaticAttribute, ContextAttribute и т.п), вводить ограничения на среду исполнения (Security attributes). Игнорирование таких возможностей привело-бы не только к усложнению языка (ThreadStatic) но, и введение доп. избыточности при реализации (Security).

Нет плюсы применения видны сразу, но есть и минусы, которые не дают мне покоя

. ThreadStatic — это вообще красиво, но ...
Это всё понятно с точки зрения написания программы, но не понятно с точки зрения ООП. Так как примеры мне удаются лучше всего на Сериалайзере, то про него. Имеется класс который описывает автомобиль (ну всякие колёса, детали, двери, мотор) и вот его надо отправить-сериализнуть (один из объектов класса) в другой город, но без колёс (колёса там свои приделают) ... С точки зрения аттрибутивного программирования мы со всех машин колёса будем снимать сразу (проставим аттрибут [WithoutWheel()]), то есть сделаем аттрибут глобальным несмотря на то что он применяется только для одной отправки в другой город, и мало того если кто-то другой решит что-то сделать с автомобилем (например прокатится на нём) и прочитает этот аттрибут, то он тоже отправится кататься без колёс.

Один из способов решения я вижу например таким:

// Псевдо код для прояснения проблемы
class Automobile
{
    public Automobile(){/*Конструирование*/}
    public Wheel _wheel=new Wheel();
    public Motor _motor=new Motor();
    /*
    Здесь куча полей и функций
    */
};

// ---> Объявление класса для например сериализатора --->
[WithoutWheel()]
declare class Automobile for XmlSerializer
{    
    /*Предполагаю, что здесь даже не нужно указывать все поля, а только те, которые изменяются аттрибутами*/
};

Таких объявлений в программе может быть множество, но факт в том, что по моему видению это должно быть так:
1) Аттрибуты определяются в объявлениях классов.
2) Для каждого аттрибута должны\могут быть указаны области действия в виде типов которые их могут увидеть.
3) Аттрибуты могут объединяться если в программе есть несколько объявлений.

В конечном итоге в рантайме это всё уже может быть приписано конкретному типу очень жёстко, но не ранее.

Вот примерно такое моё видение этой проблемы, более приемлемого пока в этой области не наблюдаю.

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

... << RSDN@Home 1.0 beta 4 >>

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

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

A>Не знаю правда как правильно это сформулировать, но попробую пояснить на пальцах.
Такая же ерунда...

A>Имеется объект, который например нужно засериализовать в XML, причём некоторым особенным образом (например не все поля нуждаются в сериализации). По-моим впечатлениям сам объект об этом знать не должен <...>
Если объект не предназначен для сериализации, не нужно его даже пытаться сериализовать. Если предназначен — он должен сам рассказать, как это делать.
Ты же не будешь пытаться добавить на форму Stream, правда?

A>А вы как думаете?
Для начала несколько наблюдений:
Во-первых, аттрибуты зачастую тесно связаны с интерфейсам. Например, SerializableAttribute и ISerializable. Особенно в компонентной модели, когда нужно описывать те или иные аспекты поведения объекта, касательно определенного интерфейса.
Во-вторых, аттрибуты в некотором смысле ортогональны наследованию, методам, интерфейсам, т.е. не связаны с ними и их можно независимо изменять, тем самым настраивая поведение объектов класса. (см.также стратегии у Александреску)
В-третьих, аттрибуты локальны, в том смысле, что они находятся непосредственно рядом с описываемой сущностью (при обычном использовании).
В-четвертых, аттрибуты почти такие же классы как и все остальные, что не может не радовать

Что же из этого следует?
Аттрибуты совместно с рефлекшном дают возможность получать дополнительную информацию о сущностях не зная ничего о них. Здесь, конечно требуется определенная аккуратность, но при вдумчивом проектировании — всё замечательно. Также с помощью аттрибутов можно неинтурзивно модифицировать поведение классов, наподобие стратегий Александреску (NB: я каждый раз упоминаю АА, ибо "стратегия" в проектировании обычно имеет несколько иной смысл, а именно обычно GOF-овский).

Особенно внимание стоит обратить на аттрибуты при наследовании. Они позволяют передовать базовым классам информацию от производных, то что в С++ обычно делается шаблонами.

// код примерный
class TypeSafeCollection : ICollection
{
    ...
    TypeSafeCollection()
    {
        ... 
        itemType = ((TypeSafeCollectionAttribute)Attribute.GetCustomAttributes(this.GetType(), typeof(TypeSafeCollectionAttribute), false)).ItemType;
        ...
    }
    ...
    void Add(object value)
    {
        if (!itemType.isAssignableFrom(value))
            throw InvalidCastException()
        ...
    }
    private Type itemType;
}

[TypeSafeCollection(typeof(MyTypeCollection))]
class MyTypeCollection : TypeSafeCollection 
{
}

Это еще не шаблоны, но уже что-то... Хотя есть определенное отличие от шаблонов в "условно положительную" сторону. Шаблоны в С++ строго типизированы, тогда как аттрибуты в некотором роде свободны от типизации. Опять же, это требует определенной аккуратности, особенно если аттрибут связан с интерфейсом, как в TypeSafeCollection выше. Что делать такой коллекции, если кто-то забудет описать аттрибут??

Использование аттрибутов с методами также даёт очень много.

class Foo
{
    [Verb("File","Open")]
    void OpenFile(object sender, EventArgs e)
    {
        ...
    }
}

Некоторый код может пробежаться по методам и, используя аттрибуты, создать элементы меню и сразу привязать соответствующие делегаты.
Здесь важно, что меню и описание Verb — локальны и не нужно носиться по всему коду при изменении Verbs. Хотя с culture здесь придётся повозиться.

Также стоит специально отметить (по мотивам тов.Рихтера), что объявление собственных аттрибутов в дополнение к "встроенным" public, static, private, etc само по себе важно с точки зрения концепции ООП, ибо позволяет относительно безопасно расширять семантику сущностей.

Что же мне не хватает?
1. Аттрибутов у имплементируемых интерфейсов.

class Blah : 
   [FooAttribute("Blah",1)] IFoo,
   [FactoryAttribute(FactoryAttribute.Singleton)] IFactory
   { ... }

2. Attribute.GetCustomAttributes(Type target, Type attr, bool inherited)
Здесь attr не может быть интерфейсом, а очень бы хотелось. Это одно из тех самых почти из "в-четвертых".

3. Перегрузка оператора new совместно с аттрибутами типа могла бы серьезно улучшить управление памятью.
Можно было бы использовать паттерны Singleton, Flyweight и т.п. естественным образом, без специального синтаксиса фабрики.
В отличие от new в С++, здесь new мог бы возвращать уже сконструированный объект, благодаря reflection и params и таким образом сильно упростить жизнь. С другой стороны, конечно можно использовать Activator.CreateInstance, однако это не так изящно и интрузивно.

Вот такие наши мысли

... << RSDN@Home 1.0 beta 4 | Сейчас четверг, 11:01, слушаю The Offspring — Me & My Old Lady >>

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

A>>Давненько меня мучает вопрос о небольшой нелогичности аттрибутов и ООП.
O>Ага, мы тут тоже всё размышляем об Аттрибутной Парадигме, как о некотором методе, а не свойстве языка.
Хоть кто-то поддержал

A>>Имеется объект, который например нужно засериализовать в XML, причём некоторым особенным образом (например не все поля нуждаются в сериализации). По-моим впечатлениям сам объект об этом знать не должен <...>
O>Если объект не предназначен для сериализации, не нужно его даже пытаться сериализовать. Если предназначен — он должен сам рассказать, как это делать.
O>Ты же не будешь пытаться добавить на форму Stream, правда?
Нет немного пожалуй не так, объект который умеет сериализовать должен знать о сериализуемом объекте всё, плюс ещё чуть-чуть того, что нужно именно для сериализации и именно этого объекта, причём сам объект об этом может и не подозревать (например в массиве некоторых объектов-обёрток мне важны только целые числа, которые эти объекты оборачивают).

O>Что же из этого следует?
O>Аттрибуты совместно с рефлекшном дают возможность получать дополнительную информацию о сущностях не зная ничего о них. Здесь, конечно требуется определенная аккуратность, но при вдумчивом проектировании — всё замечательно. Также с помощью аттрибутов можно неинтурзивно модифицировать поведение классов, наподобие стратегий Александреску (NB: я каждый раз упоминаю АА, ибо "стратегия" в проектировании обычно имеет несколько иной смысл, а именно обычно GOF-овский).
Спасибо конечно, но это-то я знаю и не всем мне это нравится.

[skip]
Сущности "Аттрибут" присущие .Net я вроде понимаю и понимаю преимущества в их использовании и всё же при проектировании испытываю некоторое сомнение прежде чем поставить некоторый аттрибут классу\полю, который совершенно не имеет отношения к этому классу\полю ... он применяется например только тем же сериализатором ... Сразу начинает казаться, что где-то с дизайном криво. И таких примеров множество:

// Псевдо - код
class Something
{
    [XmlIgnore]
    public bool _bHelpField=false;
    /*Ещё куча полей*/
};

Читая такой код невольно задумываешься, а почему это поле должен игнорировать только сериализер, а может его должны игнорировать все ? И что в таком случае придётся для каждого объекта кто будет работать с этим типом прописывать некоторые собственные аттрибуты, которые будут говорить мол, что это поле надо игнор ?
Немного лучше вот такое решение:

// Псевдо - код
class Something
{
    [SomethingIgnore]
    public bool _bHelpField=false;
    /*Ещё куча полей*/
};

// Скипаны аттрибуты
class SomethingIgnoreAttribute:Attribute
{
    // Скипаны конструктор и поля.
};

И теперь например при сериализации уже проставлять расширенные аттрибут [XmlIgnore], если описан некий аттрибут [SomethingIgnore].
Но это море лишнего кода и лишних проверок.

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

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

... << RSDN@Home 1.0 beta 4 >>

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

A>Нет плюсы применения видны сразу, но есть и минусы, которые не дают мне покоя :( . ThreadStatic — это вообще красиво, но ...
A>Это всё понятно с точки зрения написания программы, но не понятно с точки зрения ООП. Так как примеры мне удаются лучше всего на Сериалайзере, то про него. Имеется класс который описывает автомобиль (ну всякие колёса, детали, двери, мотор) и вот его надо отправить-сериализнуть (один из объектов класса) в другой город, но без колёс (колёса там свои приделают) ... С точки зрения аттрибутивного программирования мы со всех машин колёса будем снимать сразу (проставим аттрибут [WithoutWheel()]), то есть сделаем аттрибут глобальным несмотря на то что он применяется только для одной отправки в другой город, и мало того если кто-то другой решит что-то сделать с автомобилем (например прокатится на нём) и прочитает этот аттрибут, то он тоже отправится кататься без колёс.

A>Один из способов решения я вижу например таким:
A>

A>// Псевдо код для прояснения проблемы
A>class Automobile
A>{
A>};

A>// ---> Объявление класса для например сериализатора --->
A>[WithoutWheel()]
A>declare class Automobile for XmlSerializer
A>{    
A>    /*Предполагаю, что здесь даже не нужно указывать все поля, а только те, которые изменяются аттрибутами*/
      /*Предполагаю, что здесь даже не нужно подробнее почитать MSDN */
A>};
A>

A>Таких объявлений в программе может быть множество, но факт в том, что по моему видению это должно быть так:
A>1) Аттрибуты определяются в объявлениях классов.
A>2) Для каждого аттрибута должны\могут быть указаны области действия в виде типов которые их могут увидеть.
A>3) Аттрибуты могут объединяться если в программе есть несколько объявлений.

A>В конечном итоге в рантайме это всё уже может быть приписано конкретному типу очень жёстко, но не ранее.
A>Вот примерно такое моё видение этой проблемы, более приемлемого пока в этой области не наблюдаю. :shuffle:

Если без колес, то проще так: Automobile.Wheel = null; Automobile.MoveTo(Другой город);

А если серьезно — то это пример того, как не нужно проектировать автомобили и использовать атрибуты :)

Или по пунктам:
1) Да. их можно там указывать.
2) Это тоже самое, что и автомобиль который будет ездить только по ограниченному количеству дорог (авто триал такой :)) )
3) Да, да наследуемых классов они объединяются.

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

т.е. должно быть что-то вида:

public class AutoMobile
{
    public Engine Engine;
    public Wheel Wheel; // добавить остальное по вкусу.
}

public class AutoMobileDialer
{
    public static XmlSerializer FullComplectDelivery
    {
       get
       {
          //TODO: Insert Your Code Here
       }
    }

    public static XmlSerializer WheelLessDelivery
    {
       get
       {
          //TODO: Insert Your Code Here
       }
    }
}

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

A>Не знаю правда как правильно это сформулировать, но попробую пояснить на пальцах.
A>Имеется объект, который например нужно засериализовать в XML, причём некоторым особенным образом (например не все поля нуждаются в сериализации). По-моим впечатлениям сам объект об этом знать не должен,

Вобще то один из базовых принципов ООП — инкапсуляция. То есть как обрабатывать свои данные знает сам объект и больше никто.

... << RSDN@Home 1.0 beta 4 (developer build)>>

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

A>Это всё понятно с точки зрения написания программы, но не понятно с точки зрения ООП.

Если честно, то с точки зрения ООП непонятны твои желания извне вмешиваться в функционирование объекта.

A>Так как примеры мне удаются лучше всего на Сериалайзере, то про него. Имеется класс который описывает автомобиль (ну всякие колёса, детали, двери, мотор) и вот его надо отправить-сериализнуть (один из объектов класса) в другой город, но без колёс (колёса там свои приделают) ... С точки зрения аттрибутивного программирования мы со всех машин колёса будем снимать сразу (проставим аттрибут [WithoutWheel()]), то есть сделаем аттрибут глобальным несмотря на то что он применяется только для одной отправки в другой город, и мало того если кто-то другой решит что-то сделать с автомобилем (например прокатится на нём) и прочитает этот аттрибут, то он тоже отправится кататься без колёс.

А если так — на одном автомобиле колеса можно отвинтить, а на другом колес нет, там гусеницы и открутить их нельзя. Кто об этом знает? Правильно, сам автомобиль.

... << RSDN@Home 1.0 beta 4 (developer build)>>

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

O>3. Перегрузка оператора new совместно с аттрибутами типа могла бы серьезно улучшить управление памятью.
O>Можно было бы использовать паттерны Singleton, Flyweight и т.п. естественным образом, без специального синтаксиса фабрики.

Самое неприятное что эти жулики в родной библиотеке таки new как то для себя переопределяют, а вот ты сделать подобное не можешь.

... << RSDN@Home 1.0 beta 4 (developer build)>>

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

TK>Если без колес, то проще так: Automobile.Wheel = null; Automobile.MoveTo(Другой город);

TK>А если серьезно — то это пример того, как не нужно проектировать автомобили и использовать атрибуты

Ну может пример неудачный.

TK>Или по пунктам:
TK>1) Да. их можно там указывать.
Знаю, видел.
TK>2) Это тоже самое, что и автомобиль который будет ездить только по ограниченному количеству дорог (авто триал такой

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

TK>3) Да, да наследуемых классов они объединяются.
Ради нового аттрибута делать обёртку-пустышку ...

TK>Это, что автомобиль бэтмена который сам заботится о том, как ему отправить себя в другой город?
Наоборот, он не должен этого делать, а делает ... пример из жизни этот самый что ни на есть XmlSerializer.

TK>В реальной жизни люди которые проектируют автомобили их доставкой и их комплектацией не занимаются.
TK>Здесь все то-же самое. Автомобиль не должен делать сам чужую работу.
Да про это и речь.

TK>

TK>public class AutoMobile
TK>{
TK>    public Engine Engine;
TK>    public Wheel Wheel; // добавить остальное по вкусу.
TK>}

TK>public class AutoMobileDialer
TK>{
TK>    public static XmlSerializer FullComplectDelivery
TK>    {
TK>       get
TK>       {
TK>          //TODO: Insert Your Code Here
TK>       }
TK>    }

TK>    public static XmlSerializer WheelLessDelivery
TK>    {
TK>       get
TK>       {
TK>          //TODO: Insert Your Code Here
TK>       }
TK>    }
TK>}
TK>

Красиво. Я так это себе и представлял в общем-то. Но это же делается через аттрибуты объекта класса AutoMobile и очень некачественно. Можно ли такой же вариант реализовать с помощью аттрибутов без участия объекта AutoMobile? Если можно, то я чего-то недопонимаю в аттрибутах.
Наверно мне теперь не хватает убедительнейшего примера употребления аттрибута там где он будет абсолютно оправдан, а иначе получается, что вместо всех аттрибутов нужно обходится некоторыми промежуточными классами (что в прочем с успехом и делалось в C++).

Всё короче, что-то я совсем запутался, попробую чуть позже поконкретнее сформулировать мысль, сейчас поработать надо

.

P.S. Спасибо за прояснение некоторых деталей, которые я и так знаю, но возможно не так понимаю

.

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

... << RSDN@Home 1.0 beta 4 >>

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

A>Нет немного пожалуй не так, объект который умеет сериализовать должен знать о сериализуемом объекте всё,

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

ИМХО ты все поставил с ног на голову, а потом удивляешься что у тебя что то не стыкуется.

A>class Something
A>{
A> [XmlIgnore]
A> public bool _bHelpField=false;
A> /*Ещё куча полей*/
A>};
A>[/cs]
A>Читая такой код невольно задумываешься, а почему это поле должен игнорировать только сериализер, а может его должны игнорировать все ?

А если его должен игнорировать только сериалайзер?

A> И что в таком случае придётся для каждого объекта кто будет работать с этим типом прописывать некоторые собственные аттрибуты, которые будут говорить мол, что это поле надо игнор ?

Да. А как иначе? У каждого свои требования.

A>И теперь например при сериализации уже проставлять расширенные аттрибут [XmlIgnore], если описан некий аттрибут [SomethingIgnore].

А если области игнорирования разных потребителей не совпадают?

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

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

... << RSDN@Home 1.0 beta 4 (developer build)>>

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

[skip]

AVK>Вобще то один из базовых принципов ООП — инкапсуляция. То есть как обрабатывать свои данные знает сам объект и больше никто.
Вот и поясни как аттрибуты типа [XmlIgnore] помогают эту инкапсуляцию сохранять ... Если через рефлекшон ты всё равно все поля выбрать можешь, а про этот аттрибут знает только сам XmlSerializer ... Но никак не объект. Объект сам себе помечает, что-то то о чом сам о нисколько и не догадывается. По меньшей мере странно.

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

... << RSDN@Home 1.0 beta 4 >>

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

[skip]

A>>Это всё понятно с точки зрения написания программы, но не понятно с точки зрения ООП.

AVK>Если честно, то с точки зрения ООП непонятны твои желания извне вмешиваться в функционирование объекта.

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

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

... << RSDN@Home 1.0 beta 4 >>

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

AVK>>Вобще то один из базовых принципов ООП — инкапсуляция. То есть как обрабатывать свои данные знает сам объект и больше никто.
A>Вот и поясни как аттрибуты типа [XmlIgnore] помогают эту инкапсуляцию сохранять ... Если через рефлекшон ты всё равно все поля выбрать можешь, а про этот аттрибут знает только сам XmlSerializer ... Но никак не объект. Объект сам себе помечает, что-то то о чом сам о нисколько и не догадывается. По меньшей мере странно.

Если объект помечает какое-то свойство как XmlIgnore, то наверное знает, что это свойство сериализировать не нужно (например оно вычисляемое и т.п.) плюс не стоит забывать, что некоторые аттрибуты можно добавлять на этапе исполнения.

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

TK>>2) Это тоже самое, что и автомобиль который будет ездить только по ограниченному количеству дорог (авто триал такой

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

То есть дорога должна знать о всех типах автомобилей, которые по ней ездят? А если новый автомобиль появился — все дороги переделывать надо?

... << RSDN@Home 1.0 beta 4 (developer build)>>

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

AVK>>Если честно, то с точки зрения ООП непонятны твои желания извне вмешиваться в функционирование объекта.

A>А почему собственно нет,

Потому что это противоречит базовым принципам ООП.

A>я знаю об объекте всё что он мне может сообщить

А если он не хочет персонально тебе о чем то сообщать?

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

А если то, что ты отбираешь сериализовывать нельзя?

A>То есть, чтобы он мне отдал только именно то, что мне нужно, но не больше и только мне. (под объектом подразумеваю объект класса).

Это намного сложнее чем разметить объект атрибутами.

... << RSDN@Home 1.0 beta 4 (developer build)>>

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

O>>3. Перегрузка оператора new совместно с аттрибутами типа могла бы серьезно улучшить управление памятью.
O>>Можно было бы использовать паттерны Singleton, Flyweight и т.п. естественным образом, без специального синтаксиса фабрики.
AVK>Самое неприятное что эти жулики в родной библиотеке таки new как то для себя переопределяют, а вот ты сделать подобное не можешь.
Намекни куда покопать? Всмысле с чего ты взял что это так?

ЗЫ: Очень мне хочется почитать что-нибудь типа Design & Evolution of .NET

Может кто ссылочками поделится? Интересуют только откровения создателей. Слов "фиг пойми почему MS сделала так, а не эдак" и так полно в сети...

... << RSDN@Home 1.0 beta 4 | Сейчас четверг, 14:01, слушаю The Offspring — The end of the line >>

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

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

O>>>3. Перегрузка оператора new совместно с аттрибутами типа могла бы серьезно улучшить управление памятью.
O>>>Можно было бы использовать паттерны Singleton, Flyweight и т.п. естественным образом, без специального синтаксиса фабрики.
AVK>>Самое неприятное что эти жулики в родной библиотеке таки new как то для себя переопределяют, а вот ты сделать подобное не можешь.
O>Намекни куда покопать? Всмысле с чего ты взял что это так?

Копать в сторону rotor.

O>ЗЫ: Очень мне хочется почитать что-нибудь типа Design & Evolution of .NET :) Может кто ссылочками поделится? Интересуют только откровения создателей. Слов "фиг пойми почему MS сделала так, а не эдак" и так полно в сети...

А что непонятного? Вроде как все логично :)

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

AVK>>Самое неприятное что эти жулики в родной библиотеке таки new как то для себя переопределяют, а вот ты сделать подобное не можешь.
O>Намекни куда покопать? Всмысле с чего ты взял что это так?

Remoting. Посмотри RemotingConfiguration.RegisterXXXType() и к чему он приводит. Я так тоже хочу

O>ЗЫ: Очень мне хочется почитать что-нибудь типа Design & Evolution of .NET

Может кто ссылочками поделится? Интересуют только откровения создателей. Слов "фиг пойми почему MS сделала так, а не эдак" и так полно в сети...

Есть кой чего на .NET Architecture Center, но там мало. Есть кое что на www.gotdotnet.com. А так чтобы было много и в одном месте не видел.

... << RSDN@Home 1.0 beta 4 (developer build)>>

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

[skip]

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

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

Так как аттрибуты применяются всё равно только в рантайме, то почему нельзя придумать механизм накручивания их именно в рантайме. То есть существует некая статическая сущность = объект класса, а мы неким образом накручиваем ей аттрибуты присущие этому (текущему) рантайму. Существующий способ предполагает, что если я использую один и тот же объект в нескольких программах (одна dll), то путём наворотов аттрибутов для одной программы и для другой в этот объект, я могу получить нечто, которое можно обозвать Attribute Hell по аналогии с ... А иначе для каждой программы придётся делать либо свою библиотеку, либо в каждой делать обёртки и аттрибуты наворачивать уже для них, хотя принципиально объект один и тот же.

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

... << RSDN@Home 1.0 beta 4 >>

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

[skip]

AVK>>>Если честно, то с точки зрения ООП непонятны твои желания извне вмешиваться в функционирование объекта.
A>>А почему собственно нет,
AVK>Потому что это противоречит базовым принципам ООП.

Нисколько. Мне объект всё что нужно сообщил, а остальное я волен решать сам. Читая например те же аттрибуты.

A>>я знаю об объекте всё что он мне может сообщить
AVK>А если он не хочет персонально тебе о чем то сообщать?

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

A>>а далее я отбираю то, что мне нужно и иду курить с этим самым и всё.
AVK>А если то, что ты отбираешь сериализовывать нельзя?

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

A>>То есть, чтобы он мне отдал только именно то, что мне нужно, но не больше и только мне. (под объектом подразумеваю объект класса).
AVK>Это намного сложнее чем разметить объект атрибутами.

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

AVK>То есть дорога должна знать о всех типах автомобилей, которые по ней ездят? А если новый автомобиль появился — все дороги переделывать надо?
А нет не должна, пущай по обыкновенному асфальту гоняют 30 тонные Белазы ...

P.S. Пример неудачный.

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

... << RSDN@Home 1.0 beta 4 >>

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

A>Мне не нравится способ описания аттрибутов как непременных сущностей объектов класса.

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

A>То есть при проектировании объекта (утрируя представим его как один класс), я не могу утверждать, что у этого объекта вот эти поля можно игнорировать кому-либо, а кому либо нельзя.

Значит применять атрибуты в этом случае нельзя, нужно реализовывать интерфейс кастомной сериализации.

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

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

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

Монстр, которого нельзя вытащить образуется только при неправильном проектировании. Атрибуты к этому не имеют ровно никакого отношения.

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

Кто тебе это сказал? Не только. Атрибуты могут использоваться и при инспектировании сборки, некоторые атрибуты используются компилятором.

A>то почему нельзя придумать механизм накручивания их именно в рантайме.

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

A>То есть существует некая статическая сущность = объект класса,

Так статическая сущность или все таки экземпляр класса?

A>а мы неким образом накручиваем ей аттрибуты присущие этому (текущему) рантайму.

Непонятно одно — зачем здесь атрибуты?

A>Существующий способ предполагает, что если я использую один и тот же объект в нескольких программах (одна dll), то путём наворотов аттрибутов для одной программы и для другой в этот объект, я могу получить нечто, которое можно обозвать Attribute Hell по аналогии с ...

Существующий способ вобще не предполагает использование атрибутов для изменяемых данных. Если используются атрибуты значит данные в рантайме менять не надо.

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

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

... << RSDN@Home 1.0 beta 4 (developer build)>>

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

AVK>>Потому что это противоречит базовым принципам ООП.

A>Нисколько. Мне объект всё что нужно сообщил, а остальное я волен решать сам. Читая например те же аттрибуты.

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

AVK>>А если он не хочет персонально тебе о чем то сообщать?

AVK>>Это намного сложнее чем разметить объект атрибутами.

A>Вряд ли, скорее это немного более расширенные аттрибуты.

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

A>В рантайме через рефлекшон, очень легко реализуется,

Вот им и пользуйся. Зачем тебе атрибуты?

... << RSDN@Home 1.0 beta 4 (developer build)>>

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

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

A>[skip]

AVK>>>>Если честно, то с точки зрения ООП непонятны твои желания извне вмешиваться в функционирование объекта.
A>>>А почему собственно нет,
AVK>>Потому что это противоречит базовым принципам ООП.

A>Нисколько. Мне объект всё что нужно сообщил, а остальное я волен решать сам. Читая например те же аттрибуты.

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

Object.PutYourStupidStateInfo( StateInfoBag )
Storage.Save( StateInfoBag )
or
Network.Send( StateInfoBag )

A>>>я знаю об объекте всё что он мне может сообщить
AVK>>А если он не хочет персонально тебе о чем то сообщать?

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

A>>>а далее я отбираю то, что мне нужно и иду курить с этим самым и всё.
AVK>>А если то, что ты отбираешь сериализовывать нельзя?

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

A>>>То есть, чтобы он мне отдал только именно то, что мне нужно, но не больше и только мне. (под объектом подразумеваю объект класса).
AVK>>Это намного сложнее чем разметить объект атрибутами.

A>Вряд ли, скорее это немного более расширенные аттрибуты. В рантайме через рефлекшон, очень легко реализуется, но никак не реализуется через "настоящие" аттрибуты описываемые в программе.

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

A>

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

abstract class Транспорт
{
    //Возвращает количество полей, помеченных как "Колесо", или ещё что-нибудь
    КоличествоКолёс();
    ...
}
class Велосипед : Транспорт
{
    [Колесо]
    ПереднееКолесо;
    [Колесо]
    ЗаднееКолесо;

    [Рама]
    Звонок;
    [Рама]
    Сиденье;
}
class Машина : Транспорт
{
    [Колесо]
    ПравоеКолесо;
    [Колесо]
    ЛевоеКолесо;

    [Корпус]
    Фары;
    [Корпус]
    Двери;
}

Ну и писать классы, которые отправляют в другой город на основе данных о деталях (или дают миллион, когда уберёшься из города).
Тогда при отправке в другой город можно выбирать, что именно будет отправляться — рама, или всё, что не является колёсами. То есть, что и как отправлять — дело исключительно тех, кто отправляет, но мы должны предоставить им информацию, что же именно отправляется. Не нужно создавать атрибут типа "КолесоКотороеНужноОтвинтитьПриОтправкеВДругойГородАИначеНеТрогать", а достаточно просто пометить нужную сущность, как "Колесо"

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

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

... << RSDN@Home 1.0 beta 4 >>

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

O>Использование аттрибутов с методами также даёт очень много.
O>

O>class Foo
O>{
O>    [Verb("File","Open")]
O>    void OpenFile(object sender, EventArgs e)
O>    {
O>        ...
O>    }
O>}
O>

O>Некоторый код может пробежаться по методам и, используя аттрибуты, создать элементы меню и сразу привязать соответствующие делегаты.
O>Здесь важно, что меню и описание Verb — локальны и не нужно носиться по всему коду при изменении Verbs. Хотя с culture здесь придётся повозиться.

О! AVK, видишь? Примерно то о чем я тебе говорю. Только эти "object sender, EventArgs e" долой. И общий механизм экспорта из сервиса прикрутить. Ни и потом наваять возможность редизайна меню и тулбаров.

... << RSDN@Home 1.0 beta 4 >>

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

AVK>Твое желание менять атрибуты в рантайме равносильно желанию в рантайме добавить поле или метод.

А что? Было бы очень удобно. Ну по крайней мере помечтать можно.

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

Да вообще-то статические свойства здесь в самый раз. Лезишь и узнаешь рантаймную информацию.

... << RSDN@Home 1.0 beta 4 >>

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

AVK>То есть дорога должна знать о всех типах автомобилей, которые по ней ездят? А если новый автомобиль появился — все дороги переделывать надо?

Пометить дорогу как деприкейтед, а рядом проложить новую.

... << RSDN@Home 1.0 beta 4 >>

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

AVK>>Твое желание менять атрибуты в рантайме равносильно желанию в рантайме добавить поле или метод.

VD>А что? Было бы очень удобно. Ну по крайней мере помечтать можно.

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

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

VD>Да вообще-то статические свойства здесь в самый раз. Лезишь и узнаешь рантаймную информацию.

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

... << RSDN@Home 1.0 beta 4 (np: тихо) >>

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

VD>О! AVK, видишь? Примерно то о чем я тебе говорю.

Так я вроде бы на счет этого и не возражал.

... << RSDN@Home 1.0 beta 4 (np: тихо) >>

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

AVK>Так я вроде бы на счет этого и не возражал.

Ты их че-то суешь в хмл.

... << RSDN@Home 1.0 beta 4 >>

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

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

Во-во. А хотель бы шоб просто добавить... и все пучечком.

AVK>Можно и свойства, на делегатах просто можно реализовать более навороченую и гибкую логику.

Да вроде все тоже самое.

... << RSDN@Home 1.0 beta 4 >>

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

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

VD>Во-во. А хотель бы шоб просто добавить... и все пучечком.

Это приведет к таким логическим глюкам что мама дорогая.

... << RSDN@Home 1.0 beta 4 (np: тихо) >>

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

AVK>>Так я вроде бы на счет этого и не возражал.

VD>Ты их че-то суешь в хмл.

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

... << RSDN@Home 1.0 beta 4 (np: тихо) >>

Привет 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!

... << using( RSDN@Home 1.0 beta 4 ) {/* Работаем */} >>

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

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

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

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

... << using( RSDN@Home 1.0 beta 4 ) {/* Работаем */} >>

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

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

класс

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

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

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

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

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

Да.

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

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

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

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

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

Почему нет?

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.0 beta 4 (developer build)>>

Здравствуйте, 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!

... << using( RSDN@Home 1.0 beta 4 ) {/* Работаем */} >>

Здравствуйте, 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!

... << using( RSDN@Home 1.0 beta 4 ) {/* Работаем */} >>

Здравствуйте, 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, то он должен не напрямую обращаться к сериализуемому классу, а получат данные для сериализации через интерфейс или хелперский класс.

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

... << RSDN@Home 1.0 beta 3 >>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.

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

... << RSDN@Home 1.0 beta 4 (developer build)>>

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

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>Применение аттрибута и правда портит класс, т.к. он становится тяжело переносим (нужно везде вырезать аттрибут)

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

... << RSDN@Home 1.0 beta 4 (developer build)>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.0 beta 4 >>

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

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

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

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

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

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

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

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

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

.

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

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

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

... << using( RSDN@Home 1.0 beta 4 ) {/* Работаем */} >>

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

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

... << RSDN@Home 1.0 beta 3 >>

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

S>Ты не прав.

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

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

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

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

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

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

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

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

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

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

... << using( RSDN@Home 1.0 beta 4 ) {/* Работаем */} >>

Здравствуйте, 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!

... << using( RSDN@Home 1.0 beta 4 ) {/* Работаем */} >>

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

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

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

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

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

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

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

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

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

... << using( RSDN@Home 1.0 beta 4 ) {/* Работаем */} >>

Здравствуйте, 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>А неизменяемые данные для объектов, годятся только в качестве документации.

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

... << RSDN@Home 1.0 beta 4 (np: тихо) >>

Здравствуйте, 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};
  }
}

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

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

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

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

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

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

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

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

... << RSDN@Home 1.0 beta 3 >>

От:	Andir	http://twitter.com/AndirNotes
Дата:	09.01.03 01:18
Оценка:

	От:	MaxMP
	Дата:	09.01.03 03:55
	Оценка:

От:	TK	кывт.рф
Дата:	09.01.03 04:05
Оценка:

От:	Andir	http://twitter.com/AndirNotes
Дата:	09.01.03 04:10
Оценка:

От:	Andir	http://twitter.com/AndirNotes
Дата:	09.01.03 04:17
Оценка:

От:	orangy	http://twitter.com/orangy
Дата:	09.01.03 05:49
Оценка:	55 (7)

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	09.01.03 07:30
Оценка:	8 (1)

От:	VladD2	www.nemerle.org
Дата:	09.01.03 13:37
Оценка:	9 (1)

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	10.01.03 11:04
Оценка:	9 (1)

От:	Vi2	http://www.adem.ru
Дата:	10.01.03 14:11
Оценка:	16 (2)

От:	Sinclair	https://github.com/evilguest/
Дата:	11.01.03 07:47
Оценка: