Another use case where you might just have one implementor is to break circular dependency chains. You can have your module foo that depends on some core, and a module foo-api that depends only on what is needed to represent your interfaces, and now a module bar can depend on the core and foo-api and make use of services provided by foo. Similarly foo could depend on bar-api and make use of bar services, no issues now...
And testing as well. But I think the main idea is the contrast of thinking as interfaces as a asset or a cost. I think of interfaces as a cost you pay to get something better, like testability or circular dependency removal, back. But many developers and tech leads see interfaces as a good in and of itself, an asset that that pays dividends over the course of the project.
I'm super interested in hearing what you think are the advantages to that approach.
The cons I see are there are now two places where documentation needs to be kept in sync.
And reduced readability because of abstraction. For instances if I'm going through the mail chimp code base it's easier to understand how a mailcampaign interacts with the surrounding code base than something like iclickable. If I see a mailcampaign in code I instantly know what domain object it's represents, and have some idea a out what logic to expect in it. Iclickable I have no idea.
Im anxiously awaiting a thoughtful discussion of interfaces.
I'm not sure I understand your example; Does MailCampaign implement IClickable? Surely all the places you're seeing IClickable are places where the important activity somehow involves generalized clicking?
I would say that the subset of "good in and of itself" from interfaces -- ignoring those other benefits like multiple-implementations and extendable/reusable/mockable code -- usually relate to separating the mental task of defining what you wanted to exist versus what you were able to achieve so far.
In some ways an interface is similar to test-driven development, since it allows developers to create a scaffold of requirements and goals (interface methods and comments) before getting bogged down in the implementation details, and iteratively cycle between those two viewpoints.
In contrast, classes without an interface are at a higher risk for following a sort of least-effort evolution, such that someday a developer answers: "Why does it work that way? I dunno, that's just how we got it working."
> The cons I see are there are now two places where documentation needs to be kept in sync.
Ideally the in-file documentation is different though: The interface says "this method will take an X and create a new Y based on it", whereas the implementation communicates "I fulfill the interface's requirements by <stuff that makes me interesting and unique>."
True, that was not very constructive, apologies. However, I was comparing your criticism of the previous posters slight exaggeration of the name IClickable with the beauty that is FizzBuzzEnterprise.
Interfaces have many good uses in many situations, but by themselves, with one implementation, is not one of them. (note by themselves. Unit testing, multiple implementations, and so on are reasons beyond in and of themselves). And you can very well do the mental separation by coding without adding an unnecessary interface (unless it has other uses of course).
