at Rogerio:

1)  “API” never refers to the public interface of a class, it refers to a well defined interface (that should be immutable) that is distributed for other people to use your class / subsystem.  This interface never, NEVER contains a constructor method, because the interface is not a class.  Hiding the details of object construction is one of the reasons you want to use an interface.  The object would be created through a Factory or Factory method, which should be designed well enough to handle changes to the object constructors. 

Your peppering of the discussion with mention of the “Separated Interface” enterprise pattern does nothing but add confusion.  The creation of many small, client specific interfaces (even in the same package) is not a bad thing;  it is actually encouraged by the Interface Segregation Principle of class design (google “Uncle Bob SOLID”).   

2) >>The interface of the base class (which may be abstract or not) is already a good enough abstraction.

Not if you need to add new functionality for other clients.  That is the whole point of ISP.

3) >>Unit tests (and I assume that “mocks” or “fakes” were meant) don’t need separate interfaces at all. With Java, it’s very easy….

You are making a very broad statement, and backing it up with a Java specific example.  Is providing mock implementations (in the absence of an interface) still easy in other languages like C++ / C#?

I am going to save the URL and will definitely visit again. Keep it up.

When I read that article, I saw it as supporting my case and refuting yours.

What Fowler wanted to do was basically extract an interface on Vector, for example, because Vector didn’t have an explicit interface. The Java library was designed incorrectly here and only allowed inheritance, not composition. You could only derive from Vector and change only the virtual things (which is probably most), but you still get some implementation whether you want it or not.

If the Java library designers had created IVector and created a default Vector, but only ever coupled to the abstraction (IVector), Fowler never would have had problems with this.

This problem is systemic in the .NET BCL as well.

http://martinfowler.com/bliki/ImplicitInterfaceImplementation.html

I will give more evidence to support my arguments. First, see this article by one of the GoF authors: http://www.artima.com/lejava/articles/designprinciples.html

Note the parts saying “This principle tells us that depending on an interface is *often* beneficial.”, and the other one saying “Fortunately, with today’s refactoring support you no longer have to come up with an interface up front. You can distill an interface from a concrete class once you have the full insights into a problem. The intended interface is just one ‘extract interface’ refactoring away.” And of course, he was talking about *separate* interfaces, not “interface” in the general sense. Again, it’s perfectly fine to create classes which only have implicit interfaces, and this does not violate the principle. The GoF authors never intended to encourage generalized creation of separate interfaces, but only in situations where up-front design is justified to achieve *reusable* code.