Does passing an aggregate object instead of a long

Question

I read that data coupling can be reduced by "not passing unnecessary arguments"

Say there is a makeCake method which requires many instance variables in the Ingredients class as parameters:

 makeCake(ingredients.flour, ingredients.egg, ingredients.sugar, ingredients.cheese, ingredients.cream)

And instead of this, just pass the whole Ingredients Object

 makeCake(ingredients)

and access the variables within the makeCake method..

---

Is this counted as reducing coupling between the class which calls the makeCake method and the Ingredients class? Before you were passing 5 arguments and now you're only passing one?

(Note that this question was made with the Java language - and the OO side of Scala - in mind)

(sorry if this question is making you crave cake, it was the first thing that popped into my head) :)

Answer 1

I think not so much.

I think a change in the format is not the idea.

Rather, if you passed an "ingredients id" and let the target look up what it needed....that would be less coupled.

Answer 2

see http://depfind.sourceforge.net/Manual.html#Dependencies:

... a dependency is when the functioning of one element A requires the presence of another element B. We say that A depends on B and we write it:

A --> B

We say that A has an outbound dependency while B has an inbound dependency. It is the same dependency, but whether it is inbound or outbound is relative to how you look at it. We also say that A is a dependent and B is dependable.

A dependency graph comprises nodes for software artifacts linked together using two types of relationships.

Artifacts are packages, classes, and features. We use the term feature to designate class attributes, constructors, and methods; we will be treating them the same from here on. For the purpose of analyzing dependencies, we do not distinguish between different types of features, whether they are constructors or regular methods, and regardless of the feature's characteristics, such as being marked as final or static.

The first type of relationship is composition. Packages have classes, which themselves have features. We call this kind of "has a" relationship composition. A feature node is linked to its class node through composition. A class node is also linked to its package node through composition.

The second type of relationship is dependency. Classes refer to each other, features refer to each other, and features refer to classes. We call this kind of relationship dependency. Each node is linked to various other nodes of various type using dependency links.