Encapsuling Attributes in Management Objects and Interfaces

Question

I am considering to encapule certain "not very often accessed" attributes and functionalities into their own "config" and "extended" - Objects within the data structure, so that I can offer to user defined callback functions an object of a type that only gives access to the most commonly used functions and attributes and offering a "getExtended" method that returns the same object with another type that offers uncommonly used functions.

This idea is mostly based around having a slim list of auto-completion friendly functions so that development with IDEs like Eclipse flows more smoothly when writing code using the most commonly used methods of the offered object, and not having to filter out the methods that are mostly used to do one-time configuration at a very specific place in the code.

Am I falling here into an obvious anti-pattern trap or is this actually a good way to lay out the structure of an easy to use lib?

score 0 · Answer 1 · answered Mar 17 '15 at 17:28

One way to do this is to use interfaces. Interfaces can be extended through inheritance just like classes. Your collection could reference a base interface, say ISimple like below. Your getExtended() could return the IAdvanced interface. Both could be implemented by the same object (if they share identity and purpose), or by different objects. The decision of whether to implement together or not should really be based on the Single Responsibility Principle. Here is some sample code:

interface ISimple {
  IAdvanced getAdvanced();
  int getLength();
  String getName();
}

interface IAdvanced extends ISimple {
  void verifyAllTheThings();
}

class Implementation implements IAdvanced {

  public IAdvanced getAdvanced() { return this; }

  // ISimple
  public int getLength() { return 2; }
  public String getName() { return "something"; }

  // IAdvanced
  public void verifyAllTheThings() { /* do stuff */ }
}

I think you really are asking if this is a bad pattern or not. In and of itself it is not a bad pattern (IMHO), but there is different design problem implied by your question. If your motivation of being friendly with IDE's is because there are are a huge number of methods on each object, then that is possibly a questionable design. Again, the Single Responsibility Principle is a good guide to tell you if your object is doing too much, and should be split apart into separate concerns. If so, then doing a simple/extended split is a possibly weak way to divide up the set of all methods, and instead you might want to consider breaking up the object along more conceptual lines.

score 0 · Answer 2 · edited May 23 '17 at 12:12

Duane already get to the point, but sadly missed the mark with using the interface. An interface can be inherited but not always need to. And yes, using interface to limit the method accessibility is the right way to do it.

As example, actually you can:

interface ITwoDimensional {
  int getWidth();
    int getLength();
}

interface IThreeDimensional extends ITwoDimensional {
    int getHeight();
}

interface ISpherical{
    int getRadius();
}

class Consumer{
    int calculateArea(ITwoDimensional a){
        // you can only access getLength() and getWidth();
    }
    int calculateArea(ISpherical a){
        // you can only access getRadius();
    }
    int calculateArea(IThreeDimensional a){
        // you can access getLength(), getWidth() and getHeight();
    }
}

That is only the basic example. There are many more design available with interface access.

Encapsuling Attributes in Management Objects and Interfaces

2 Answers2