Pass Objects or values as parameters to functions

Question

I'm working with JEE standard. I have the following layers: JPA (Eclipse Link), Data Access, Business Logic, and JSF (Primefaces). Primefaces uses MVC design pattern, so the the presentation layer contains the ManagedBeans (controllers).

When I create an object from an user request, must I contruct the object in the ManagedBean and pass it as the whole object to the logic, or should I pass the attributes of that object to the logic:

public void businessLogicMethod(String clientAttributeA, int clientAttributeB...)

or

public void businessLogicMethod(Client client)

I really can't make up my mind. Functionally, both options do the same... But are there any software quality advantages from one to the other? Is there any layer design reason to construct it in the controller or the model? Is there any other reason?

One of the advantages I see in the upper one is that the deployment diagram's services will have the parameters declared in the service interfaces, so there is much more information in the diagram.

Answer 1

But are there any software quality advantages from one to the other?

Programming is complex and so we try to do things that make it more manageable and maintainable.

One tool we have for that is abstraction. If we can abstract the relevant details and hide the implementation of those details that gives us an advantage, because we can consider fewer rules and issues, and things just work.

Whenever you can take several concepts and bundle them together into one single abstraction, you're getting advantage.

So, taking string, int and packaging that as a class Client is an abstraction that helps clients (no pun intended), often us, to write better software with fewer concerns and opportunities for error.

One issue with two separate parameters is that someone could confuse clientA string with clientB int. Bundled together, that can't happen.

Another issue with the code you're showing is that the primitive data types don't offer as high value type checking, so someone could confuse some other string value with the string for clientA. Bundled together as in a new abstraction (a new class, its own type) that won't happen.

The concept of providing a quality abstraction that is less error prone is at the heart of writing maintainable code.

One of the advantages I see in the upper one is that the deployment diagram's services will have the parameters declared in the service interfaces, so there is much more information in the diagram.

This is actually contrary to what we want. We want to hide implementation details so that future changes perturb the smallest possible code surface.

Is there any layer design reason to construct it in the controller or the model?

You should construct your abstractions (here of Client) at the earliest practical moment, when you have the various attributes altogether. After that, an (single) abstraction is the best packaging of those attributes.