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?

  • 1
    Related: stackoverflow.com/questions/1863479/…
    – Doc Brown
    Feb 26, 2014 at 20:19
  • 2
    It's not a full answer, but there are two types of encapsulation. There's the kind where you design the algorithm to be used properly, and the kind where you actively try to prevent malicious users from using it improperly. For most non-security related tasks, it is fair to assume that users will not arbitrarially cast their objects.
    – Cort Ammon
    Feb 27, 2014 at 3:50
  • 1
    What is wrong with a new interface for the controller?
    – User
    Apr 5, 2014 at 13:11

2 Answers 2


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?

  • Something is either encapsulated, or it is not. There is no relative perspective. May 1, 2014 at 3:17
  • @FrankHileman So you have directing attitude. You are taking encapsulation as something that needs to be rigorously enforced. Not as way to hint at proper usage.
    – Euphoric
    May 1, 2014 at 5:03
  • @Euphonic it is also a hint, if you don't see something? I believe encapsulation does serve an important purpose, just as strong typing and other compile time directives do, yes. May 1, 2014 at 5:32
  • @Euphonic I am reminded of the two types of faces: horse or pie. Put that way, neither is especially flattering :). May 1, 2014 at 5:34

The interface provides no encapsulation advantage if you need to cast to the class to be able to use an object, or if the class is public, rather than internal or privately nested in another class.

To give your controller access to members that are not available to other classes, you must either make Foo a private nested class within the controller class, making it invisible even within the same assembly, or make Foo an internal class, making it invisible outside the assembly.

My advice is to avoid interfaces as much as possible, and use them only in cases where you need the advantages of multiple inheritance, as it is the only form of multiple inheritance allowed (yes it is not true inheritance, but the idea is the same). Use base classes as much as possible. This will make it easier for others to read and navigate your code. For encapsulation, try to put related classes in the same assembly, so some of them can be internal, and some members can also be internal.

Choosing between Class and Interface in the Framework Design Guidelines book has more information.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.