我应该公开组合对象吗？

Question

这里是这个设计的用途

我需要发布一些 API，以便外部世界可以配置用户及其服务。配置用户主要包括根据输入参数（如id、密码、级别等）创建新用户和创建新的连接对象。一旦创建了用户对象，就需要进行服务配置。这是一个两步过程 - 启用服务，修改服务细节。修改服务详细信息由一组操作组成。这些操作仅特定于该服务。对于其他服务，这些操作会有所不同。

这是我当前的实现

一个用户类由service_manager、connection、group类组成。 service_manager 类管理一组服务（比如 ServiceA、ServiceB ... ServiceN）。每个服务都有一个单独的类。

用户类有一个公共函数assignService。此函数需要一个参数，用于标识服务类。它返回相应服务类的对象。这是相同的伪代码。

serviceObjectA = user.assignService ('A');

稍后，此服务对象可用于执行特定该服务的操作。

serviceObjectA.performActionA1(...);
serviceObjectA.performActionA2(...);
serviceObjectA.performActionA10(...);

这是问题所在，我正面临着这个实现：

a) performAction 函数需要很少的用户类属性（如 id、密码、位置等）和连接对象。这些用户属性是准备请求所必需的。需要连接对象通过已创建的连接发送此请求。 目前，我在服务类构造函数中管理它，其中，我将这些用户属性和连接对象作为构造函数参数传递。它变得有点难以管理，因为各种服务类别需要不同的用户属性。

请提出一些替代方案。

b) 将服务对象暴露给外界真的是一种好习惯吗？

我还是 OOP 世界的新手，如果我理解不正确，敬请见谅。 如果你能用一个伪例子来演示它，我会非常棒。

Answer 1

解决您的一些问题的一种方法是关注builder pattern

因此，您不会使用包含越来越多的参数和构造函数的约定来适应所有这些不同的选项。您不需要在构造函数中提供所有必要的选项，而是有一个“构建器”类，可以使用所有需要的选项进行设置，然后构建（返回一个实例）您的正确设置的类。

这类似于另一个没有公共构造函数的选项，但没有静态工厂方法。如果您的构造函数变得难以区分并且参数失控，这些将很有帮助。拥有静态工厂方法意味着您可以使用方法名称更具描述性，并避免歧义和复杂性。有效的 Java 有几个与此相关的主题，对于更深入地讨论良好的设计模式是一本不错的读物。

不了解您的设计及其用途的更多信息，很难说什么应该公开，什么不应该公开。在我看来，最好让您班级的用户只与“用户”交互，从而隐藏操作由各种服务执行的事实。这使复杂性降低了一点，并允许以后根据需要更改实现。