|
Управление версиями.
Если класс изначально запечатан, его впоследствии
можно сделать незапечатанным, не нарушая совместимости. Однако обратное не-
возможно, поскольку это нарушило бы работу всех производных классов. Кроме
того, если в незапечатанном классе определены незапечатанные виртуальные
методы, необходимо сохранять порядок вызова виртуальных методов в новых
версиях, иначе в будущем возникнут проблемы с производными типами.
Производительность.
Как уже отмечалось, невиртуальные методы вызываются
быстрее виртуальных, поскольку для последних CLR во время выполнения
проверяет тип объекта, чтобы выяснить, где находится метод. Однако, встре-
тив вызов виртуального метода в запечатанном типе, JIT-компилятор может
сгенерировать более эффективный код, задействовав невиртуальный вызов.
Это возможно потому, что у запечатанного класса не может быть производных
классов. Например, в следующем коде JIT-компилятор может вызвать вирту-
альный метод
ToString
невиртуально:
using System;
public sealed class Point {
private Int32 m_x, m_y;
public Point(Int32 x, Int32 y) { m_x = x; m_y = y; }
public override String ToStringO {
return String.Format("({0}, {1})", m_x, m_y);
}
public static void Main() {
Point p = new Point(3, 4);
// Компилятор C# вставит здесь инструкцию callvirt,
// но JIT-компилятор оптимизирует этот вызов и сгенерирует код
// для невиртуального вызова ToString,
// поскольку p имеет тип Point, являющийся запечатанным
Console.WriteLine(p.ToString());
}
}
204
Глава.6 .Основные.сведения.о.членах.и.типах
Безопасность и предсказуемость.
Состояние класса должно быть надежно
защищено. Если класс не запечатан, производный класс может изменить его
состояние, воспользовавшись незащищенными полями или методами базового
класса, изменяющими его доступные незакрытые поля. Кроме того, в произво-
дном классе можно переопределить виртуальные методы и не вызывать реали-
зацию соответствующих методов базового класса. Назначая метод, свойство
и событие виртуальным, базовый класс уступает некоторую степень контроля
над его поведением и состоянием производному классу, что при неумелом обра-
щении может вызвать непредсказуемое поведение и проблемы с безопасностью.
Беда в том, что запечатанные классы могут создать изрядные неудобства для
пользователей типа. Разработчику приложения может понадобиться производный
тип, в котором будут добавлены дополнительные поля или другая информация
о состоянии. Они даже могут попытаться добавить в производном типе дополни-
тельные методы для работы с этими полями. Хотя CLR не предоставляет механизма
расширения уже построенных типов вспомогательными методами или полями,
вспомогательные методы можно имитировать при помощи методов расширения
C# (см. главу 8), а для расширения состояния объекта может использоваться класс
ConditionalWeakTable
(см. главу 21).
Вот несколько правил, которым я следую при проектировании классов:
Если класс не предназначен для наследования, я всегда явно объявляю его
запечатанным. Как уже отмечалось, C# и многие современные компиляторы
поступают иначе. Если нет необходимости в предоставлении другим сборкам
доступа к классу, он объявляется внутренним. К счастью, именно так ведет себя
по умолчанию компилятор C#. Если я хочу определить класс, предназначенный
для создания производных классов, одновременно запретив его специализацию,
я должен переопределить и запечатать все виртуальные методы, которые на-
следует мой класс.
Все поля данных класса всегда объявляются закрытыми, и в этом я никогда не
уступлю. К счастью, по умолчанию C# поступает именно так. Вообще говоря,
я бы предпочел, чтобы в C# остались только закрытые поля, а объявлять их
со спецификаторами
protected
,
internal
,
public
и т. д. было бы запрещено.
Доступ к состоянию объекта — верный путь к непредсказуемому поведению
и проблемам с безопасностью. При объявлении полей внутренними (
internal
)
также могут возникнуть проблемы, поскольку даже внутри одной сборки очень
трудно отследить все обращения к полям, особенно когда над ней работает не-
сколько разработчиков.
Методы, свойства и события класса я всегда объявляю закрытыми и невирту-
альными. К счастью, C# по умолчанию делает именно так. Разумеется, чтобы
типом можно было воспользоваться, некоторые методы, свойства и события
должны быть открытыми, но лучше не делать их защищенными или внутрен-
ними, поскольку это может сделать тип уязвимым. Впрочем, защищенный или
205
Компоненты,.полиморфизм.и.версии
внутренний член все-таки лучше виртуального, поскольку последний предо-
ставляет производному классу большие возможности и всецело зависит от
корректности его поведения.
В ООП есть проверенный временем принцип: «лучший метод борьбы со слож-
ностью — добавление новых типов». Если реализация алгоритма чрезмерно
усложняется, следует определить вспомогательные типы, инкапсулирующие
Do'stlaringiz bilan baham: |
