我将MainActivity的责任分开并尝试通过扩展BaseActivities来保持其清洁和可读性，例如MainActivity扩展AdBaseActivity扩展LocationBaseActivity扩展FullScreenActivity扩展Activity。
每个活动只关注它们的命名，同时保持MainActivity设置布局和视图，并为任务运行主对象，如GameSurfaceView或它应该运行的主类。关于耦合和内聚，难以测试或来自任何其他设计原则方面，这是一种糟糕的编程实践吗？
是否正在使用一个类，例如LocationController需要所有生命周期方法并实例化或使用依赖注入，这比扩展BaseActivities更好？
我想知道如何在需要权限的情况下维护具有Activity所需的回调的Manager类，并且例如，应该如何使用DialogFragment或任何其他视图，或者返回另一个Activity的结果？这些管理器类可以是其他类的成员，并且对Activity的更深层引用可能会导致内存泄漏，如果这种情况只能进行，则可能很难检测到 当管理器类处于阻止不释放Activity引用的特定状态时发生。
答案 0 :(得分：1)
<强> TLDR;
是，不！
继承和所有OOP原则对于可读性和代码管理非常有效，但由于您正在开发移动应用程序，因此太多类可能会降低内存和性能。
我明白你要做什么以及为什么。在编写一个相当大的Android应用程序时，我有一段时间遇到同样的问题。
因为它基本上是一个Activity个应用，其中包含4个Fragments我的MainActivity中的代码太多了，即使将一些代码委托给我的Fragments也是如此。
然后我改变了我的MainActivity并通过合成使其拥有以下Manager类：
LocationManager ApiVendorManager UIManager BackgroundJobManager AppFunctionalityManager StageTransitionManager 每个包含 800 + 行代码和生命周期回调（onCreate()，onPause()，...）。
在那之后，我的MainActivity非常干净整洁，我为自己感到骄傲，但我发现性能急剧下降。
然后我偶然发现了documentation page这句话：
但是，抽象的成本很高：通常它们需要更多的代码才能执行，需要更多的时间和更多的RAM才能将代码映射到内存中。
我最后做的是在抽象和效果之间找到一些平衡，只保留4 Managers。
我会说：继续抽象，直到您发现性能问题。那是你应该考虑限制继承和组合的时刻，甚至可能重新合并一些以前扩展的类。
同样的原则适用于扩展您的Activity类。
答案 1 :(得分：1)
这取决于目标项目。如果你想获得可重用性的好处。那么这不是一个好习惯，因为拆分依赖关系并不容易。但是如果你不打算再次重复使用代码并且你的东西相对较小..那么它可能不会那么糟糕，有时这是以继承风格管理逻辑的唯一方法。
但还有另一种方式......作文！
请参阅：Difference between Inheritance and Composition
组合是has-a关系，而继承是is-a。实际上，当继承很重要时，组合就是出口门。
使用像Dagger这样的依赖注入器来应用composition，可以在可读性，可重用性和可扩展性方面提供高质量的代码。
答案 2 :(得分：0)
耦合是OOP的基本关键，并没有“通过耦合做错”这样的事情。您希望尽可能地封装，并且每当您觉得您第二次使用相同的代码时，请使用耦合。
另请参阅此问题以获得有关您附近主题的更多说明：Is there such thing as too many classes?