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

Question

В последнее время я столкнулся с ситуацией, когда мне нужно было создать пользовательский VideoView для моего приложения для Android.Мне нужен был доступ к объекту MediaPlayer и добавить несколько слушателей.

К сожалению (для меня), все члены класса VideoView являются частными, поэтому даже расширение класса не помогло бы мне получить доступ к егоMediaPlayer объект (или что-то еще), мне пришлось сделать полную копию класса с моими модификациями.

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

Answer 1

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

РЕДАКТИРОВАТЬ: Безопасно использовать наследование, когда подкласс и суперкласс находятся под управлением одного и того же программиста, но наследование реализации может привести к хрупкому API.Как вы упомянули, если реализация суперкласса изменится, то подкласс может сломаться или, что еще хуже, будет совершать непреднамеренные действия молча.Другой подход состоит в том, чтобы иметь закрытое поле, которое ссылается на экземпляр существующего класса (VideoView), известный как состав, и каждый метод экземпляра в новом классе вызывает соответствующий метод на содержащемся экземпляре существующего класса и возвращает результаты.Этот подход обертки можно также назвать шаблоном «Декоратор»

Answer 2

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

Answer 3

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

Answer 4

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

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

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