My understanding of encapsulation is that only the object methods should interact with the state of the object. This is why a service object which has getters/setters breaks encapsulation. With regard to constructor I don’t think it break encapsulation, as you are not allowed to modify the state of the object, you only need to provide the state/dependencies on creation. In addition the callee is does not know how to create the dependency, it asks for it likewise.

Here is some more discussion I found online
http://stackoverflow.com/questions/1005473/must-dependency-injection-come-at-the-expense-of-encapsulation

But as we pass more and more parameters, does it not break encapsulation ? There could be problems related with improper use. So somebody may be able to pass an incorrect instance of creditcardprocessor that bypasses logging/auth ?

I’ve been playing with Apache wicket and ran into this problem. Here’s the scenario:

PageBorder – a border component that wraps around a BasePage and does stuff like setting title, meta etc.

class PageBorder extends Border {
public PageBorder (id, BasePage page){
this.page = page;
add (”title”, new Label(”title”, page.getTitle());
}
}

At the same time, since the BasePage contains the PageBorder, the BasePage needs to know about the border (create the border passing this as a ctor param)
public abstract class BasePage extends Page {
PageBorder border;
public add (Component c) {
if (border == null) {
border = getBorder();
// subclass must create a border passing themselves in
add (”border”, border);
}
border.add(c);
}
}

In this case, in the BasePage class, I’ve put a protected method – getBorder() – so that the implementing page can decide which border to create.

While this set up works, somehow this seems smelly.

OTOH, if I look at wicket itself, seems like this mutual knowledge is rampant (Page class has a getComponent) and Component classes have a getPage() – however, the coupling is lower.

Any suggestions?

Which one do you think is better? I think this one is way more truthful and gives the reader a better view to what is going on:
Mechanic(Engine e, Chassis c, Body b, Gearbox g, Paint p)

But I think you are trying to say, that there is way to much in the constructor, and I agree for you, so you should group them to logical groups and have
Mechanic(Powertrain p, Chassis c, Body b, Pain p);

But this example is a little flawed, since to make a mechanic you don’t should not need a car and paint, So I think the example you wanted to do was
Car(Powertrain p, Chassis c, Body b, Pain p);