Объявляете ли вы каждый класс, от которого не собираетесь наследовать, sealed или на всякий случай оставляете возможность наследовать от него?

Здравствуйте, igna, Вы писали:

I>Объявляете ли вы каждый класс, от которого не собираетесь наследовать, sealed или на всякий случай оставляете возможность наследовать от него?

Объявляю sealed. Наследование (за исключением некоторых особых случаев) — зло.

Здравствуйте, igna, Вы писали:

I>Объявляете ли вы каждый класс, от которого не собираетесь наследовать, sealed или на всякий случай оставляете возможность наследовать от него?

Стараюсь. Но бывает что ленюсь/забываю.

Здравствуйте, igna, Вы писали:

I>Объявляете ли вы каждый класс, от которого не собираетесь наследовать, sealed или на всякий случай оставдяете возможность наследовать от него?

Кто использует эти классы? Команда проекта или сторонние разработчики (например фрэймворк)?
Если сторонние разработчики, то необходимо думать об обратной совместимости — если вы в 1-ой версии не объявите его sealed, то во 2-ой версии без breaking changes не получится отменить свое решение. Что-то подобное с виртуальными методами — делайте методы виртуальными только тогда, когда вы уверенны, что они должны быть виртуальными. То есть лучше быть more strict.

Здравствуйте, igna, Вы писали:

I>Объявляете ли вы каждый класс, от которого не собираетесь наследовать, sealed или на всякий случай оставляете возможность наследовать от него?

Добавлю. Класс, который позволяет наследоватся от себя (а таковым является каждый не-sealed класс), должен проектироваться с большим вниманием, с учётом обеспечения необходимых возможностей для наследников. Приходится, по сути, поддерживать два контракта — открытый, для пользователей, и защищённый, для наследников. Что бы сделать такую поддержку непротиворечивой, согласованной и безопастной надо продумать дизайн отдельно.

ИМХО, один из лучших примеров "хорошего" базового класса: Collection<T>. Попробуйте сами, не смотря на его реализацию, написать базовый расширяемый класс пользовательских коллекций и сравните.

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, igna, Вы писали:

I>>Объявляете ли вы каждый класс, от которого не собираетесь наследовать, sealed или на всякий случай оставляете возможность наследовать от него?

N>Объявляю sealed. Наследование (за исключением некоторых особых случаев) — зло.

IMHO, класс должен быть по умолчанию sealed и только явные действия разработчика должны переводить его в обратное состояние (методы по умолчанию невиртуальные, то есть по умлочанию расширяемость запрещена — к сожалению классы ведут себя иначе ).

Здравствуйте, igna, Вы писали:

I>Объявляете ли вы каждый класс, от которого не собираетесь наследовать, sealed или на всякий случай оставдяете возможность наследовать от него?

"Сделаю я, пожалуй, все методы виртуальными, чтобы обеспечить максимальную гибкость производным классам". Все чего он добился — это создание целого выводка вложенных ошибок, которые проявились позднее...
я уверен, что вы должны по умолчанию герметизировать(sealed) ваши классы...
(С)Трей Неш

Лично я пытаюсь не забывать добавлять sealed...)

Здравствуйте, igna, Вы писали:

I>Объявляете ли вы каждый класс, от которого не собираетесь наследовать, sealed или на всякий случай оставляете возможность наследовать от него?

Я разрешаю наследоваться от класса (и в таких случаях делаю мемберы виртуальными) только если наследование предполагается исходя из самого предназначения класса. В остальных — строго sealed.