3 ms·

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

mpeg 9y 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 9y ago
  Then you go back and refactor the code to pull out the interface! I so hate interface abuse.
  - sanderjd 9y 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 9y 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 9y 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 9y 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 9y 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 9y 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 9y ago
    Finally ready for trinary computing!
  - breakingcups 9y ago
    See also: https://thedailywtf.com/articles/What_Is_Truth_0x3f_ https://thedailywtf.com/articles/What_Is_Truth_0x3f_
Ace17 9y 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>).

mpeg 9y 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 9y ago
Then you go back and refactor the code to pull out the interface! I so hate interface abuse.
- sanderjd 9y 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 9y 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 9y 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 9y 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 9y 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 9y 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 9y ago
  Finally ready for trinary computing!
- breakingcups 9y ago
  See also: https://thedailywtf.com/articles/What_Is_Truth_0x3f_ https://thedailywtf.com/articles/What_Is_Truth_0x3f_

Ace17 9y 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>).