什么是组织服务层类的好方法？

Question

我的应用程序中有一个服务层，在一段时间内，只有一个类用于API调用

当前情景

MyAPI类

1. authenticateApp()
2. authenticateUser()

展望未来，这门课会非常庞大，很难维持下去。即使我按同一个模块对调用进行分组(用户身份验证、用户配置文件等)它会人满为患。

未来情景

MyAPI类

1. authenticateApp()
2. authenticateUser()
3. ..。
4. getSomeDataFromSomeModule()

为了避免这种情况，我应该如何以其他层不可见的方式在多个文件上创建模块？

像工厂方法或装饰模式这样的模式对我有帮助吗？还有其他我错过的模式可以解决这个问题吗？

Answer 1

展望未来，这门课会非常庞大，很难维持下去。即使我按同一个模块对调用进行分组(用户身份验证、用户配置文件等)它会人满为患。

也许是时候把这两个原则重构成多个类了：

• 按类别划分的最多5个公共方法(经验法则)
• 类只应该做一件事，但要做得很好(单一责任原则)

如果为了实现一个场景需要进行大量的方法调用，请考虑在门面中对它们进行重新分组。

Answer 2

您已经提到了模块，如果以这种方式对代码进行逻辑分组已经是有意义的，那么继续这样做。

拥有一个授予对模块的访问权限的守门对象可能是不可避免的，但每个模块将控制与其相关联的访问和功能。回到基础，并将其保持为干的，保持实心有助于描述这些高级模块。

就模式而言，构造模式是开始探索可能性的好地方。创造模式还应该提供从网关管理员访问模块的指导。