Dependency Inversion Principle (SOLID) vs Encapsulation (Pillars of OOP)

Question

I was recently having a debate about the Dependency Inversion Principle, Inversion of Control and Dependency Injection. In relation to this topic we w

Answer 1

Does IoC always break encapsulation, and therefore OOP?

No, these are hierarchically related concerns. Encapsulation is one of the most misunderstood concepts in OOP, but I think the relationship is best described via Abstract Data Types (ADTs). Essentially, an ADT is a general description of data and associated behaviour. This description is abstract; it omits implementation details. Instead, it describes an ADT in terms of pre- and post-conditions.

This is what Bertrand Meyer calls design by contract. You can read more about this seminal description of OOD in Object-Oriented Software Construction.

Objects are often described as data with behaviour. This means that an object without data isn't really an object. Thus, you have to get data into the object in some way.

You could, for example, pass data into an object via its constructor:

public class Foo
{
    private readonly int bar;

    public Foo(int bar)
    {
        this.bar = bar;
    }

    // Other members may use this.bar in various ways.
}

Another option is to use a setter function or property. I hope we can agree that so far, encapsulation is not violated.

What happens if we change bar from an integer to another concrete class?

public class Foo
{
    private readonly Bar bar;

    public Foo(Bar bar)
    {
        this.bar = bar;
    }

    // Other members may use this.bar in various ways.
}

The only difference compared to before is that bar is now an object, instead of a primitive. However, that's a false distinction, because in object-oriented design, an integer is also an object. It's only because of performance optimisations in various programming languages (Java, C#, etc.) that there's an actual difference between primitives (strings, integers, bools, etc.) and 'real' objects. From an OOD perspective, they're all alike. Strings have behaviours as well: you can turn them into all-upper-case, reverse them, etc.

Is encapsulation violated if Bar is a sealed/final, concrete class with only non-virtual members?

bar is only data with behaviour, just like an integer, but apart from that, there's no difference. So far, encapsulation isn't violated.

What happens if we allow Bar to have a single virtual member?

Is encapsulation broken by that?

Can we still express pre- and post-conditions about Foo, given that Bar has a single virtual member?

If Bar adheres to the Liskov Substitution Principle (LSP), it wouldn't make a difference. The LSP explicitly states that changing the behaviour mustn't change the correctness of the system. As long as that contract is fulfilled, encapsulation is still intact.

Thus, the LSP (one of the SOLID principles, of which the Dependency Inversion Principle is another) doesn't violate encapsulation; it describes a principle for maintaining encapsulation in the presence of polymorphism.

Does the conclusion change if Bar is an abstract base class? An interface?

No, it doesn't: those are just different degrees of polymorphism. Thus we could rename Bar to IBar (in order to suggest that it's an interface) and pass it into Foo as its data:

public class Foo
{
    private readonly IBar bar;

    public Foo(IBar bar)
    {
        this.bar = bar;
    }

    // Other members may use this.bar in various ways.
}

bar is just another polymorphic object, and as long as the LSP holds, encapsulation holds.

TL; DR

There's a reason SOLID is also known as the Principles of OOD. Encapsulation (i.e. design-by-contract) defines the ground rules. SOLID describes guidelines for following those rules.