ГЛАВНАЯ     АРХИВ     НАПИСАТЬ АДМИНУ     ПОДПИСАТЬСЯ НА RSS     ВОЙТИ      

Поиск

Категории

Облако тегов

  << Предыдущий пост       Следующий пост >>  
От: ironMan
16. августа 2011 02:47

История вопроса

Большинство языков программирования разрабатываются с учетом набора необходимых возможностей. Так, в начале создания компилятора вы думаете, какова будет структура приложений на новом языке, как один фрагмент кода будет вызывать другой, как распределить функциональность, и о многих других проблемах, решение которых сделает язык продуктивным средством создания ПО. Обычно разработчикам компиляторов приходится иметь дело со статическими сущностями. Например, вы определяете класс на С#, помещая перед его именем ключевое слово class. После этого вы определяете производный класс, вставляя двоеточие после его имени, за которым следует название базового класса. Это может служить примером решения, которое принимается разработчиком языка однажды и навсегда. Сейчас те, кто пишет компиляторы, семь раз отмерят, прежде чем отрежут. Но даже они не могут предвидеть все будущие усовершенствования в нашей области и то, как они повлияют на способы выражения программистами типов на данном языке. Скажем, как создать связь между классом на C++ и URL документации для данного класса? Или как вы будете ассоциировать члены классов C++ с полями XML в новом решении вашей компании в области электронной коммерции? Поскольку C++ разрабатывался задолго до прихода в нашу жизнь Интернета и протоколов, таких как XML, обе эти задачи выполнить довольно трудно. До сих пор решения подобных проблем предполагают хранение дополнительной информации в отдельном файле (DEF, IDL и т. д.), которая затем связывается с тем или иным типом или членом. Так как компилятор не обладает сведениями о каком-то файле или связи между вашим классом и этим файлом, такой подход обычно называется разрывным решением (disconnected solution). Главная проблема в том, что класс больше не является «самоописывающимся», т. е. теперь пользователь не может сказать о классе все, лишь взглянув на его определение. Одно из преимуществ самоописывающегося компонента — гарантия соблюдения при компиляции и в период выполнения правил, ассоциированных с компонентом. Кроме того, сопровождение самоописывающегося компонента проще, поскольку разработчик может найти всю связанную с ним информацию в одном месте. Так все и было многие десятилетня. Разработчики языка пытаются определить, что вы хотите от языка, создают компилятор с этими возможностями, и, к счастью или к сожалению, вы остаетесь с этими возможностями до прихода следующего компилятора. Так это и было вплоть до сегодняшнего дня. С# предлагает иную парадигму, берущую начало от атрибутов (attributes).

Назначение атрибутов

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



class MyClass
{
[RegistryKey (HKEYCURRENTUSER, "foo")]
public int Foo;
}



Чтобы прикрепить определенный атрибут к типу или члену С#, нужно просто задать данные атрибута в скобках перед целевым типом или членом. В нашем примере мы прикрепили атрибут RegistryKey к полю MyClass.Foo. Как вы вскоре увидите, все, что нам надо сделать в период выполнения,—это запросить значение поля, связанное с разделом реестра, и использовать его, чтобы сохранить данные в реестре.

Похожие записи


Вопросы на собеседовании C#, Net, ASP.NET, SQL
Продолжая тему вопросов на собеседовании. Нашел еще одну подборку. Оригинал лежит здесь . Перенес, чтобы не затерялось. Есть вполне вменяемые ответы (хотя, на некоторые вопросы ответил бы по-другому). Ответы находятся после списка вопросов, я их не менял. 23. Что такое шаблон проектирования Model/View/Controller? Как и зачем его применяют? 2...

Многопоточный HTTP сервер на C#
Оригинал статьи здесь: Многопоточный сервер на C# за 15 минут Автор (на хабре): ertaquo C# довольно простой и гибкий язык. Вместе с .NET поставляется довольно много уже готовых классов, что делает его еще проще. Настолько, что вполне можно написать простой многопоточный HTTP-сервер для отдачи статического содержимого всего за 15 минут. Можно было бы использовать уже...

Нейгел, Ивьен, Глинн, Уотсон, Скиннер - C# 2008 и платформа .NET 3.5
Название: C# 2008 и платформа .NET 3.5 для профессионалов Авторы: Нейгел, Ивьен, Глинн, Уотсон, Скиннер Издательство: Вильямс ISBN: 978-5-8459-1458-3 Год: 2008 Страниц: 1392 От издателя: Эта книга является совершенным руководством по языку C# 2008 и его среде. Она обновлена с учетом вышедших версий .NET 3.5 и Visual Studio 2008. Начиная с обзора и архитектуры ...

Добавить комментарий




biuquote
  • Комментарий
  • Предпросмотр
Loading


  Сохранить комментарий