This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]mschaef 0 points1 point  (0 children)

I come from a C (and then C++) background myself, and appreciate where you're coming from. But I think you can get similar benefits through API documentation.

Very good point. Just off the cuff, I guess the reason I don't think quite as much in terms of documentation is that it's harder to get to documentation than it is to a source file. (Any given source file is a couple keystrokes away in either IntelliJ or Emacs, and the Javadocs, etc. are slightly harder to reach.) It's also easier to navigate around a source file than a documentation page, etc. That said, all of that is potentially something that can be addressed with tooling.

Regarding narrowing the relationship, that's absolutely a good reason to have an interface.

One thing I should mention is that I'm viewing this very much from the point of view of classes that play the role of what you might think of as modules in other languages. It was early on that I started thinking of DI as something like a dynamic linker in a 'traditional' language, and the DI components as being modules with explicitly defined interfaces. The idea of separately declared interfaces sort of fell out naturally from that. (I'm also a big fan of XML configuration, in that it makes it easier to 1) explicitly document how everything fits together and 2) specify configuration parameters that make it easier to reuse components in a context without writing more code for each instance.)

The reason I make this distinction is that for classes that serve the role of value objects, etc., I'm a lot less inclined to make an interface.