4 ms·

This is wrong, bad advice, for the same reasons that structural typing is wrong and nominal typing is right. It goes against all OOP and modularity principles.

This is wrong, bad advice, for the same reasons that structural typing is wrong and nominal typing is right. It goes against all OOP and modularity principles. Interfaces should never be declared at the use site because an interface is a contract promised by the implementor. As for the example, it feels contrived and unprofessional. There should never be a monolithic "Backend" type. Functionality should be separated into services, each one with an interface, and each one injected dynamically for easy testability and upgradeability.

enriquto 7y ago
> It goes against all OOP and modularity principles. Sounds good to me, then!
- LessDmesg 7y ago
  I hate the flavour of OOP present in C++/Java/C# as much as the next man, but the principles are sound. Defining the interface at the user side is like a conflict of interest, like a kangaroo court. It's just bad architecture.
  - sagichmal 7y ago
    > Defining the interface at the user side is like a conflict of interest, like a kangaroo court. It's just bad architecture. You're wrong.
Nitramp 7y ago
> [this is wrong] because an interface is a contract promised by the implementor. I think the point the article makes is that you can instead think of an interface as a list of requirements demanded by a user (so your criticism here is a bit of a tautology). The article backs this up by describing concrete advantages of that approach. Maybe you could share why (or whether) you think these don't apply, or how they contrast with your preferred approach?
- LessDmesg 7y ago
  It's all in the books. Gang of Four, etc. Learn from good books instead of bloggers who have a type called "Backend" and make brilliant discoveries that DI and nominal typibg are bad despite the whole industry using them successfully.
  - Nitramp 7y ago
    > It's all in the books. Gang of Four, etc. No worries, I've read the usual suspects. Taking your example of Gang of Four though (and this applies similarly to the other usual suspects), it definitely does not discuss this observation (and potential trade offs), given it predates common use of structural type systems by far. I think as professional engineers it behooves us well to prefer actual argument and exposition of engineering tradeoffs over authority ("whole industry does it", "learn from good books").
    - jcelerier 7y ago
      > I think as professional engineers it behooves us well to prefer actual argument and exposition of engineering tradeoffs over authority ("whole industry does it", "learn from good books"). That really depends on what you want to achieve. e.g. if you want to retain the possibility to fire a whole team and replace it with newcomers, or external contractors, at any point in the development cycle, it is muuuuch safer to stick to what is taught in most schools (which is "tradtional OOP").
jayd16 7y ago
Whats the big deal? Structural typing explores the concept that the implementer contract and the user requirement is separate and tries to gain some composability out of that. You still have the public methods as the implementer contract.

enriquto 7y ago

> It goes against all OOP and modularity principles. Sounds good to me, then!

LessDmesg 7y ago
I hate the flavour of OOP present in C++/Java/C# as much as the next man, but the principles are sound. Defining the interface at the user side is like a conflict of interest, like a kangaroo court. It's just bad architecture.
- sagichmal 7y ago
  > Defining the interface at the user side is like a conflict of interest, like a kangaroo court. It's just bad architecture. You're wrong.

Nitramp 7y ago

> [this is wrong] because an interface is a contract promised by the implementor. I think the point the article makes is that you can instead think of an interface as a list of requirements demanded by a user (so your criticism here is a bit of a tautology). The article backs this up by describing concrete advantages of that approach. Maybe you could share why (or whether) you think these don't apply, or how they contrast with your preferred approach?

LessDmesg 7y ago
It's all in the books. Gang of Four, etc. Learn from good books instead of bloggers who have a type called "Backend" and make brilliant discoveries that DI and nominal typibg are bad despite the whole industry using them successfully.
- Nitramp 7y ago
  > It's all in the books. Gang of Four, etc. No worries, I've read the usual suspects. Taking your example of Gang of Four though (and this applies similarly to the other usual suspects), it definitely does not discuss this observation (and potential trade offs), given it predates common use of structural type systems by far. I think as professional engineers it behooves us well to prefer actual argument and exposition of engineering tradeoffs over authority ("whole industry does it", "learn from good books").
  - jcelerier 7y ago
    > I think as professional engineers it behooves us well to prefer actual argument and exposition of engineering tradeoffs over authority ("whole industry does it", "learn from good books"). That really depends on what you want to achieve. e.g. if you want to retain the possibility to fire a whole team and replace it with newcomers, or external contractors, at any point in the development cycle, it is muuuuch safer to stick to what is taught in most schools (which is "tradtional OOP").

jayd16 7y ago

Whats the big deal? Structural typing explores the concept that the implementer contract and the user requirement is separate and tries to gain some composability out of that. You still have the public methods as the implementer contract.