Net framework 5, а также среды Visual Studio 2012 и C#

Глава.6 .Основные.сведения.о.членах.и.типах
Независимо от используемой для вызова экземплярного или виртуального 
метода инструкции — 
call
или 
callvirt
— эти методы всегда в первом параметре 
получают скрытый аргумент 
this
, ссылающийся на объект, с которым произво-
дятся действия.
При проектировании типа следует стремиться свести к минимуму количество 
виртуальных методов. Во-первых, виртуальный метод вызывается медленнее невир-
туального. Во-вторых, JIT-компилятор не может подставлять (inline) виртуальные 
методы, что также ухудшает производительность. В-третьих, как показано далее, 
виртуальные методы затрудняют управление версиями компонентов. В-четвертых, 
при определении базового типа часто создается набор перегруженных методов. 
Чтобы сделать их полиморфными, лучше всего сделать наиболее сложный метод 
виртуальным, оставив другие методы невиртуальными. Кстати, соблюдение этого 
правила поможет управлять версиями компонентов, не нарушая работу производ-
ных типов. Приведем пример:
public class Set {
private Int32 m_length = 0;
// Этот перегруженный метод — невиртуальный
public Int32 Find(Object value) {
return Find(value, 0, m_length);
}
// Этот перегруженный метод — невиртуальный
public Int32 Find(Object value, Int32 startIndex) {
return Find(value, startIndex, m_length startIndex);
}
// Наиболее функциональный метод сделан виртуальным
// и может быть переопределен
public virtual Int32 Find(Object value, Int32 startIndex, Int32 endIndex) {
// Здесь находится настоящая реализация, которую можно переопределить...
}
// Другие методы
}
разумное использование видимости типов 
и модификаторов доступа к членам
В .NET Framework приложения состоят из типов, определенных в многочисленных 
сборках, созданных различными компаниями. Это означает практически полное 
отсутствие контроля над используемыми компонентами и типами. Разработчику 
обычно недоступен исходный код компонентов (он может даже не знать, на каком 
языке они написаны), к тому же версии компонентов обновляются в разное вре-
мя. Более того, из-за полиморфизма и наличия защищенных членов разработчик 
базового класса должен доверять коду разработчика производного класса. В свою 
очередь, разработчик производного класса должен доверять коду, наследуемому от 

---

203
Компоненты,.полиморфизм.и.версии
базового класса. Это лишь часть ограничений, с которыми приходится сталкиваться 
при разработке компонентов и типов.
В этом разделе я расскажу о том, как проектировать типы с учетом этих факторов. 
А если говорить конкретно, речь пойдет о том, как правильно задавать видимость 
типов и модификаторы доступа к членам.
В первую очередь при определении нового типа компиляторам следовало бы 
по умолчанию делать его запечатанным. Вместо этого большинство компилято-
ров (в том числе C#) поступают как раз наоборот, считая, что программист при 
необходимости сам может запечатать класс с помощью ключевого слова 
sealed
. 
Было бы неплохо, если бы неправильное, на мой взгляд, поведение, предлагаемое 
по умолчанию, в следующих версиях компиляторов изменилось. Есть три веские 
причины в пользу использования запечатанных классов.
‰