Effective Java (Joshua Bloch) Item 17 说：
“设计和记录或继承或禁止它”
但是，只要粗略浏览一下 Android API，就会发现大多数 API 类都不是最终的。如果它们也被记录为继承（例如），那是可以View的。Activity但是也有几个非最终类，但是文档没有提到这些类的可继承性。只是一些随意的例子来说明我的观点：
WifiManager, NotificationManager...)UriMatcher.Camera.开放性和可扩展性是 Android 的哲学，这里的约定是否颠倒了？意思是，可以假设所有Android API 类都被设计为可继承的（无论是否明确记录）；除非宣布最终？
Android 开发人员竭尽全力确保可扩展性（虽然在许多情况下不推荐）是可能的。这背后的动机似乎与测试环境有关。
WifiManager例如，如果最终确定，为了创建单元测试的目的而创建一个仿制品会困难得多。WifiManager如果没有最终确定，子类化（例如，在操作期间模拟“意外”的 wifi 断开连接）并从自定义测试返回这个子类的实例是微不足道的Context。
因此，虽然您可能永远找不到在交付给最终用户的应用程序中实现这些类的子类的理由，但如果出于某种原因需要，您可以灵活地扩展它们。
在实用类的情况下，答案很简单，即允许开发人员进行子类化并不会削弱类的实用性；在许多情况下，开发人员可以通过继承实现比聚合和委托更易于理解的代码重用。
只是我的 0.02 欧元：本书中的清洁 OO 设计是一回事，在实践中让所有可能的用例都适用是另一回事。干净的 OO 设计原则有时有点学术性质。- 也许有点黑白。
例如，想想谁在使用 google 提供的 Android API：不仅应用程序开发人员，而且设备制造商都需要为他们的设备专门化通用 API。
所以，对我来说，在大多数情况下，SW 设计既不是黑白的，也不是黑白的。灰色的阴影很重要。
最后：在实践中，我很少（阅读：从未）看到由“粗心”省略final关键字（在类上）引起的问题，而未反映的过度使用final（通常是由诸如“我的代码太[伟大|丑陋]之类的想法引起的，没有人实际上会想通过继承来修改它”）可能会很痛苦。
“我知道我一无所知”似乎适合这里：声称一个人预先知道其他人的所有疯狂、巧妙、创造性、聪明……关于如何使用自己的代码的想法是自以为是的。