should I expose the composition object?

Question

Here is the use of this design

I need to publish some APIs so that the external world can configure the user and its services. Configuring the user mainly includes the creation of new user based on the input params (like id, password, level etc) and creating a new connection object. Once the user object is created, service configuration is required. It's a two step process - enabling service, modifying service details. Modifying service details is composed of a set of actions. These actions are specific to only that service. These actions will be different for other services.

Here is my current implementation

A user class is composed of service_manager, connection, group classes. service_manager class manages set of services (say ServiceA, ServiceB ... ServiceN). There is a seaparate class for each service.

user class has a public function assignService. This function takes an argument, required to identify the service class. It return an object of the respective service class. Here is an pseudo code for the same.

serviceObjectA = user.assignService ('A');

Later, this service object can be used to perform actions, specific to that service.

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

Here is the issue, I am facing with this implementation:

a) the performAction function needs few attributes of the user class (like id, password, location etc) and the connection object. These user attributes are required to prepare the request. The connection object is required to send this request over the already created connection. Currently, I am managing it in the service class constructor, wherein, I am passing these user attributes and connection object as the constructor arguments. It's becoming little bit unmanagable as various service classes require different user attributes.

Please suggest some alternative to this.

b) Is it really a good practice to exposing the service object to the outside world?

I am still new to the OOP world, so apologies if I understood anything incorrectly. I will be really great if you can demonstrate it with a pseudo example.

Answer 1

One way to solve some of your issues would be to follow the builder pattern

So you would not use the convention of including more and more parameters and constructors to suit all of these different options. Instead of requiring all the necessary options in the constructor, you have a "builder" class that can be set with all the desired options and then build (return an instance of) your class that is set up properly.

This is similar to another option of having no public constructors, but static factory methods. These are helpful if your constructors are getting hard to distinguish and the parameters are getting out of control. Having static factory methods means that you can be more descriptive with the method name and avoid ambiguity and complexity that way. Effective Java has several topics related to this, and would be a good read for more in-depth discussion of good design patterns.

Not knowing more about your design and its use, it's hard to say what should be exposed and what should not. It seems to me that it's better to have the users of your class interact only with the "User", hiding the fact that the actions are performed by various services. This keeps the complexity a little lower, and allows the implementation to change later if you want.