我应该公开构图对象吗？

这里是使用这种设计我应该公开构图对象吗？

我需要发布一些API，以便外部世界可以配置用户及其服务。配置用户主要包括基于输入参数（如id，密码，级别等）创建新用户并创建新的连接对象。一旦用户对象被创建，服务配置是必需的。这是一个两步的过程 - 启用服务，修改服务细节。修改服务细节由一组操作组成。这些操作仅针对该服务。对于其他服务，这些操作将有所不同。

这是我目前的执行

用户类是由service_manager，连接，组班。 service_manager类管理一组服务（比如ServiceA，ServiceB ... ServiceN）。每项服务都有一个海水班。

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

serviceObjectA = user.assignService ('A');

后来，这个服务对象可用于执行操作，具体该服务。

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

这里是问题，我面临着这样实现：

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

请为此建议一些替代方案。

b）将服务对象暴露给外部世界真的是一种很好的做法吗？

我还是OOP世界的新手，很抱歉，如果我理解错误的话。如果你可以用伪示例来演示它，我将会非常棒。解决你的一些问题

来源

2012-07-31 rpg

一种方式是遵循builder pattern

所以你不会使用，包括越来越多的参数和施工的惯例，以满足所有这些不同的选择。您不需要构造函数中的所有必要选项，而是可以使用所有期望的选项设置“构建器”类，然后构建正确设置的类（返回实例）。

这与另一个没有公共构造函数但静态工厂方法的选项类似。如果你的构造函数越来越难辨别并且参数失控，这些将会很有帮助。拥有静态工厂方法意味着您可以更方便地描述方法名称，并避免模糊性和复杂性。有效的Java有几个与此相关的主题，对于更好的设计模式的深入讨论将是一个很好的解读。

不知道更多关于您的设计和使用，很难说什么应该暴露，什么不应该。在我看来，最好让你的班级的用户只与“用户”进行交互，隐藏这些操作由各种服务执行的事实。这可以使复杂性降低一些，并且可以在稍后根据需要更改实现。

来源

2012-07-31 18:30:18 Carl

感谢您的回复。关于我的设计和使用。我希望这些服务能够为外界揭露。但我有点怀疑我是否应该通过用户对象或服务对象公开这些performAction函数。 – rpg 2012-08-01 01:09:08

我已经更新了描述使用此设计的问题。请看看这些词。请帮我说明我是否需要将这些服务对象暴露给外部世界？ – rpg 2012-08-01 13:50:25

因此，听起来好像根据使用哪种服务会有不同的操作，并且只有一种服务可以被用户使用？我的第一个想法是，尝试通过用户来隐藏所有的API可能不是一个好主意，因为它们中的很多不会被应用，因为它们是特定于该用户无法使用的其他服务的。或者用户可以使用多种服务，但是每个服务在使用前都必须先设置好？ – Carl 2012-08-01 16:43:13

我应该公开构图对象吗？

回答

相关问题