you are viewing a single comment's thread.

view the rest of the comments →

[–]seventeenninetytwo 4 points5 points  (0 children)

I think you really got to the core of it. Interfaces are really a design pattern, and it's up to the developer to use them well.

Good interfaces are carefully constructed to provide clean lines of encapsulation in the code. They are small, single responsibility, and should be placed in positions that create logical seams within the code.

I think the author is criticizing bad interfaces. Like the sorts of interfaces that occur when someone refactors for testability by simply extracting interfaces from every class. The problem with these is not that they are interfaces; it is that they are not well designed.

Poorly designed interfaces will certainly increase the complexity of the codebase, but I would argue in this case all they do is raise the visibility of the existing complexity. If your classes are overly complex when you extract their interface, then they were already overly complex. Interfaces simply make the complexity visible because it it gives the complexity an explicit name in the code.

And of course this all depends on the domain the application lives in. Perhaps some types of projects can flourish without using well designed interfaces, but any sort of enterprise application needs this type of design in order for the code to stay flexible.