Idea: Deinterfacing

[wgebczyk]

Scenery

As of now, in non trivial code base, average ratio between interface and number of it's implementation oscillates around 1.01 (maybe 1.1 - no measurement, just hunch-based). The reason for that is... testing, mocking, stubbing, etc.

Proposal

Let's have new keyword interfaceof that could be used as:

class AwesomeService {
  public void RunGoDoIt();
}
class SuperDuper {
  public SuperDuper(interfaceof(AwesomeService) service) {}
  public void DoIt() {
    this.service.RunGoDoIt();
  }
}
class SuperDuperShould {
  void RunServiceWithSuccess() {
    var serviceMock = NAmazingMock.Create<interfaceof(AswesomeService)>()
    var sut = new SuperDuper(serviceMock);
    serviceMock.Called().RunGoDoIt().Once();
  }
}

interfaceof(T) will make sure that any type that fulfill public members of T can be used.

PS: Maybe we could promote 2 spaces default instead of now (for years) 4 - would reduce number of electrons sends over the wire ;)

[KennethHoff]

Structural typing would be awesome, but I don't see it ever happening. It's too much of a divergence from the fundamentals of C#

[wgebczyk]

Not necessary full structural typing is needed, just "partially keyword supported lang extension" :D

[HaloFour]

Sounds like something best accomplished by a source generator:

[AutoInterface] // generator keys off of the presence of a custom attribute, or whatever you want
partial class AwesomeService {
  public void RunGoDoIt() { }
}

// generator emits the following:
public interface IAwesomeService {
    void RunGoDoIt();
}

partial class AwesomeService : IAwesomeService { }

[jaredpar]

I agree, this seems like a task for a source generator, not a language proposal. This doesn't really change the expressiveness of the language but is rather about automating, somewhat, manual tasks. Great case for a generator.

[wgebczyk]

Lang support would be even better!

Yeah... if that would be officially published MS package, Yea... short term workaround.
Relying on some Josh or UncleJim or SpidyCatLover007 library what might be dropped in 6 months :D

Still I think lang support would be better and admittance that "interfacing for testing" is to the core "dotnet way".

[HaloFour]

This will never become a language feature, as C# does not adhere to this notion that all classes should have an interface automatically defined for it, nor would it even for testing scenarios.

[jaredpar]

Lang support would be even better!

That could be said of virtually any source generator: it would be better / more complete if you did it in the language.

Still I think lang support would be better and admittance that "interfacing for testing" is to the core "dotnet way".

I disagree with the assumptions in this statement. They are fairly broad statements about the ecosystem that are backed by very little in the way of data.

[HaloFour]

PS: Maybe we could promote 2 spaces default instead of now (for years) 4 - would reduce number of electrons sends over the wire ;)

Tabs would be even less. ;)

The language itself doesn't care, you can set the indentation level to whatever you want.

[wgebczyk]

Do you suggest that "to write interface or not to" is such controversial question like "to space or to tab to be"?

[HaloFour]

Nope, only that C# as a language doesn't care what you use for indentation, or if you use any indentation at all.

[En3Tho]

Ive never seen a codebase where this 1 class - 1 intergace dogma really worked well.

People just end up with useless abstractions all over the place, mocks over mocks over mocks and really weak mental model about how their code actually works. Not to mention performance hit this approach brings.

Sadly, this is a mainstream enterprise practice.

So my question is: maybe just reduce the number of interfaces you dont actually need?

[HaloFour]

I believe it comes from a TDD philosophy that everything should be mockable and interfaces force that level of abstraction without having to dictate that all methods are marked as virtual. I agree that if it's a 1:1 to mapping that it's a bit redundant, and mocking frameworks like Moq I believe permit you to override non-virtual methods in unit tests via assembly rewriting.

[DavidArno]

It comes from an overzealous application of the "a unit must be isolated" mantra leading to far too many isolated unit tests. Write sociable unit tests and this problem vanishes. Good TDD leads to more sociable unit tests with interfaces only being employed to mock classes that have side-effects (which should be minimal).

So I completely agree with @En3Tho: a 1:1 ratio of classes to interfaces is a huge code smell. Either the code will contain many needless abstractions making it far more complex than it needs to be or side-effects haven't been minimised, making the code far more complex than it needs to be...

[HaloFour]

I think those are two different categories of tests, both of which are useful. The more isolated tests let you better test edge cases that could lead to a Cartesian product in integration tests. That's true even when absent of side effects, when composing over multiple pure functions.

In any case, I do think 1:1 implementation is overzealous and is perhaps a result of not understanding tools or practices to reduce the necessity for those layers.

[wgebczyk]

Uhm... Usually when our dear software uncles, MVPs promote pyramid of tests with simple examples, the mindset is tricked to spam lowest level tests the most and less and less higher to system level. Using reversed ways with integration/functionality/module might reduce interfaces for lowest level stuff - as you won't need in tests replace with mock.

Is this smell or not, that depends on taken arch style - 1:1 is de facto standard as I see written code not only in enterprisey env.
We can like it or not but it will stay.

Or.. you both @HaloFour & @DavidArno want to change whole dotnet evangelization? :D

[HaloFour]

I've never heard of any .NET evangelization suggesting that for testing you need to declare an interface to match every class. If you're finding that to be the case, then yes, I believe that evangelization should be changed. Not even Java follows this dogma, and they're a bit obsessive about onion-oriented programming.

[wgebczyk]

Hey! Thanks for a lot of comments. Nice!

I've checked eShop and out of 44 defined interfaces, only 5 of them have more than one implementations (excluding mocks, tests etc).
I was wrong! It s not a few percent it is around 10%

I can understand the point "we should not write such crappy code", I could event agree with it! Let's do it! But... the reality is that advocated, evangelized way of writing is "write damn interface as you will need in testing". I can check any non-library project on GH or template for "clean code" and those pesky lone-interfaces will be in majority.
I can accept that we should not intro this feature, because we should be better. more saint, then... who "should you choose to accept it..." this impossible mission to convince MS ppl to drop they mindsets and start promoting "non enterprisey", "non zealotish" way of composing the code?

I think this way of writing will have its place for years - you like it or not! This was advertised for ages by uncles and aunts that we should do it and rooting it out is not an option IMO.

About "adding features not bringing to language value". Well, please look at that from different POV.

1. delegates/events, were getting "sugared" twice if I remember to write less and I could add 3rd one as well - lambdas.
   Who now is using event or delegate?! I don't see often it in the code, but it is there! (yes for ages not coded against UI, hence this might be biased) - LANG CAN HAVE THINGS NOT USED BY MAINSTREAM

2. "async/await" - placing in method even single async+await, needed or not, generates for you tons of code/types/logic to make sure you can silently release whole call stack and get back to execution in the middle of function pretending stack allocation is intact :D - LANG CAN SILENTLY GEN THINGS

3. "ranges and indices" - oh my... this thing when last time checked with Roslyn over net BCL sources was less used that "goto". Yeah you read it correctly feature that was out on the brag list of "new c# stuff" has so lower adoption than crucified "goto" (Interesting to find out or read reasoning behind it when browsing dotnet code). - LANG CAN HAVE OBSCURE NOT USED STUFF

I would say nothing from the past of lang or dotnet exclude that on first sight.

Borrowing term from one of comments, "Overzealous purists of language, should not block small improvements for enterprisey/minority"
But yeah... this is more joke than serious comment as we all know that using such language closes discussion, polarize it etc.

---

As of now I see that this could be dropped if someone would revert the river of thought in MS world of MVP to stop "interfacing" - small change as there is not even wide agreement that this should happen.

If we cannot change hammered mental model of dotnet dev good code, then can we get painkiller?