Неплохая статейка, описывающая роли ключей /debug /optimize, компилятора C#:

http://blogs.msdn.com/ericlippert/archive/2009/06/11/what-does-the-optimize-switch-do.aspx

Небольшой обзор того, что нам готовит новая версия спецификации языка.
Смена первой цифры произошла благодаря четырём основным фичам:

• Dynamycally Typed Objects
• Optional and Named Prameters
• Improved COM Interoperability
• Co- and Conra-variance

Сегодня подробней рассмотрим первую.

Dynamycally Typed Objects
Динамическая система типов является, пожалуй, самым основным нововведением языка. Судя по лекциям с PDC 2008, c точки зрения архитектуры .NET добавился еще один компонент – DLR (dynamic object runtime), являющийся, по сути, надстройкой над CLR. С точки зрения языка добавилось ключевое слово dymanic. И одноименный тип добавился в .NET Type System.
Какое время назад Microsoft Research утверждала, что реализация будет происходить так: на момент компиляции объект будет не типизирован, а тэгирован, и на момент выполнения тег заменяется на свежевычесленный тип и вместо “неопределенного” типа подставляется “настоящий” и дальше все работает по старой схеме. Собственно DLR этим и должен заниматься.
Но что же происходит на самом деле?
Read the rest of this entry »

В этом выпуске:
Раздел: Средний .NET разработчик

1. Вопрос #10: Опишите разницу между интерфейсно-ориентированным, объектно-ориентированным и аспектно-ориентированным стилями программирования.
2. Вопрос #11: Дайте описание Интерфейса и опишите основные его отличия от Класса.
3. Вопрос #12: Что такое Reflection?

Вопрос #10: Опишите разницу между интерфейсно-ориентированным, объектно-ориентированным и аспектно-ориентированным стилями программирования.

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

Вопрос #11: Дайте описание Интерфейса и опишите его основные отличия от Класса.

Ответ: Ответ на этот вопрос чрезвычайно объемен. Попробую сделать выжимку. Начать, думаю, стоит с определений, доступных в спецификации языка C#:
Класс – структура данных, которая может содержать: члены-данные, такие как константы и переменные; члены-функции, такие как методы, свойства, события, индексаторы, операторы, конструкторы класса, деструкторы и статические конструкторы; вложенные типы. Классы поддерживают одиночное наследование.
Интерфейс – структура данных, которая может содержать: методы, свойства, события и индексаторы. Интерфейс не содержит реализации этих типов. Он определяет контракт, предписывающий, классам и структурам, которые реализуют этот интерфейс реализовывать все его члены. Интерфейсы поддерживают множественное наследование.
Уже из определения видно, что основное различие – идеологическое. Не смотря на то, что с точки зрения CLR и то и то является типом данных, класс – это контейнер, а интерфейс – контракт.
Вообще говоря, вопрос, поставленный в самом начале не совсем верен. О различиях, как мне кажется, мы можем говорить, в случае сущностей противоположных или в каких-то аспектах, претендующих на одну и ту же роль. Такая ситуация имеет место быть, например, в случаях с абстрактными классами и интерфейсами. В обобщенном же случае мы говорим и связке «класс-интерфейс», эффективно они существуют в паре. Отсутствие механизма множественного наследования в CLR в большинстве случаев разрешается множественной реализацией интерфейсов. В случае значимых типов, когда имеется базовый тип ValueType, наличие интерфейсов позволяет создавать пользовательские типы, удовлетворяющие определенным ограничениям и т.п.

Вопрос #12: Что такое Reflection?

Ответ: Говоря формально, Reflection или Отражение (перевод, принятый в русскоязычной литературе), по сути, процесс, при котором приложение во время выполнения, может отслеживать трассу исполнения, поведение и собственную структуру и менять их. В разрезе .NET, а мы говорим, уже о конкретной реализации отражений в среде виртуальной машины .NET, этот механизм реализован с помощью средств, доступных в пространстве имен System.Reflection. Эти средства позволяют читать метаданные сборок, подгружать их в домены приложений, исполнять методы и использовать типы сторонних сборок, о которых приложение в момент компиляции ничего не знает. Чаще всего, практическое применение механизм отражений находит в создании приложений, поддерживающих подключаемые модули (add-in). Однако наличие механизмов отражений открывает широкие возможности для метапрограммирования и создания суперкомпиляторов.

На шестой вопрос ответов на вопросы Хансельмана, по поводу Component Cоntainer, пришло некоторое количество недоуменных отзывов. Действительно, я написал несколько расплывчато и не объяснил откуда взялся именно Windows Server. Попробую исправиться.

В данном вопросе речь идет скорее о поддержке разноцелевых операционных систем. Серверные опреационные системы несколько отличаются от клиентских. Разный набор поддерживаемых фич. Дело в том, что в .NET CL есть множество Component Container, однако в МСДН, в разделе про применимость каждого из них, частенько ничего не сказано о поддержке серверных ОС. Ограничения могут быть связаны, например, с тем, что серверные ОС не поддерживают красивостей интефейсной части, там нет тем рабочего стола, потому большая часть контролов относящихся к украшательству на сервере недоступна, и т.п.

Мне кажется, что правильнее было бы сформулировать вопрос о наиболее универсальных Compnent Container, применимых как в серверных так и в клиентских ОС.

В этом выпуске:
Раздел: Каждый, кто пишет код

1. Вопрос #7: Что такое PID? Как его можно использовать для устранения неисправностей системы?
2. Вопрос #8: Сколько процессов могут “слушать” один TCP/IP порт?
3. Вопрос #9: Что такое GAC? Какую проблему он решает?

Вопрос #7: Что такое PID? Как его можно использовать для устранения неисправностей системы?
Ответ: PID (Process Identifier) уникальный идентификатор процесса, который выдается системой при создании. Идентификатор интересующего процесса можно подсмотреть в Task Manager. Использовать идентификатор процесса можно для завершения этого процесса из Task Manager, можно подключать к нему из дебугер Visual Studio при наличии соответствующих символов и т.д. Подробнее о процессах можно почитать в ответе на первый вопрос и по ссылке на MSDN.

Вопрос #8: Сколько процессов могут “слушать” один TCP/IP порт?
Ответ: В каждый момент времени только один.

Вопрос #9: Что такое GAC? Какую проблему он решает?
Ответ: GAC (Global Assembly Cache) – кэш для хранения сборок .NET. По сути GAC – это директория расположенная по пути %WINDIR%\assembly и хранящая все зарегистрированные сборки. Хорошим тоном считается, при использовании сборки на клиентской машине, зарегистрировать её в GAC. Это помогает решить, так называемую проблему dll-hell. GAC позволяет отслеживать версионность, связи и зависимости сборок (динамически линкуемых библиотек, к примеру) зарегистрированных в системе, тем самым избавляя разработчика от множества проблем связанных с подгрузкорй «не той» dll, выщитыванием и валидацией пути к нужной dll и т.п. (http://msdn.microsoft.com/en-us/library/yf1d93sz.aspx)