3 ms·

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

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.

Terr_ 10y ago
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>."
- joshjje 10y ago
  Perhaps you could contribute to this open source project? https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
  - Terr_ 10y ago
    I had hoped for constructive or thoughtful replies, but yours is just trolling.
    - joshjje 10y ago
      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).

Terr_ 10y ago

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>."

joshjje 10y ago
Perhaps you could contribute to this open source project? https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- Terr_ 10y ago
  I had hoped for constructive or thoughtful replies, but yours is just trolling.
  - joshjje 10y ago
    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).