Заключительные классы на Java, которые не должны быть финальными или наоборот?

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

В частности, все их методы могут быть переопределены. Это позволяет вам создать сломанный BigDecimal, например:

public class BrokenBigDecimal extends BigDecimal {
    public BigDecimal add(BigDecimal augend) {
        return BigDecimal.ZERO;
    }
}    

Это может создать серьезные проблемы, например, если вы получите BigDecimal из ненадежного кода.

Перефразируя эффективную Java:

• Оформить и оформить на наследство или запретить его
• Классы должны быть неизменными, если нет веской причины сделать их изменяемыми.

java.awt.Dimension не является окончательным и неизменным, и должно было быть. Все, что возвращает Dimension (например, объект Window), должно создавать защитные копии, чтобы не дать вызывающим абонентам делать неприятные вещи.

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

Есть веские причины сделать Integer, Double и String всеми final.

Есть веские причины жаловаться на это.

Затем есть BitSet, BitInteger и т.д., которые можно было бы сделать final.

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

Чтобы выбрать конкретный класс: BitSet. Это не final, но вы не можете расширить его, добавив немного shift операции. С таким же успехом они могли сделать это final или позволить нам добавить такую ​​функциональность.

Выскакивает класс Date. Это изменяемый класс простых значений (по сути, оболочка для long), но хорошая эвристика состоит в том, что классы простых значений должны быть неизменяемыми. Также обратите внимание на многочисленные устаревшие методы: больше доказательств того, что дизайн был испорчен. Изменчивость Date является источником ошибок, требующих дисциплинированного защитного копирования.

тот, которого нет и должен быть

Большинство финальных классов в java спроектированы таким образом, что, учитывая соображения безопасности, в целом финальных классов относительно немного. Например, java.util.String является окончательным именно по этой причине. Как и многие другие. Некоторые классы с частным c-tor объявлены окончательными (Math, StrictMath), но в таком случае это не имеет значения.

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

Вкратце: я не могу придумать окончательный класс, которого не должно быть, однако есть некоторые, которые потенциально могли бы быть. Например, java.lang.Thread быть окончательным, возможно, не потребовалось для защиты от вредоносных clone().

Я считаю, что java.util.Arrays и java.util.Collections должны быть объявлены окончательными.

Вот почему:

1. Они содержат только статические члены и частный конструктор.
2. Частный конструктор предотвращает расширение этих классов.

Таким образом, эти классы не могут быть расширены, но этот факт не отображается в их общедоступном интерфейсе. Объявление их final раскрыло бы это и прояснило бы намерения.

Кроме того, java.lang.Math (другой так называемый служебный класс) имеет такую ​​же структуру и также объявлен final.

Отметьте класс String, который является окончательным и, вероятно, должен был стать вашим ответом на собеседовании.

Проверьте документы.

http://docs.oracle.com/javase/7/docs/api/java/lang/String.html