Класс Java, содержащий только закрытые члены

Когда программист делает что-то приватным, он делает ставку на то, что никому другому никогда не понадобится использовать или переопределить это, и поэтому сокрытие информации принесет выгоду. Иногда эта ставка не срабатывает. Это перерывы.

Обычно в таких ситуациях я предпочитаю композицию наследованию.

EDIT:
Использование наследования безопасно, когда и подкласс, и суперкласс находятся под контролем одного и того же программиста, но наследование реализации может привести к нестабильности API. Как вы упомянули, если реализация суперкласса изменится, подкласс может сломаться или, что еще хуже, будет делать непреднамеренные вещи молча.

Другой подход заключается в том, чтобы иметь закрытое поле, которое ссылается на экземпляр существующего класса (VideoView), известное как композиция, и каждый метод экземпляра в новом классе вызывает соответствующий метод для содержащегося экземпляра существующего. класс и возвращает результаты. Этот подход-оболочка также может называться шаблоном «Декоратор».

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

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

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

Когда я прочитал все поучительные ответы (и комментарии) и комментарии к ним, я понял, что ожидал чего-то неуместного от некоторых классов. В случае примера VideoView fr этот класс уже является последним в цепочке наследования. Его не следует расширять, так как это одна логическая единица, очень конкретная и очень тесная, для очень конкретной цели. Мои потребности, чтобы получить специальные состояния из представления и MediaPlayer, были необходимы для целей контроля качества, и такие потребности действительно не следует учитывать при предоставлении продукта, который является закрытым блоком (хотя исходный код открыт). Это разумный аргумент, и я нахожу его удовлетворительным. Иногда не следует реализовывать каждую концепцию ООП. Спасибо всем за ответы.