Sunday, January 08, 2006

Bug or Feature

ImplicitInterfaceImplementation "What would it mean to implement an implicit interface? Essentially it would tell the type system that the ValuedCustomer class implements all the methods declared in the public interface of Customer but does not take any of its implementation, that is its public method bodies, and non public methods or data. In other words we have interface-inheritance but not implementation-inheritance."

InterfaceImplementationPair "Using interfaces when you aren't going to have multiple implementations is extra effort to keep everything in sync (although good IDEs help). Furthermore it hides the cases where you actually do provide multiple implementations."

Interfaces "Somewhat related to this is one of Robert Martin's Principles of Object-Oriented Design: "The Interface Segregation Principle", which says "Clients should not be forced to depend on methods that they do not use. Interfaces belong to client, not to hierarchies."

In a dynamic system like Smalltalk, Ruby, or Python, we don't need explicit interfaces, so "The Interface Segregation Principle" doesn't seem to apply. In static systems like Java and C++, one could declare interfaces specific to each client, but it seems that few people do.

The principle seems to more about dependency-breaking than anything else. I'd be interested in hearing from people who have actually done this extensively."

Implicit Interfaces "Of course Martin's suggestion would make it easier to use third party code without wrapping it up in a shim of your own. Personally I think it's a good thing to get in the habit of segregating third party code and putting it behind a thin, object based firewall of your own devising. The shim/wrapper code allows you to blend the alien API into your standard ways of doing things and gives you a chance to refine the abstraction that the third party API provides. Chances are their abstractions are in terms of the problem that they solve whereas yours should be in terms of the problem that you are solving and might only use a small part of the API... What's more, if you have slipped in an interface you can test without the third party code and you can, potentially, replace the third party code with other code if required..."

This last point is very much in line with my own experience and the point in A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT "Often we are encouraged, for economic reasons, to use software that was developed for some other
project...The resulting software may not be the ideal software for either project, i.e., not the software that we would develop based on its requirements alone, but it is good enough and will save effort."

No comments: