4 ms·

The wider problem is that to do a thing you have to start thinking about the design of IDoAThing and a implementation ThingDoer before you've even worked out ex

by mhh__ 2y ago

The wider problem is that to do a thing you have to start thinking about the design of IDoAThing and a implementation ThingDoer before you've even worked out exactly what to do yet.

hnthrow90348765 2y ago
You don't have to do that any more, you can provide default methods for IDoAThing
taberiand 2y ago
The C# tooling is very refactor-friendly. I commonly just build the class then pull out the interface later. C# does want to have interfaces though, and gravitates to the common interfaces - core services - composition/DI root architecture, with lots of projects in the solution to provide separation of concerns. I think it works very well generally for business software at least, but I hear plenty of grumbling about 'complexity' so it's not for everyone.
- HdS84 2y ago
  Just a small advertisement: have a look at automatic interface written by me. It builds your interface automatically from your class.
- mhh__ 2y ago
  I like the tooling but this doesn't change that the language has a major case of OOP-brain
  - taberiand 2y ago
    Maybe in how it's taught, but in practice deep inheritance and mutable state is easily avoided and best practice is more for a more procedural style
    - ngrilly 2y ago
      Is there a good example of an open source code base written like this?
neonsunset 2y ago
'ThingDoer' is a naming convention from Go (I'm not a fan of the fact that we have to live with the Delphi-ism that is IMyThing but at least it's just one letter). There is no requirement to define new interfaces except for a specific coding style in a team. It is best for most components to stay as plain and simple as possible, and for the module and component level testing to be applied with as little mocking as possible (because, most of the time, it is an anti-pattern imposed on us by what is sometimes named "London's school of testing" which is just bad practice and whoever perpetuates it should apologize).

by mhh__ 2y ago

The wider problem is that to do a thing you have to start thinking about the design of IDoAThing and a implementation ThingDoer before you've even worked out exactly what to do yet.

hnthrow90348765 2y ago

You don't have to do that any more, you can provide default methods for IDoAThing

taberiand 2y ago

The C# tooling is very refactor-friendly. I commonly just build the class then pull out the interface later. C# does want to have interfaces though, and gravitates to the common interfaces - core services - composition/DI root architecture, with lots of projects in the solution to provide separation of concerns. I think it works very well generally for business software at least, but I hear plenty of grumbling about 'complexity' so it's not for everyone.

HdS84 2y ago
Just a small advertisement: have a look at automatic interface written by me. It builds your interface automatically from your class.
mhh__ 2y ago
I like the tooling but this doesn't change that the language has a major case of OOP-brain
- taberiand 2y ago
  Maybe in how it's taught, but in practice deep inheritance and mutable state is easily avoided and best practice is more for a more procedural style
  - ngrilly 2y ago
    Is there a good example of an open source code base written like this?

neonsunset 2y ago

'ThingDoer' is a naming convention from Go (I'm not a fan of the fact that we have to live with the Delphi-ism that is IMyThing but at least it's just one letter). There is no requirement to define new interfaces except for a specific coding style in a team. It is best for most components to stay as plain and simple as possible, and for the module and component level testing to be applied with as little mocking as possible (because, most of the time, it is an anti-pattern imposed on us by what is sometimes named "London's school of testing" which is just bad practice and whoever perpetuates it should apologize).