Почему многие классы API Android не являются окончательными, даже если они явно не задокументированы для наследования?

Question

Эффективная Ява (Джошуа Блох). Пункт 17 гласит:

«Дизайн и документ или наследство или иное запрещение»

Однако, лишь беглый взгляд на API Android показывает, что большинство классов API не являются окончательными; что нормально, если они также задокументированы для наследования (например, View из Activity). Но есть и несколько не финальных классов, но в документации не упоминается о наследуемости этих классов. Несколько примеров, иллюстрирующих мою точку зрения:

• Классы, представляющие системные службы (WifiManager, NotificationManager ...)
• Утилиты, такие как UriMatcher.
• Некоторые аппаратные классы, такие как Camera.

Открытость и расширяемость, являющиеся философией Android, не отменяется ли здесь соглашение? Это означает, можно ли предположить, что все классов API Android предназначены для наследования (явным образом задокументированы или нет); если не объявлено окончательным?

Answer 1

Только мои € 0,02: Чистый ОО-дизайн книги - это одно, заставить вещи работать на все возможные варианты использования на практике - это другое.Принципы чистого ОО-дизайна иногда носят академический характер.- И, может быть, немного черного и белого.

Подумайте, например, о , который использует API Android, предоставленный Google: не только разработчикам приложений, но и производителям устройств, которые нуждаются чтобы специализировать общие API-интерфейсы для своих устройств.

Так что для меня дизайн ПО в большинстве случаев не бывает ни черным, ни белым;важны оттенки серого.

И наконец: на практике я редко (читай: никогда ) не сталкивался с проблемами, вызванными "небрежно" пропущенными ключевыми словами final (в классах), в то время какнеотраженное чрезмерное использование final (часто вызванное такими мыслями, как «мой код sooo [здорово | некрасиво], никто на самом деле никогда не захочет изменить его с помощью наследования»)довольно больно.

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

Answer 2

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

Например, было бы гораздо сложнее создать поддельный WifiManager для целей создания модульных тестов, если бы он был завершен.Без финализации тривиально подкласс WifiManager (например, чтобы имитировать «неожиданное» отключение Wi-Fi во время работы) и вернуть экземпляр этого подкласса из настраиваемого тестирования Context.

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

В случае классов утилит ответ прост: утилита класса не уменьшается, позволяя разработчику создавать подклассы;во многих случаях разработчик может добиться более понятного повторного использования кода с помощью наследования, чем с помощью агрегации и делегирования.