5 ms·

I suppose this is the money quote: > Please note that I’m not saying that interfaces are always bad. When they add value, they are useful. I’m only saying that

I suppose this is the money quote: > Please note that I’m not saying that interfaces are always bad. When they add value, they are useful. I’m only saying that interfaces that mirror one and only one class implementation is waste. That's not really controversial or interesting. "Don't write interfaces that have only one implementation" is something I've heard many times. The only well-accepted exception to that rule is interfaces that are expected to be implemented by, say, users of a library you are writing.

deleted 10y ago
[deleted]
jpitz 10y ago
I don't find it controversial, and it isn't altogether interesting, but I would like it if it were better communicated. I've cleaned up code that dogmatically followed a interface-per-class policy.
dibujante 10y ago
I have worked at shops where, without fail, EveryClass : IEveryClass
- mpeg 10y ago
  Because, of course, you might expand it later. Sure, I'm adding this shitty console based logger, but since it's wrapped in ILogger I'll later come and write a FileBasedLogger, a DBLogger and a KafkaProducerLogger for when we go webscale. Except, that never happens.
  - BatFastard 10y ago
    Then you go back and refactor the code to pull out the interface! I so hate interface abuse.
    - sanderjd 10y ago
      If you use names like Logger instead of ILogger, you don't even have to change all the names when you refactor to an interface! If you end up wanting a FileBasedLogger, you just rename the current implementation to StdoutLogger, create a Logger interface, create a FileBasedLogger, and change instantiation sites to build the instance you want.
      - reitanqild 10y ago
        Using IClass naming is considered best practice in the .Net world AFAIK. (I think Visual Studio and/or Resharper hints very clearly about this.)
        sanderjd 10y ago
        I know, I'm demonstrating one reason I think that's a bad best practice :) I recognize there's nothing most people can do about that, though!
        hota_mazi 10y ago
        > Using IClass naming is considered best practice in the .Net world AFAIK. No, it's the opposite. IClass is the norm, for legacy reasons going all the way back to the early COM days (it all started with IUnknown[1]). [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
      - hota_mazi 10y ago
        > If you use names like Logger instead of ILogger, you don't even have to change all the names when you refactor to an interface! But you want to, that's the point. You're making a drastic change to your code base, surely you want to inspect every place where that type is used.
  - dibujante 10y ago
    //Names changed slightly to protect the wicked public interface IProvideBoolean { Boolean True { get; } Boolean False { get; } } public class BooleanProvider : IProvideBoolean { public Boolean True => true; public Boolean False => false; } So.... SOLID.... If there's ever a third value for Boolean, I Will Be Ready.
    - Ygg2 10y ago
      Finally ready for trinary computing!
    - breakingcups 10y ago
      See also: https://thedailywtf.com/articles/What_Is_Truth_0x3f_ https://thedailywtf.com/articles/What_Is_Truth_0x3f_
- Ace17 10y ago
  There are some (rare) occasions, when private members drag new dependencies that you don't want the user of your class to know about. You can also do "pImpl", which is similar, if not worse, in terms of boilerplate, but doesn't allow DI. Just don't use these techniques unless you can prove they're needed (e.g private members drag new problematic dependencies, #include <some_volatile_header_file.h>).
jsarasti 10y ago
It's quite controversial in the real world where "each service class has an interface" is official codified dogma. OTOH in certain specific cases I see the value of the interface even for just one class when I want to clearly separate the contract (which I'm bound to fulfill now and in the future) and the implementation specific comments. Let's say that in my little pet programming language I have just one List type. I want to clearly separate what's the contract (indexed ordered sequence) as opposed to "incidental" implementation details (constant cost random index access).
hinkley 10y ago
The rule of three works out pretty well. If you don't have three of something then you don't really have a group you can attribute a set of behaviors to. If and when a third one does present itself, you usually have to rework things because you were very wrong about the way you organized things.
mdpopescu 10y ago
> That's not really controversial or interesting. It is to me. So far it seems that everyone takes this for granted. I disagree: I have yet to see a problem created by the "each class has an interface" rule, and I have seen countless problems created by classes without one. So: what problems are caused by interfaces with only one implementation?

deleted 10y ago

[deleted]

jpitz 10y ago

I don't find it controversial, and it isn't altogether interesting, but I would like it if it were better communicated. I've cleaned up code that dogmatically followed a interface-per-class policy.

dibujante 10y ago

I have worked at shops where, without fail, EveryClass : IEveryClass

mpeg 10y ago
Because, of course, you might expand it later. Sure, I'm adding this shitty console based logger, but since it's wrapped in ILogger I'll later come and write a FileBasedLogger, a DBLogger and a KafkaProducerLogger for when we go webscale. Except, that never happens.
- BatFastard 10y ago
  Then you go back and refactor the code to pull out the interface! I so hate interface abuse.
  - sanderjd 10y ago
    If you use names like Logger instead of ILogger, you don't even have to change all the names when you refactor to an interface! If you end up wanting a FileBasedLogger, you just rename the current implementation to StdoutLogger, create a Logger interface, create a FileBasedLogger, and change instantiation sites to build the instance you want.
    - reitanqild 10y ago
      Using IClass naming is considered best practice in the .Net world AFAIK. (I think Visual Studio and/or Resharper hints very clearly about this.)
      - sanderjd 10y ago
        I know, I'm demonstrating one reason I think that's a bad best practice :) I recognize there's nothing most people can do about that, though!
      - hota_mazi 10y ago
        > Using IClass naming is considered best practice in the .Net world AFAIK. No, it's the opposite. IClass is the norm, for legacy reasons going all the way back to the early COM days (it all started with IUnknown[1]). [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
    - hota_mazi 10y ago
      > If you use names like Logger instead of ILogger, you don't even have to change all the names when you refactor to an interface! But you want to, that's the point. You're making a drastic change to your code base, surely you want to inspect every place where that type is used.
- dibujante 10y ago
  //Names changed slightly to protect the wicked public interface IProvideBoolean { Boolean True { get; } Boolean False { get; } } public class BooleanProvider : IProvideBoolean { public Boolean True => true; public Boolean False => false; } So.... SOLID.... If there's ever a third value for Boolean, I Will Be Ready.
  - Ygg2 10y ago
    Finally ready for trinary computing!
  - breakingcups 10y ago
    See also: https://thedailywtf.com/articles/What_Is_Truth_0x3f_ https://thedailywtf.com/articles/What_Is_Truth_0x3f_
Ace17 10y ago
There are some (rare) occasions, when private members drag new dependencies that you don't want the user of your class to know about. You can also do "pImpl", which is similar, if not worse, in terms of boilerplate, but doesn't allow DI. Just don't use these techniques unless you can prove they're needed (e.g private members drag new problematic dependencies, #include <some_volatile_header_file.h>).

jsarasti 10y ago

It's quite controversial in the real world where "each service class has an interface" is official codified dogma. OTOH in certain specific cases I see the value of the interface even for just one class when I want to clearly separate the contract (which I'm bound to fulfill now and in the future) and the implementation specific comments. Let's say that in my little pet programming language I have just one List type. I want to clearly separate what's the contract (indexed ordered sequence) as opposed to "incidental" implementation details (constant cost random index access).

hinkley 10y ago

The rule of three works out pretty well. If you don't have three of something then you don't really have a group you can attribute a set of behaviors to. If and when a third one does present itself, you usually have to rework things because you were very wrong about the way you organized things.

mdpopescu 10y ago

> That's not really controversial or interesting. It is to me. So far it seems that everyone takes this for granted. I disagree: I have yet to see a problem created by the "each class has an interface" rule, and I have seen countless problems created by classes without one. So: what problems are caused by interfaces with only one implementation?