Должно ли программирование в соответствии с интерфейсом скрывать все?

Question

ООП - это программирование с интерфейсом, а не реализация. Объекты «разговаривают» друг с другом, используя свои интерфейсы. Когда интерфейсы не определены должным образом, один объект может слишком много знать о другом, и если вам нужно изменить реализацию вашего объекта, вам нужно будет изменить свою программу в разных местах. Это действительно плохо, все дело в том, чтобы что-то менять в одном месте и DRY принципах. Итак, мой вопрос заключается в следующем: что если сделать интерфейс интерфейса. Контекст интерфейса гарантирует, что если объект предоставляет несколько интерфейсов, другие объекты смогут использовать только тот, который им нужен. Это облегчит вещи и уменьшит вероятность ошибок.

Позвольте мне представить пример: некоторый абстрактный класс, который позволяет нам читать текст и писать текст. Так что у него два интерфейса: читатель и писатель. Если вы имеете дело с читателем, все, что вам нужно, это методы читателя. Таким образом, мы можем удалить интерфейс писателя. В реальном мире вы все еще будете видеть читателя (в таких средах, как Visual Studio). Но что если сделать такую ​​вещь, которая позволит вам объявить «Я в контексте читателя», и вы сможете делать вещи, связанные только с чтением, и каждый класс покажет вам свой интерфейс, связанный с читателем. Как вы думаете? Имеет ли это смысл? Как надстройки для Visual Studio, которая будет скрывать другие интерфейсы, если установлен один?

Answer 1

Да, это часто имеет смысл, особенно когда вы начинаете больше работать с принципами Inversion of Control.

Самый простой способ сделать это - явно реализовать интерфейс.

public interface IFoo
{
    void Foo();
}

public interface IBar
{
    void Bar();   
}
public class Baz : IFoo, IBar
{
    void IFoo.Foo()
    {

    }

    void IBar.Bar()
    {

    }
}

public class Program
{
    public void DoStuff()
    {
        Baz b = new Baz();
        //b.Foo(); // doesn't compile
        IFoo f = b as IFoo;
        f.Foo(); // works
        IBar bar = b as IBar;
        bar.Bar(); //now we an see that.
    }
}

Метод Foo будет отображаться на панели только после того, как вы приведете его к IFoo.

Answer 2

Ознакомьтесь с «Принципом интеграции интерфейсов» Роберта Мартина, а также с остальными Принципами SOLID объектно-ориентированного проектирования.

Answer 3

В Eclipse у вас есть метод с именем getAdapter(), который пытается превратить объект во что-то еще. Итак, вы можете сказать:

Writer w = text.getAdapter(Writer.class);

Тогда текст может понять, как превратить себя в писателя и создать его для вас. Следующий шаг - создать реестр адаптеров, чтобы вы могли сказать:

AdapterRegistry.instance().register(TextDocument.class,
                                    new TextDocumentAdapterFactory ());

В TextDocument вы можете сказать:

public Object getAdapter(Class c) {
    AdapterRegistry.instance().createAdapter(this, c);
}

Таким образом, вы можете добавить адаптеры для существующих объектов позже.

С другой стороны, это делает ваш код чрезвычайно гибким. С другой стороны, это делает код невозможным для отладки, так как вы не можете сказать, что в итоге getAdapter() migth возвращает.