Best practices for using interfaces in code, but hiding internal methods from end user

Question

Review the following model:

interface Context {
    BeanFactory getBeanFactory(); // public method
    void refresh(); // public method
    void destroy(); // public method
}

interface BeanFactory {
    <T> T getBean(String id); // public method
    void destroyBeans(); // should be private method for user, but visible for Context
}

class ContextImpl implements Context {
    private BeanFactory beanFactory;

    @Override
    public void destroy() {
        beanFactory.destroyBeans();
    }
}

ContextImpl uses BeanFactory interface, that's why method destroyBeans() is placed there. But I don't want it to be there, because it is internal API and should be hidden from user.

I thought of using AbstractBeanFactory reference with protected destroyBeans() method inside Context. That will solve the problem of exposing method to end user, but will replace the interface with abstract class.

Another variant is to make another interface, that will extend end-user interface, and use it inside Context. This will break the ability for user to create his own BeanFactory implentations.

I wanted to know if there is a well-known solution for the problem or just see another alternatives.

It does not make sense to me to have supposedly private methods in an interface. As the name suggests, it is an "INTERFACE", internal implementation (I mean private method) should NOT matter IMHO. — Alp, Jul 03 '15 at 19:28
You can have two interfaces, one containing the method `getBean()`, the other extends it and adds `destroyBeans()`. — biziclop, Jul 03 '15 at 19:32

biziclop · Accepted Answer · 2015-07-09T15:42:20.657

You can separate your user-facing methods into a user-facing interface, the rest in another one.

interface Context {
    BeanFactory getBeanFactory(); // public method
    void refresh(); // public method
    void destroy(); // public method
}

interface BeanFactory {
    <T> T getBean(String id); // public method
}

interface DestroyableBeanFactory extends BeanFactory {
    void destroyBeans(); // should be private method for user, but visible for Context
}

class ContextImpl implements Context {
    private DestroyableBeanFactory beanFactory;

    // internally we demand a DestroyableBeanFactory but we only
    // expose it as BeanFactory
    public BeanFactory getBeanFactory() {
        return beanFactory;
    }
    @Override
    public void destroy() {
        beanFactory.destroyBeans();
    }
}

Update: If you're worried about a caller casting your BeanFactory to DestroyableBeanFactory and calling destroyBeans() on it, you can return a read-only view instead:

class ContextImpl implements Context {
    private DestroyableBeanFactory beanFactory;

    // to be extra safe, we create a read-only wrapper
    // for our bean factory
    public BeanFactory getBeanFactory() {
        return new BeanFactory() { //written as an anon inner class for brevity, ideally you should cache this read-only wrapper instance
             public <T> T getBean(String id) { 
                 return beanFactory.getBean(id);
             }
        };
    }
    ...
  }

With this the only way to access the value of the beanFactory field is through reflection (or, optionally, serialization). But if you only want to defend against naughty developers cutting corners and not a malicious attacker, you should be fine.

Exposing the `BeanFactory` instead of `DestroyableBeanFactory` +1 — maskacovnik, Jul 03 '15 at 19:39
this is the best so far, but user can cast a reference and call a method. if we make the interface package local, user won't be able to create BeanFactory implementations. that's why I wanted to see other variants, that use another techniques, like helper classes, for example. — AdamSkywalker, Jul 03 '15 at 19:47
@AdamSkywalker At the end of the day the user can just use reflection to call any method. If you need to completely hide this, you can use composition instead of inheritance. I'll whip up an example of that too . — biziclop, Jul 03 '15 at 20:45
Though on second thought that would still allow a malicious client to access the private field `beanFactory` in `ContextImpl` via reflection. — biziclop, Jul 03 '15 at 21:44
@AdamSkywalker - don't worry about that. security concern is often overblown. very few applications need to worry about malicious code; such applications include browsers running javascripts; applet containers running applets; etc. — ZhongYu, Jul 04 '15 at 00:25

score 1 · Answer 2 · edited May 23 '17 at 11:54

Look at this question: Protected in Interfaces
This is about the protected methods, but there is well explained the problem.
I would use new abstract class as this:

abstract ABeanFactory {
    abstract <T> T getBean(String id);
    final void destroyBeans(){}
}

Or use second interface like this:

interface Context {
    BeanFactoryPrivate getBeanFactory();
    void refresh(); // public method
    void destroy();
}

interface BeanFactory {
    <T> T getBean(String id);
}

interface BeanFactoryPrivate extends BeanFactory{
    void destroyBeans();
}

class ContextImpl implements Context {
    private BeanFactoryPrivate beanFactory;

    @Override
    public void destroy() {
        beanFactory.destroyBeans();
    }
}

Not tested

Best practices for using interfaces in code, but hiding internal methods from end user

2 Answers2