Обстоятельства, чтобы сделать окончательный класс?

Ответ 1

Создание финала класса только предотвращает его расширение, как вы заметили. Почему вы хотите это сделать?

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

• Вы также можете просто отметить класс как final, чтобы документировать тот факт, что он не предназначен для расширения. См. Например, "Эффективная Java # 17:" Дизайн и документ для наследования или запрет ").

Ответ 2

В идеале вы прочитали Джоша Блоха и разработали свой класс для отлично работающего наследования. Но на практике мой (IMHO) ответ на создание окончательного класса -

Доверяете ли вы (или хотите) его продлить?

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

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

Если вы не делаете ничего подобного, не раздражайте пользователей, делая его окончательным. Я часто проклинал Java для создания таких классов, как Double final.

Ответ 3

Хорошо известно, что наследование прерывает инкапсуляцию. Аллан Снайдер в своей статье Инкапсуляция и наследование в объектно-ориентированных языках программирования демонстрирует заботу, которую вы должны выполнять с наследованием.

Josua Bloch в своей книге Эффективная Java рекомендует вам разрабатывать и документировать ваши уроки, наследуемые, или же вы запрещаете это, точно ссылаясь на проблемы, уже известные Снайдеру.

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

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