0

There is a lot of content on the web discussing if it is worth defining an interface if only one class implements it. The answers are mostly either "Yes, because you probably need to mock it anyways" or "No, I strongly believe in YAGNI".

But what about narrowing the classes public interface?

Example:

public interface Picture {
    public Dimension getSize();
    public void resize(Dimension d);
    // Some methods to retrieve byte data, etc
}

public class PictureImpl implements Picture {
    // Implement inherited methods
    public void setResizeStrategy(ResizeStrategy rs) { ... }
}

I intentionally do not add the setResizeStrategy(..) method to my interface, because i don't want other classes that accept a Picture object to change the strategy for resizing (think of linear upscaling vs using a technique such as antialiasing).

I essentially narrow the public interface of PictureImpl for the rest of my program, since it only uses the Picture interface (following the programming to an interface, not an implementation method).

I can then hide the actual PictureImpl construction in some kind of creating container, like a factory:

public class PictureFactory {
    public Picture createPicture() {
        PictureImpl p = new PictureImpl();
        // Search for a library that can resize pictures
        // If a library is found that we can support return the corresponding strategy
        // If no library is found, use our self coded linear upscale strategy
        ResizeStrategy strat = ResizeStrategyResolver.findBestStrategyAvailable();
        p.setResizeStrategy(strat);
        return p;
    }
}

Is this a valid use case for interfaces, or am i misusing the technology?

Note: I know that one could argue that changing the strategy during runtime might be a desired feature. I couldn't come up with a better example on the spot. I hope you get the point i am trying to make.

  • possible duplicate of Using interfaces as part of encapsulation – gnat Jul 14 '16 at 16:53
  • 1
    The question is really quite similar to mine, but since it only has downvoted answers of which none is accepted i would like a better answer if possible :) – Luca Fülbier Jul 14 '16 at 16:57
  • Does the technique you're asking about effectively solve a problem you're having in a real-world application? – Robert Harvey Jul 14 '16 at 17:05
  • 1
    @RobertHarvey: The "picture" example might not be the best. Consider the Repository Pattern. You create interfaces for your repositories to allow for easy mocking. Is it a good practice to split these interfaces up on, say, read-only behavior versus read/write behavior? That would be a similar example to illustrate this question. – Greg Burghardt Jul 14 '16 at 17:22
  • 1
    @Greg That is a way better example than mine. I program an library where the user is supposed to use a DataReceiver object. The interface only provides one method named getNextDataSet(). The implementation has a lot more setup/configuration methods. But since i provide Service Classes that return a pre-configured DataReceiver object i don't see the point in making that part of the implementation interface visible to them. – Luca Fülbier Jul 14 '16 at 17:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.