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

дилемма разработчика: базовый 
класс или интерфейс?
Меня часто спрашивают, что лучше выбирать для проектировании типа — базовый 
тип или интерфейс? Ответ не всегда очевиден. Вот несколько правил, которые 
могут помочь вам сделать выбор.
‰
Связь потомка с предком. 
Любой тип может наследовать только одну реа-
лизацию. Если производный тип не может ограничиваться отношением типа 
«является частным случаем» с базовым типом, нужно применять интерфейс, 
а не базовый тип. Интерфейс подразумевает отношение «поддерживает функ-
циональность». Например, тип может преобразовывать экземпляры самого 
себя в другой тип (
IConvertible
), может создать набор экземпляров самого 
себя (
ISerializable
) и т. д. Заметьте, что значимые типы должны наследовать 
от типа 
System.ValueType
и поэтому не могут наследовать от произвольного 
базового класса. В этом случае нужно определять интерфейс.

---

352
Глава.13 .Интерфейсы
‰
Простота использования.
Разработчику проще определить новый тип, произ-
водный от базового, чем создать интерфейс. Базовый тип может предоставлять 
массу функций, и в производном типе потребуется внести лишь незначительные 
изменения, чтобы изменить его поведение. При создании интерфейса в новом 
типе придется реализовывать все члены.
‰
Четкая реализация.
Как бы хорошо ни был документирован контракт, вряд 
ли будет реализован абсолютно корректно. По сути, проблемы COM связаны 
именно с этим — вот почему некоторые COM-объекты нормально работают 
только с Microsoft Word или Microsoft Internet Explorer. Базовый тип с хорошей 
реализацией основных функций — прекрасная отправная точка, вам останется 
изменить лишь отдельные части.
‰
Управление версиями. 
Когда вы добавляете метод к базовому типу, производ-
ный тип наследует стандартную реализацию этого метода без всяких затрат. 
Пользовательский исходный код даже не нужно перекомпилировать. Добавление 
нового члена к интерфейсу требует изменения пользовательского исходного 
кода и его перекомпиляции.
В FCL классы, связанные с потоками данных, построены по принципу насле-
дования реализации. 
System.IO.Stream
— это абстрактный базовый класс, предо-
ставляющий множество методов, в том числе 
Read
и 
Write
. Другие классы (
System.
IO.FileStream
, 
System.IO.MemoryStream
и 
System.Net.Sockets.NetworkStream
) 
являются производными от 
Stream
. В Microsoft выбрали такой вид отношений 
между этими тремя классами и 
Stream
по той причине, что так проще реализовывать 
конкретные классы. Так, производные классы должны самостоятельно реализовать 
только операции синхронного ввода-вывода, а способность выполнять асинхронные 
операции наследуется от базового класса 
Stream
.
Возможно, выбор наследования реализации для классов, работающих с пото-
ками, не совсем очевиден: ведь базовый класс 
Stream
на самом деле предоставляет 
лишь ограниченную готовую функциональность. Однако если взглянуть на классы 
элементов управления Windows Forms, где 
Button
, 
CheckBox
, 
ListBox
и все прочие 
элементы управления порождаются от 
System.Windows.Forms.Control
, легко пред-
ставить объем кода, реализованного в 
Control
; весь этот код просто наследуется 
классами элементов управления, позволяя им правильно функционировать.
Что касается 
коллекций
(collections), то их специалисты Microsoft реализовали 
в FCL на основе интерфейсов. В пространстве имен 
System.Collections.Generic
определено несколько интерфейсов для работы с коллекциями: 
IEnumerable
, 
ICollection
, 
IList
и 
IDictionary, 
TValue>
. Кроме того, Microsoft 
предлагает несколько конкретных классов (таких, как 
List
, 
Dictionary, 
TValue>
, 
Queue
, 
Stack
и пр.), которые реализуют комбинации этих интер-
фейсов. Такой подход объясняется тем, что реализация всех классов-коллекций 
существенно различается. Иначе говоря, у 
List
, 
Dictionary, 
TValue>
и 
Queue
найдется не так много общего кода.

---

353
Дилемма.разработчика:.базовый.класс.или.интерфейс?
И все же операции, предлагаемые всеми этими классами, вполне согласованы. 
Например, все они поддерживают подмножество элементов с возможностью пере-
бора, все они позволяют добавлять и удалять элементы. Если есть ссылка на объ-
ект, тип которого реализует интерфейс 
IList
, можно написать код, способный 
добавлять, удалять и искать элементы, не зная конкретный тип коллекции. Это 
очень мощный механизм.
Наконец, нужно сказать, что на самом деле можно определить интерфейс 
и
соз-
дать базовый класс, который реализует интерфейс. Например, в FCL определен 
интерфейс 
IComparer
, и любой тип может реализовать этот интерфейс. Кроме 
того, FCL предоставляет абстрактный базовый класс 
Comparer
, который реа-
лизует этот интерфейс (абстрактно) и предлагает реализацию по умолчанию для 
необобщенного метода 
Compare
интерфейса 
IComparer
. Применение обеих возмож-
ностей дает большую гибкость, поскольку разработчики теперь могут выбрать из 
двух вариантов наиболее предпочтительный.

---

---