Запечатывание класса - PullRequest
       1

Запечатывание класса

8 голосов
/ 08 декабря 2011

Запечатывание класса - это не то, на что я обращал большое внимание в прошлом, однако я задаюсь вопросом, что является лучшей практикой.Если вы знаете, что класс не будет или не должен быть производным, запечатайте его в качестве меры предосторожности, просто оставив запечатанное ключевое слово, зная, что шансы того, что кто-то попытается получить его, невелики.

Полагаю, что я спрашиваю: должны ли вы запечатать все классы, которые не предназначены для наследования, просто как вопрос хорошей практики?

Ответы [ 6 ]

4 голосов
/ 08 декабря 2011

В коде приложения, где весь код, производный от вашего класса, контролируется вами, я бы оставил большинство классов незапечатанными по умолчанию.Если вы нарушаете код, производный от вашего класса, изменяя базовый класс, вы можете просто исправить его.

Но запечатывание очень полезно в коде библиотеки.Если вы оставите класс незапечатанным, вы пообещаете не нарушать какой-либо код, производный от него.то есть вы увеличиваете свою общественную площадь.По умолчанию в библиотеках IMO площадь поверхности должна быть минимальной, что подразумевает запечатывание.

Но не всегда необходимо запечатывать весь класс.Этого может быть достаточно, чтобы запечатать некоторые или все виртуальные методы.Таким образом, код, производный от вашего класса, может только расширять его, но не изменять его текущие функциональные возможности путем переопределения метода.

Другой тип класса, который часто должен быть закрытым классом со семантикой значения.Гораздо сложнее реализовать правильное равенство и псевдо мутаторы для открытых классов.Поэтому я бы просто запечатал их и избегал дополнительной работы, если в этом нет особой необходимости.

4 голосов
/ 08 декабря 2011

Если вы придерживаетесь принципа открывать / закрывать для письма, запечатанное ключевое слово никогда не должно использоваться.Но я думаю, что всегда есть угловые случаи.

3 голосов
/ 08 декабря 2011

Я не собираюсь давать вам прямой ответ, но вот несколько вещей, которые следует учитывать:

Запечатанные классы могут дать вам (небольшое) преимущество в производительности. Смотрите эту тему:

Действительно ли запечатанные классы дают преимущества в производительности?

Запечатанные классы часто мешают распространенным средам моделирования, которые реализуются путем создания подклассов вашего кода.

Для дальнейшего чтения:

Почему в .Net существует ключевое слово «sealed»?

На практике я часто не опечатываю занятия.

2 голосов
/ 08 декабря 2011

Единственный раз, когда я замечаю, что класс запечатан, это когда мне действительно нужно извлечь что-то из него, но потом выяснить, что я не могу.

Я никогда не чувствовал необходимости запечатывать свои собственные классы. Я просто не думаю, что я достаточно умен, чтобы знать, когда класс никогда не должен быть выведен. Я довольно умен, но не могу предсказать будущее.

Для герметизации базовых классов .NET Framework может иметь смысл то, что они могут жестко контролировать поведение платформы, но я никогда не видел случая, чтобы это делал обычный разработчик. Возможно, вы захотите отказаться от получения класса, но его окончательная герметизация является окончательной, и кто знает, какими будут ваши потребности на следующей неделе / ​​месяце / году / продолжительности жизни?

2 голосов
/ 08 декабря 2011

Вы не должны произвольно запечатывать все классы, которые в любой момент времени не предназначены для наследования.

Вместо этого закройте классы, которые, как вы знаете, НИКОГДА не должны наследоваться, и оставьте остальные открытыми. Если в какой-то более поздний момент времени может быть принято решение, что эти классы НИКОГДА не наследуются, вы можете запечатать их.

0 голосов
/ 08 декабря 2011

Да, если вы хотите, чтобы ваш класс не был унаследован, просто добавьте ключевое слово "Sealed"Этот класс не может быть абстрактным, не может иметь защищенных или виртуальных методов / полей.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...