Using interfaces as part of encapsulation

encapsulationinterfacesmocking

I'm creating interfaces for a number of our existing classes for mocking reasons. Many of these classes also have package scope methods as an attempt to give some level of encapsulation by ensuring only the controller can modify some of their state. I had thought I could use this change to try to get cleaner encapsulation as well.

My question is two fold. First, is it considered viable to use interfaces for encapsulation? I could make certain methods not in my interface that are available in the class. or I could have my IBar method have a getFoo method that returns an IFoo, but my bar class overrides getFoo to return a Bar. The problem is that anyone could easily cast my Ixxx to the actual class, so is it really considered a worthwhile encapsulation?

My second question has to do with my model. I would want my model to have some getAllFoo sort of methods that return IFoo objects. however, I want my controller to have a way to fetch the actuall Foo implementation (ie, know that my IFoo is of type Foo) so that it has access to methods not in the interface. What is considered the cleanest way to ensure my controller has access to the full class but other classes only see the interface? I asume just casting the interface to it's concrete class would be considered rather sloppy?

Best Answer

Whenever casting is a problem for encapsulation depends whenever you have Enabling or Directing attitude. For person with directing attitude, the fact that you can upcast to bypass the encapsulation is definitely a problem, so they probably won't see using an interface as proper encapsulation. But for person with enabling attitude, this is not a problem, because for them it is enough that interface tells programmer what methods are safe to use and that any programmer will be well aware of problems and risks that upcasting can bring and will not use it lightly.

There is also case of using public interface with private or internal class. Then the problem of upcasting goes away, because compiler won't allow access to the private class so you could upcast.

And lets not forget about reflection. Even if programmer is limited by encapsulation, reflection can usually get around it. So there is always a way to break encapsulation if programmer thinks it will solve his problems.

As for your model question. Where is the problem of keeping collection of Foo internally in controller but returning collection of IFoo to the outside world?

Related Solutions

C# Design – When to Use Abstract Classes vs Interfaces with Extension Methods

When you need a part of the class to be implemented. The best example I've used is the template method pattern.

public abstract class SomethingDoer
{
    public void Do()
    {
        this.DoThis();
        this.DoThat();
    }

    protected abstract void DoThis();
    protected abstract void DoThat();
}

Thus, you can define the steps that will be taken when Do() is called, without knowing the specifics of how they will be implemented. Deriving classes must implement the abstract methods, but not the Do() method.

Extensions methods don't necessarily satisfy the "must be a part of the class" part of the equation. Additionally, iirc, extension methods cannot (appear to) be anything but public in scope.

edit

The question is more interesting than I had originally given credit for. Upon further examination, Jon Skeet answered a question like this on SO in favour of using interfaces + extension methods. Also, a potential downside is using reflection against an object hierarchy designed in this way.

Personally, I am having trouble seeing the benefit of altering a currently common practice, but also see few to no downsides in doing it.

It should be noted that it is possible to program this way in many languages via Utility classes. Extensions just provide the syntactic sugar to make the methods look like they belong to the class.

Object-oriented – Why is Encapsulation considered a primary principle in OOP

I agree, those descriptions are really similar. But Abstraction is the idea of consolidating state and functionality into meaningful bundles. Encapsulation is about protecting that bundle so that an outsider can't come in, break the rules, and mess with your state.

The abstraction has exclusive domain over the state, and encapsulation is how we guarantee that.

Another side of encapsulation is that the implementation may be more complicated than the abstraction. So you might have a method (pseudocode):

List<Thing> getRelatedThings()

but internally, the list of Things isn't represented as a List at all. Maybe it's a complicated mess of data structures, from which you abstract a List.

Or maybe it is just a list of Things, but you want to be able to change your mind later. The abstraction stays the same, but encapsulation protects the implementation.

So another difference would be: abstraction strives to simplify, but encapsulation hides complication.

EDIT: one more thing... Encapsulation is an important aspect of decoupling. So let's say that I have two classes that are really similar. Without encapsulation, those abstractions might start to overlap and become more and more inter-twined over time. Encapsulation says, no, this abstraction is distinct from that abstraction.

If there is a common abstraction, factor it out & abstract a base class.

(although now you have two problems ;) ) (...sorry, thats a "favor composition over inheritance" joke. If that doesn't make sense, you'll get there.)

encapsulation keeps the boundaries of an abstraction distinct

Best Answer

Related Solutions

C# Design – When to Use Abstract Classes vs Interfaces with Extension Methods

Object-oriented – Why is Encapsulation considered a primary principle in OOP

Related Topic