随着代码库的增长,这与在代码库中创建组件、可重用对象和代码维护有关。您的方法适用于小型应用程序,并且没有禁止它的规则。但是,通常根据推荐的常用方法创建包/文件结构可以更轻松地修改代码并与同一项目中的其他人一起工作。考虑以下几点:
如果您有许多活动分布在许多包或文件夹中,那么负责更改 UI 的人将不得不遍历这些包。这使得识别可以在 Activities 中使用的 UI 模式变得困难,甚至更难使用这些模式,因为您需要在每个包/文件夹中实现它们。
这也会产生一个问题,在非 UI 组件(如数据对象模型、视图控制器等)中看到不太明显的模式。例如,如果您需要在两个不同的 Activities 中创建一个“用户”对象,您是否会创建 2 个不同的对象?这不是可重用的代码。
假设您决定重用“用户”对象,这样您就只有 1 个类。那么你是否在其他需要它的包中子类化以遵循你的模式?那么如果一个 UI 元素需要一种新方法,你会在那个地方实现它吗?还是基础对象?
或者您是否公开了“用户”对象并从其他包/文件夹中引用它?如果这是您的答案,那么您将开始根据代码的演变在位置创建对象,而不是基于逻辑或易于维护。除此之外,这使得在你的代码库中训练一个新人“一切都在哪里”变得非常困难。 “用户”对象将位于一个位置,然后“用户帐户”对象最终出现在第一次需要它的位置,但不太可能与“用户”对象在一起。
随着一个项目增长到数百个类,我认为这种方法对于许多应用程序来说显然变得难以管理。类将根据 UI 要求出现在包中,而不是基于它执行的功能。维护它们变得具有挑战性。
例如,在 Lollipop 到 Marshmallow 的情况下,Apache http 已被弃用。如果您在整个项目中分散了这种依赖关系,那么您将在很多地方寻找如何处理这种变化。在一个可能很好的小项目上,但在一个较大的项目上,如果您在其他开发正在进行时尝试这样做,这可能会变得非常混乱,因为您现在正在跨许多包和文件夹而不是仅在几个位置进行修改.
但是,如果您有一个将行为封装在一个或多个文件夹中的数据访问层或模型层组件,那么您的更改范围就更容易让您周围的人看到。当您将更改合并到项目中时,与您一起工作的人很容易知道其他组件是否受到影响。
因此,虽然没有必要遵循这些准则(尤其是对于小型项目),但随着项目的发展和几个或很多人参与开发,您会看到变化,但一般做法是按目的或功能分组而不是按 UI / 视觉组件分组。如果您一开始就做好了其中的一些,那么您以后处理变化的工作就会减少。 (但是,在项目早期开始提供过多的结构性支持可能会使项目面临永远无法完成的风险......)
几个答案提供了指南的链接。我希望这个答案有助于解释为什么存在这些准则,我相信这是您问题的核心。