Should programming according to the interface hide everything?
OOP is programming with an interface, not an implementation. Objects "talk" to each other using their interfaces. When interfaces are not defined correctly, one object may know too much about another, and if you need to change your object's implementation, you will need to change your program in different places. This is very bad, all about changing things in one place and DRY . So my question is this: what if to make a context interface. The interface context ensures that if an object provides multiple interfaces, other objects can only use the one they need. This will make work easier and less likely to make mistakes.
Let me give you an example: some abstract class that allows us to read text and write text. Thus, it has two interfaces: reader and writer. If you are dealing with a reader, all you need are reading methods. This way we can remove the recording interface. In the real world, you will still see the reader part (in an IDE like Visual Studio). But what if you do something that allows you to declare "I am in the context of the reader" and you can do something that is only reading, and each class shows you its own interface associated with the reader. What do you think? Does this make sense? How do add-ins to Visual Studio hide other interfaces if they are installed on one?
source to share
Take a look at Robert Martin's "Interface Principle" as well as the rest of SOLID's object-oriented design principles .
source to share
Yes, it often makes sense, especially when you start working more with inversion of control principles.
The easiest way to do this is to explicitly display the interface.
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.
}
}
The Foo method will only show up in the panel after you pass it to IFoo.
source to share
In Eclipse, you have a method called getAdapter()
that tries to turn an object into something else. So you can say:
Writer w = text.getAdapter(Writer.class);
The text can then determine how to turn itself into a Writer and create it for you. The next step is to have a registry of adapters, so you can say:
AdapterRegistry.instance().register(TextDocument.class,
new TextDocumentAdapterFactory ());
In TextDocument
you can say:
public Object getAdapter(Class c) {
AdapterRegistry.instance().createAdapter(this, c);
}
This way you can add adapters for existing objects later.
On the plus side, it makes your code extremely flexible. On the negative side, this makes the code impossible to debug, since you can't tell what getAdapter()
migth returns .
source to share