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

часть функциональности. Если вспомогательные типы используются в един-
ственном супертипе, следует сделать их вложенными. Это позволит ссылаться на 
них через супертип и позволит им обращаться к защищенным членам супертипа. 
Однако существует правило проектирования, примененное в утилите 
FxCopCmd 
exe.
Visual Studio и рекомендующее определять общедоступные вложенные типы 
в области видимости файла или сборки (за пределами супертипа), поскольку 
некоторые разработчики считают синтаксис обращения к вложенным типам 
громоздким. Я соблюдаю это правило, и никогда не определяю открытые вло-
женные типы.
работа с виртуальными методами 
при управлении версиями типов
Как уже отмечалось, управление версиями — важный аспект компонентного про-
граммирования. Некоторых проблем я коснулся в главе 3 (там речь шла о сборках 
со строгими именами и обсуждались меры, позволяющие администраторам гаран-
тировать привязку приложения именно к тем сборкам, с которыми оно было по-
строено и протестировано). Однако при управлении версиями возникают и другие 
сложности с совместимостью на уровне исходного кода. В частности, следует быть 
очень осторожными при добавлении и изменении членов базового типа. Рассмотрим 
несколько примеров.
Пусть разработчиками компании 
CompanyА
спроектирован тип 
Phone
:
namespace CompanyA {
public class Phone {
public void Dial() {
Console.WriteLine("Phone.Dial");
// Выполнить действия по набору телефонного номера
}
}
}
А теперь представьте, что в компании 
CompanyB
спроектировали другой тип, 
BetterPhone
, использующий тип 
Phone
в качестве базового:
namespace CompanyB {
public class BetterPhone : CompanyA.Phone {
public void Dial() {
Console.WriteLine("BetterPhone.Dial");
EstablishConnection();
продолжение


---

206