Привет RSDN!

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

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

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

А вы как думаете?

З.Ы. Или я настолько сильно заблуждаюсь?

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

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

A>Привет RSDN!

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

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

Не понял: выход октуда (какая задача)?

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

Можно развить эту тему дальше: меня мучает вопрос о небольшой нелогичности методов класса и ООП.

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

З.Ы. Или я настолько сильно заблуждаюсь?

Тоже самое с полями

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

MMP>Не понял: выход октуда (какая задача)?
Чтобы соответсвовать модели ООП. Никакой задачи нет, просто идея совмещения аттрибутов и ООП не очень укладывается в модель, в которой я уже привык программировать ...

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

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

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

TK>Можно развить эту тему дальше: меня мучает вопрос о небольшой нелогичности методов класса и ООП.

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

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

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

TK>>Можно развить эту тему дальше: меня мучает вопрос о небольшой нелогичности методов класса и ООП.

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

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

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

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

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

Здравствуйте, 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, однако это не так изящно и интрузивно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[skip]

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

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

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

[skip]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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