.Net Foundation Virtual User Group, 29 Jun 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: What's New In C# 8 Interfaces (and how to use them effectively) - Jeremy Clark - SEVDNUG and NWVDNUG

Description

We'll look at the new features of C# 8 Interfaces and see where they are useful and where they should be avoided.

C# 8 brings new features to interfaces, including default implementation, access modifiers, and static members. We'll look at these new features and see where they are useful and where they should be avoided. With some practical tips, "gotchas", and plenty of examples, we'll see how to use these features effectively in our code.

Jeremy Clark makes developers better. By drawing on over 15 years of experience in application development, he helps developers take a step up in their skill set with a focus on making complex topics approachable regardless of skill level. He is a Microsoft MVP for .NET, and he has authored seven courses for Pluralsight, including "C# Interfaces", a course aimed at giving developers a clear understanding of abstraction. He loves speaking and has delivered over 300 technical presentations in the last 10 years in the United States and Europe. Jeremy lives in northern Washington with his lovely wife, 3 cats, 2 dogs, and a banjo.

This session is part of the .NET Virtual User Group (https://www.meetup.com/dotnet-virtual-user-group) series, where you can join and find more virtual user groups happening around the world.

CONTACT ME

Twitter: https://twitter.com/digitaldrummerj
Web Site: https://digitaldrummerj.me
Twitch: twitch.tv/digitaldrummerj

A

It's really great to be back at the Phoenix user group meetings. So I haven't been there in a really long time, so I used to live in SoCal, so I managed to get out there. Usually at least once a year um three years ago, I moved up to Washington State, so I miss you guys so hello and it's nice to see a lot of familiar names on the participant list and we should chat more often because I don't get enough of this. Hey.

B

A

B

Get Sun to rain out of interesting.

A

So a wife so actually.

C

A

I moved for her Kirk I uprooted myself and went 1,250 miles north for a girl.

A

D

How's, the girl.

A

Beagles, which, fortunately, she took them out today, so you shouldn't hear them barking in the background, as they often do you so.

B

I'm a little down here because of the weather but I will I will admit that the weather is sucks up there, but the beer is way better.

A

Yeah so I'm, not a beer drinker, so I.

E

A

Ii would join.

E

A

He's around somewhere, he'll probably show up in the background, so yeah I might win the award for the most crazy stuff in the background right now anyway. But we're not here to talk about me, we're here to talk about C, sharp bait interfaces and the reason I'm doing this is because interfaces have been a really important thing to me as a developer and as an educator. So I had trouble learning about interfaces when I was just getting started.

A

As a professional developer, I was working in a language Delphi for those of you who go back in time a little bit and it had interfaces in it in the language and I could tell that they were important, but I didn't understand what they were for, and so it took me a little while to figure that out and since then I've been helping.

A

Other people figure that out I have a Pluralsight course which helps people get started with c-sharp 8 and our c-sharp interfaces I should say, and the thing is with c-sharp 8 there's a lot of changes that came out so we're going to be going through kind of a whirlwind tour of what those changes are and what they might mean to us and kind of how we can avoid getting into trouble with them. So that's really the goal. For tonight. My website is Jeremy, bytes calm.

A

You can see up there on the screen and you can follow me on twitter, at jeremy bytes as well. If you go out to Jeremy, bytes comm you'll find a link to this talk and there's a github repo that has all of the code samples I'll be showing as well as this enormous slide deck. But don't let it scare you the slide deck is here mostly for your reference. Later. I won't be spending a whole lot of time on it and then also a link to quite a range of articles about this particular topic.

A

So really, the reason why I talk about this is because it hasn't been very well communicated by Microsoft exactly what's going on, because basically, when c-sharp 8 comes out and there's you know, here's the list of things, you know there's the great triangle: blank like the nullable reference types and default implementation for interfaces, and this and this and this and it basically the interfaces, get like a little half paragraph most of the time saying.

A

Well, you can add a default implementation to your code so, for example, here's the one that they here's the example that's on every single Microsoft slide, I've seen so we have an ilogger interface that has an existing log method on it, and the idea is that we can add a log exception method to the interface that also has an implementation, and because this implementation is here, existing implementers of ilogger don't have to add it. So if we have existing eye loggers out there, they will continue to work.

A

If they don't provide their own implementation, then this default one will be used. So this is the example. That's always used, and the thing that's frustrating is once I started. Looking at this, it's like. Oh, these changes go a lot deeper because it's not just default implementation, and when we talk about default implementation, it can apply to all the members that we can have on interfaces so methods, properties, events and indexers.

A

Something else that's changed is we can now have access modifiers on interface members, so originally you weren't allowed to have access modifiers on an interface. Everything was public, it was automatically public and you couldn't change it and in fact, even if you typed in public it wasn't allowed. So now we have access modifiers, so we can have private and protected members on our interface and we'll look at that as we go. Another thing is static members, so now we can have static methods and fields and constructors. If we want.

A

We can also have abstract members, which sounds weird, because interfaces in the old world are abstract members, but we can actually specifically mark things as abstract and then we can have partial interfaces. So, just like partial classes, we can split up an interface into multiple files and potentially add to it later and then, along with the static members, we can also have a static main. So you can put your entry point of your application inside an interface.

A

If you really want to I would say you probably don't want you, but these are all things that are now possible, so it really rubs me the wrong way. When I see that little paragraph and the you know 15-second, oh, you can have implementation on your members and it'll be a default because there's a lot more. That's underneath this now. The reason why this was added I actually got this off of the language design notes that Microsoft publishes.

A

If you are curious, you can go, hunt them down and find them, but the reason for changing interfaces was actually threefold. One of them is so that there'd be compatibility with Android and iOS, so both Java and Swift have default implementation as part of the languages and so for xamarin compatibility.

A

This actually helps with that, because now c-sharp can be more compatible with Java and Swift, and those libraries that you might be consuming. Another thing is that you can extend existing api's. So if you have an existing interface, that's out there, that's a name, that's your API! You can add to it without breaking your existing implementers. I have mixed feelings about that, and I'll talk. I'll talk to them about those. After we kind of look at what this stuff is and then the third reason is for make sense.

A

Now the idea with a mixin is that we have, basically, you can think of an interface that only has implementation in it. So it's got this little kind of set of functionality and you can say: okay well, this class implements this interface and basically all this functionality comes along with it. So really mix-ins is multiple inheritance and c-sharp doesn't allow for multiple inheritance, but you can implement multiple interfaces, and so now that we can have default implementation, we can have make sense as well.

A

So again, I'll talk a little bit more about these kind of once we look at the mechanics, but these are the reasons why the language was updated and I do want to say.

A

If you have any questions, feel free to I'm gonna, try to keep it a an eye on the chat window, but I'm not always good at that, so feel free to speak up or raise your hand and then I'll rely on one of the hosts to flag me down and say: hey Jeremy, slow down so, like I said, I've been talking about interfaces for a long time now and before c-sharp eight, there were kind of a lot of rules that made interfaces.

A

I, don't want to say restrictive, because you know kind of by having the rules. You have great freedom, so it's kind of like by having the rules in chess. You can have an interesting game and in the same way, by having these rules on interfaces, you can do certain things that you can't do in other ways and originally before c-sharp eight, there was no implementation code allowed. These were all abstract members. They were just declarations.

A

No implementation and like I mentioned earlier, everything was automatically public and you, like you, can't even put a public access modifier on it. It wouldn't build, so everything was just automatically public. There was no other way. You could not have static members and you could not have fields of any kind and just to kind of show that in a little more detail, one of the things I do when I talk about the differences between interfaces and abstract classes is I had this chart. That said well, here's the differences, so interfaces do not have implementation code.

A

Abstract classes can have implementation code. Well, you know that's! No! That's no longer true.

A

A class may implement any number of interfaces, so we don't have to, whereas with abstract classes, we have single inheritance that actually stays the same, but when we get to the next one about access, modifiers yeah interfaces aren't automatically public anymore, they can have access modifiers and, as far as what you can put into interfaces, a lot of those restrictions are gone now. I will say: there's some caveats to that.

A

So even though I say an interface can have a field down, it actually can only have static fields and I'll talk a little bit why static fields are okay, but instance, fields aren't and then before no static members and that's gone now. So basically, the line between interfaces and abstract classes is really blurry. Right now,.

A

I'll talk a little bit about this as we go, but really this is one of the things that I'm I was kind of concerned about it's like okay. Well, now, we've got these blurry lines. How do we you know separate these and how do we make sure we're going forward with the right things and then before looking at the actual features, just a note about c-sharp eight, which includes default implementation?

A

This is something you can use in net core 3.1. If you have dotnet standard libraries and you have dotnet standard 2.1 you're good upcoming, dotnet 5 you're good, but this is not something that's available in dotnet framework at all period and dotnet standard. 2.0. Same same reason, since that supports not net framework. So if you're using a standard, 2.0 or dotnet framework for point 8, these are not available now. The reason I point this out is because again there was kind of a when c-sharp 8 came out.

A

People are saying: oh well, you know what you can use these features in dotnet framework. If you you know either do this setting make sure you have this compiler or go out and get this NuGet package or do this, but you you can't do default implementation, that's something you can't do with C with any of these add-ons for dotnet framework and so again, I kind of got upset with people saying, oh, you can do everything in c-sharp 8 in dotnet framework.

A

Well, except this one thing but like I said it's not just one thing: it's actually a whole list of things. So with that, let's go ahead and start looking at some of these features.

A

Okay and we will start out with default method implementation, because, quite honestly, this is probably what you'll be using if you use any of these features, and the other features will really kind of support. This default implementation so kind of the way I think about it. For those of you who have been in the dotnet world for a while I think about this, like when we got linked in the language, so link came in, and language integrated, query really awesome, still one of my favorite things out there, but to support it.

A

We also got lambda expressions. We also got the VAR keyword. We also got extension methods. We also got anonymous types. Those were all added to the language to specifically support link, but there are things that we could use individually as well. So a lot of these features were added specifically to support default method implementation, but they can be used for other things as well. Now, one thing I'll point out is at the bottom of a lot of these slides you'll, see links to github and that's because I've got to get hub repo.

A

That has the project that I'll be showing and it's actually a solution with probably about eight or ten projects in it. And so, if you download these slides from github, then you can click on these links and they would take you to the specific file in the repo where this code lives. So if you want to dig into it a little bit more later on.

C

A

Available to you so, like I mentioned, the idea with default implementation is that we can change an interface after it's already out there and let's actually go to some code, because I feel like thinking in code.

A

Excuse me: okay, so I mentioned the solution and it actually does have a number of projects, and most of them are named after the specific feature that we're looking at so we'll start out just with the default method, implementation and just kind of show. You an example here: okay, so here's an ilogger interface that just has one method, which is a log method and there's an enum here on line five for the log level and then a log method that takes the log level and a message right now.

A

I have an implementer of this called initial logger, so it has the log method filled in and then I also have a positional.

F

Operator is going to do different, we're going to do it differently. Sorry,.

A

Was that a question or no okay?

A

So here's a console application that instantiates that initial logger class and right now, it's just calling log two times once on line ten and again on line 18.

A

So let's say we want to extend this and we'll just do what we had in the sample. So we'll add a log exception method, and this will take an exception as a parameter.

A

And for this we'll just call the existing log method and we'll pass in the log level of error and then give it a message. So let's go ahead and pull out the type of the exception and the message.

A

So that now has a default implementation with it now what's important is if I build at this point. I will get a successful build so for this initial logger object, even though it doesn't have this additional member on the interface. It still builds, it's still fine, so we can continue without modifying this particular class, so we won't break existing implementers, which is you know, one of the big keys of this and then I can change this inside the catch blog I'll change this to log exception and then we'll pass in the e^x.

A

So now, if we run this and.

A

Of course, it pops up on a different monitor.

A

There we go at the very top where we have the warning message that says just a warning: carry on that's actually going through the log method of the initial logger class, so that's actually the class level method and then the second one, that's logging, the exception, that's coming from the default implementation, so this is something that is not part of the initial logger class, but it still works.

A

Now when we use the default implementation. There's a couple things to keep in mind, and that is in order to call this log exception method. We need to be using a type that is of the ilogger interface type.

A

So what I mean by that is, if I were to change this to initial logger, so we'll have it as the class type, then we actually get a build, a compiler exception or I'm. Sorry, a compiler error, because this initial logger class does not have this method, even though the inter face that it implements does have the method. So we cannot refer to it by the actual class type.

A

The only way we can do it is by referring to the interface type, and the same thing is true: if we want to use var so a lot of times we're used to using var, depending on what kind of work we're doing in this case, var is just a replacement for the hard for the concrete type, so it is of type initial logger. So we have the same error message, which is initial logger, doesn't have a log exception method.

A

So when we're using these default implementations, we have to use the interface type rather than a specific, concrete type.

A

Now this is very similar to how we would do explicit implementation in interfaces and for those of you who haven't done explicit implementation before I'm, just going to add a new class here, real fast and we'll call this explicit logger.

A

And we'll just class that implements ilogger interface and if you use the control dot to bring up the implementing the interface there's two options: there's implement interface and implement all members explicitly.

A

A

Okay, I'll just start with this, so there's actually broken tooling. Here, you'll notice that I only got one method. I only got the logger method. I did not get the log exception method for that, and that's actually something that I don't know what Visual Studio is going to change the way that works or not, but for right now, it's kind of a hassle.

A

So what I can do is I can implement this interface. I can interface implement the interface members explicitly. So what that means is. If we look here on line 9, the log method is prefixed with the ilogger type, so this is saying I log or dot log and then on line 14, the same thing: I log or dot log exception and you'll notice. Again we don't have a access.

A

Modifier here does public actually work or does that throw an air yeah so that actually throws an error when you do explicit implementation- and this is the way it's always been- you can't put an access, modifier and I'm, not sure why I guess it's, because they don't apply or it's carryover from the everything is automatically public from interfaces that we had before. So there's no access modifiers. When we do this now, if we were to do the explicit logger, then what we would see is the same thing.

A

So if we refer to it by the I log or interface, then both the log method on line 10 and the log exception method on line 18 work, but I pay, X plus it logger, then now we'll see that we've got red squigglies on both of those on line 10 and on line 18, and that's because this member, this explicit logger object, does not have those members visible. So if we do log or dot, we just see kind of the default things that everything has in c-sharp. We don't see those things that are explicitly implemented.

A

So when we're looking at default implementation, calling methods that have defaults is very similar to calling explicit implementations. Wow is this confusing? It probably is because explicit implementation generally throws people off a generally explicit implementation will help us if we have methods that might have the same signature, that we need to bring in separately or if we want something specifically associated with an interface but not not as directly with the class itself, so that world is a little bit strange.

A

So, let's flip back to the slides for a second and just kind of look at this again. So if we have a default implementation, it must be called with the interface type, otherwise we'll get compile time errors. So if you are using default implementation so that you can extend an interface if you have any calling code that is not referencing that interface, it's referencing, the concrete types or using VARs, you will actually have breaking changes in your code, so your code will break it'll, stop compiling.

A

So that's something to be aware of yeah, that's fun, and so I kind of mentioned that this is similar to explicit implementation. So again, I've got the example that I just showed you here, and this is the same thing. So if we use explicit implementation, we must reference the interface type rather than the concrete type or again VAR references, the concrete type. So the first one will work and the other two examples: do you not?

A

Okay? So now that we've seen this, we kind of have to think about what is an interface and has it really changed fundamentally, and so the answer is the definition really hasn't changed from a fundamental perspective, and when this first came out there were some discussions.

A

I don't want to call them debates, I'll call them discussions about whether this is a good idea for c-sharp or not- and you know everybody has their own opinion on that, but a lot of people were coming from other languages which do you support this kind of structure and talking about how we were thinking about interfaces as an abstraction, so as an abstraction it now it has like concrete code in.

A

Is it still an abstraction, and the answer is yes, it is actually still an abstraction, and the reason for that is when we talk about what belongs to instances versus what belongs to the abstraction. The default implementations actually belong to the abstraction so because of that, we're not adding instance code into our abstraction, we're actually keeping it abstract, and that sounds like a mess. Okay am I, making any sense at all, because I feel like I'm babbling. A little bit can I get one thumbs up from the chat room. It's totally making sense.

A

Oh sweet, okay, I will take one as a success. Okay, so I. The way that I would describe interfaces is as a contract. So the idea with a contract is it's something that two parties have to agree to so there's. You know generally two parties in the contract. The contract itself has to be visible to both parties and, in this case we're talking about the people calling the interface methods. So that's one party and then the people implementing the interface methods is another party. So those are the two parties. We're talking about.

A

Interfaces are still a contract but they're kind of a contract that has some functionality behind it, which is kind of where things Bend a little bit so I'm kind of modifying the way I describe interfaces now and I appreciate my conversations with Barry Stahl, because we always have awesome conversations yeah Barry, thank you, but we can think of interfaces as an interface describes, a set of capabilities on an object. So when we're talking about that, the capabilities might not be directly exposed, so we saw when we had an explicit implementation.

A

Okay and again, this is before any of the changes that we're seeing tonight when we had an explicit implementation. A class kind of technically does and doesn't have that that feature at the same time. So it has the feature. So if you cast it to the right type and call it it's there, but if you don't cast it properly, you can't see it so I kind of think about this explicit implementation and kind of the same way. With these, the way things are exposed kind of like thinking about a person who has multiple roles right.

A

So maybe you have a boss, who is also a father and if you're referring to him as boss, he will not do any of the fatherly functions.

A

But if you refer to him as dad, he does so, even though that one person has multiple capabilities, you kind of have to ask the right way in order to get the right set of capabilities, so I'm still working on that description, but that's that's kind of the best one that I've come up with so far and like I mentioned, the object, may only have the capabilities if it's referenced, the right way and again referencing the interface type rather than the class type itself, and as we've already seen default, implementation is called the same way as explicit implementation.

A

So if we call it with the interface type, it works if we call it with the concrete type it does not and again, if we use bar that's the same thing as using a concrete type, so that does not work either.

A

Okay, so we've kind of seen how to call it now. What happens if we want to override that functionality? Well, there's nothing to say that we can't provide our own functionality. We don't have to rely on the default, so let's go ahead and just create another implementation here and we'll call this override lager.

A

And it will implement the I lager interface now again, I do want to point out the tooling problem that we have I'm using Visual Studio 16.6 dot 2, which I believe is the latest I, updated it the other day and I.

A

Don't have you know my little notifications, not yelling at me, so I probably have another two days before a new version comes out, so this is actually something that I use quite a bit because a lot of times interfaces will have seven or eight members, and rather than going in and typing in all the method signatures you know, I want the tools to do it for me now you'll notice, in this case, if I ask for it to add the implementations, it's only doing it for the one that is truly abstract for the one that has a default implementation.

A

It's not offering to override that. So again, that's a shortcoming in the tool which I hope will be taken care of in the not-too-distant future, because I am a lazy, developer and I want these things. To do everything for me. So we'll do this a little more of the boring way and just do it manually.

A

And so in this case, I'll just put a console.writeline.

A

Duty and let's do the level.

A

Yeah and we'll do the message.

A

They say from override Locker.

A

And we'll just do something similar here.

A

Log level, dot exception or air and then we'll do the X stopped message and that almost fits on the screen.

A

Back to our program and use our override logger here.

A

And run the location.

A

And to a screen where we can see it.

A

We can see these first two lines. Do you say that they're from the override logger? So we are not using the default implementation. In this case, we are using the override. So when we are talking about default implementation, it is truly default its. If there is no implementation available, it will use the default one. Otherwise it will use the more specific one.

A

So, yes, we can override those as we go. Okay and then again, I mentioned that there is a bit of a tooling problem that I hope gets fixed and then, when we are calling an over at an interface member and I, don't like to use the word override, because it's not a true override it just isn't using the default, but when we're using that we can actually refer to the class in any of these fat in any of these fashions.

A

So if we go back to the code, if I change this to an override logger, this will work and this will compile and that's because if we look at the logger object itself and I just lost.

A

Then we'll see we have both a publicly visible log method and a publicly visible log exception method. So if we are not using the default implementation, we can refer to these interface members with a type with the concrete type, and then var will also work here as well.

A

If we do have specific implementation, that's overriding the defaults. It doesn't matter how we refer to this object. Okay, so to summarize, are you confused, because this is confusing so just to reiterate if a class does not provide an implementation, then using the interface type to call that method, we'll call the default if you use the class type or VAR, the code does not compile if the class does provide an implementation using the interface. If you use the interface type, the class method is called if use the class type.

A

The class method is called an abuse bar. The class method is called so based on this. One of the fun things about using interface methods is I might not know whether there's a default implementation being used or not, and so to avoid these issues.

A

Kind of a general recommendation is that if you are calling interface, members use something that's of the interface type and that might be even I'm, taking an object and casting it to the interface in order to call those members, and that way you can be sure that you will get that you will get the implementation.

A

If it's a default member or even if it's explicitly implemented on the implementing side, so in either of those scenarios, kind of the recommendation is to use the interface type and that actually helps us keep the abstraction better together as well. Wow I feel like I'm talking a whole lot into my computer.

C

You are we're absorbing all the stuff you're talking about. You are correct. The stuff is kind of confusing out your explanation, but the how they've implemented in changing some of the ways we've done. Interfaces of known interfaces is slightly confusing. Yes,.

A

It is confusing and that's actually a bit of my frustration. So if you haven't figured out yeah I'm, not a fan of these changes, I'm figuring out how to.

A

I won't say, accept them, but to accept that they exist and help people move forward because, like you said Justin, it does change the way that we think about interfaces in the way that we interact.

C

A

Them so we do need to know about these changes so that we can adjust our code appropriately now something ease no.

C

A

As well, yes, it's extremely easy to abuse and I'm gonna spend some time on that, because I actually have some abuses in this slide deck, which anyway.

E

A

Get there okay, so we've kind of talked about how, when calling a default member using the interface type is how you get to the default or how you get to an explicit implementation. This actually also impacts how dynamic works. So probably most people listening are not impacted by dynamic, because I think it's not very widely used. I used it in a couple scenarios where I had different types coming in that I knew all had the same members on them, but they were actually different types.

A

They did not share an interface, they didn't share a base type, they were all different types, but they had the same members on them. So to make my world a little bit easier, what I did was I used a dynamic object in the calling method and said hey. This will be great.

A

Unfortunately, I ran into some problems once default implementation kind of reared its head. So here's an example where I have an interface which is an irregular polygon. So this describes a geometric shape that has three or more sides, and each side is the same length, and so, in this case, I have a property for the number of sides. I have another property for the side length and then two methods, one to get the perimeter and one to get the area.

A

Now the perimeter calculation is the same regardless of how many sides the polygon has so I can actually create a default here and nobody needs to override it. So this is something that, in the past, I would have stuck into an abstract class and in the future, I probably will continue to put into an abstract class. But I want to show you the issue that I ran into now get area there's no way to well.

A

There probably is a very nerdy heavy math way to abstract that, but generally the calculation for the simple calculation for get area varies depending on. If you have a triangle or a square or an octagon, for example, so we'll say that I have this interface in place and I have two different objects, so as part of our tale of two objects, I have a square method or I'm sorry a square object, and this does not implement the get perimeter method. So it will rely on the default implementation for that it doesn't have it in there.

A

In addition, I also have a triangle object and for the triangle object, I did put an implementation forget perimeter. The calculation happens to be exactly the same in this case, but I did explicitly put in that get perimeter implementation on my object.

A

Now, if I have a dynamic or a method that takes a dynamic as a parameter and I try to access this get perimeter method. What I'll find is that triangle will work because triangle has an explicit get perimeter method on it, but if I pass a square into this, it does not work, and that's even true if the type I'm passing in is of type I, regular polygon that I pass in, because what dynamic does is it actually works with the runtime object, so it doesn't know anything about the interfaces. All it knows is I.

A

Have this object? Does it have these publicly available properties or methods on it? And in this case, if we pass in a square, we get an exception and it will say: it'll be a runtime exception, because dynamic only throws runtime exceptions and I'll, say: hey, you don't have a get perimeter method, so this is something that I ran into with dynamic, and so, if you're, using dynamic, it's just something to be aware of. I won't spend well I'll just show you yeah.

D

Jeremy, there's also a question in the chat that you might want to answer. If you can, you want me.

A

To let's see, okay, so from math, couldn't you end up getting a different result if you call using an interface type when there is a regular and an explicit implementation of the interface member? And the answer to that is yes, so I'm actually going- and this will show this now- let's see okay, I am going to paste in to the chat for all you and the chat. The.

A

A

Go air goes the.

A

Link for this particular talk, so part of this is I- have an additional topic here, which has to do with explicit implementation, and this is kind of fun because it actually goes through. Okay, let's say: I have two different interfaces with methods with the same signature on them and in this case, I have a single class that I need to implement on a single class implementing both of these interfaces.

A

In this case, since the methods have the same signature, I can do it normally, but what if one of these are actually here? Yeah? Okay, I won't go into that. Let's say that I have three methods on this class instead, and let me zoom in on this, because that's a little little and it's still quite a bit blurry, but you can take a look at this, so this is actually something where I have a single implementation class that is implementing both of these interfaces, but I have three save methods.

A

The first save method is a normal one that belongs to the implementation class itself. The second one is an I savable, dot, save method that belongs to the I savable interface. The third one is an I persistable, save method that belongs to the I persistable interface, and so we will actually get different results depending on what type of how we're referencing it. Let me actually just pop back up to this code, so in this case, what I've done is I've created three different variables from the same class, the implementation class.

A

So one is the concrete type. One is the I savable interface and one is the I persistable interface and then I call the save method using those three different types and then there's also an example where I cast types as well the interfaces, and so what happens is depending on what type of what type of object we're calling that method on. We will get different results. So, if I'm, using the concrete type, I will get the implementation safe method, if I'm using the I, saleable type I will get it's that interface, safe method.

A

If I use the I persistable type, it will use that one. So the answer is yes: they can. This can get very confusing, especially with explicit implementation. Once you start drilling down into it. Does that answer the question.

A

Cool okay, glad to help and again I.

E

Have a follow-up question there: okay.

A

E

Feels like explicit implementation, then, is a really bad idea, and I should never do that unless I have two things that must implement the same method name is that right should I flee from explicit implementations, I.

A

Would generally say yes as far as explicit needs, there's an example where, if you implement the let's say you're implementing the ienumerable of T interface, it actually has an enumerable of T and ienumerable. Just the you know, no generic type that does object. It actually has two methods with the same signature, which is get a numerator that takes zero parameters, but the generic one returns the T as the type and the non generic one returns object as the type.

A

So you have two methods with the same method, signature, but different return types and in c-sharp you can't overload based on that. So in that situation, if you implement ienumerable of T, you will generally implement the non generic version. Explicitly. Did that make sense.

E

Yeah, that does, and it feels like that edge case where that's necessary, but in the majority of cases it sounds like it also shouldn't be necessary. Is that right.

A

Yes, I would agree with that. Sir okay, you know I'm feeling brave I'll, just I'm just going to show you because the tooling handles this. So let's do a public class called my enumerable. The implements ienumerable of inte, let's say now. The the tooling is actually good on this first I need a using statement and then implement the interface because it actually will implement the ienumerable of inte in the normal way, not explicitly, and then it will implement the enumerable version. The non generic type explicitly, and so the tooling actually will do this.

A

For you in a lot of situations which is kind of cool. Can you tell I nerd out on interfaces.

A

And let me tell you, I can tell you where all the weaknesses in the tooling are.

A

Okay, oh and I was actually heading over to say there is a dynamic and default implementation project here, and so you can see it has that triangle in square classes, that I showed on the screen and there's a little program that actually kind of goes through and shows how you'll get runtime binding exceptions. So if you have something that references, the interface itself, you're fine, if you have something that does dynamic, this will actually give you a runtime exception for the one that does not have the implementation.

A

I might as well run that why not? Oh wait! That's gonna run the other one. Okay, so I have this cool little tool installed. These are all dotnet core applications and there's a power command power commands that you can get from the visual studio marketplace and it has this really cool open command, prompt on it. So if I right-click on a project, go to power, commands and say open command prompt, it will give me a visual studio, developer command, prompt at that location.

A

So I can do something cool like just type dotnet run and have it go from there? Oh and it looks like I, got an updated version. Okay,.

A

B

A

A

So what happens is this actually shows the runtime exceptions coming out? So if you want to play with this, there's all kinds of stuff out there, okay and there's actually an article that goes along with that as well. But let's head back to the slide.

C

Jeremy, to make it even easier to pull up that command prompt. Typically, it's alt spacebar will pop it up with whatever file you have to have open. Currently.

A

Okay, well, I'm usually want to do it at the class level yep but like if I was here. Okay, what did you say? Alt spacebar yep,.

C

I'll space, for it typically we'll bring it up our control. Spacebar might be it one of the two I. Don't have business to do open, yeah, that's their normal default command. You may have not set the command or the shortcut for all the people that have ever played quake before it's a little console command in quake.

A

Yeah, that's not popping up here the way.

C

A

To do it was I, would right click and say Open File, Explorer, yeah I'm gonna do it is that'll, give me the folder and then I could just go open PowerShell and it would give me power shell. So it's saving me a couple clicks.

A

Email me with that shortcut: I wrote, okay, so.

A

So yeah, so if you use dynamic again something that you might run into problems with and I think the most frustrating thing about the dynamic is, it will work if you're not using the default and it fails if you are using the default and as a consumer right someone who's calling this method I, don't know whether the class I'm I'm using has explicitly implemented that or not I, don't know. So that's a little bit of a frustration on my point on my part again.

A

If we refer to everything by the interface type, we don't run into that problem, and in that case you can't use dynamic at all. So you'd have GSD explicit type. Another thing that I've run into has to do with unit testing and mocking frameworks.

A

So because of the way mocking frameworks operate by defaults, they will not pick up a default implementation on an interface and I know that I've seen open issues on mock queue and substitute and fake it easy and from what I can tell it has not been resolved yet so as far as I know, there is not a way to fix this yet, but here's an example using mock you so up in the top corner I have the I regular polygon. So this is the same interface that we used with the dynamic.

A

So there's one default implementation for get perimeter and then in mock you, what I want to do is I really want to test that default implementation. So what I do is I mock the interface and then mock. You has a property called call base and that's supposed to deal with. If you have different trees that will call base base methods appropriately.

A

It actually doesn't do anything with regard to default. Implementation. I just put it in there to see if it would do anything and it doesn't and then what I've done is I've set up the two properties. The number of sides, property and the side length property, so I've, given those a value of 3 and 5 respectively, and then I call the get perimeter method on this mock object and in the assertion you can see, I expect it to be 15, which is 5 times 3, which is what the default shows.

A

If we go to the actual tests. Let me just close a whole bunch of documents, because I do have a unit testing project and we will scroll down to the occu here and.

A

I'll go to the test Explorer and we're actually looking at this one check default implementation. So if I run this.

A

It will actually fail and the message is while I was expecting 15, which is 5 times 3, but the actual was zero and that's just because of the way mocking frameworks have always worked even before default implementation. So the idea is that, with a mocking framework, I can set up a mock object with my specific functionality. I need for my test, so in this case I've set up to say on line 54. Then, if someone asks for the number of sides property, you should give them a 3.

A

If someone asks for the side length property on this object, you should give them a 5. Now, if I were to call the get area method which has no implementation whatsoever, then what Maki does is. It says well I'm, going to do I'm going to return you a default value for this type, so get area returns, a double I believe, and so it returns the value of zero point zero, which is the default value for a double and it's bitwise zero. And so it's doing the same thing here.

A

It's saying well, okay, well, get perimeter is not set up on this mock object, so I'm going to give you the default behavior, not the default interface behavior, but the default mocking behavior, which is to say, if you don't have a setup I'm going to give you a zero back, and so that's what's happening here now for this particular testing, I went through and I used mock you along with and substitute and fake it easy. If you do actually need to test a default implementation.

A

You'll want to go outside of the mocking framework. So here I have two actual fake objects set up one. This one here overrides the get perimeter on line 20, so it provides an implementation, and then this one here on line 9 does not provide an implementation, so it would rely on the default.

A

So if we test with the default implementation, this one actually passes. So if I were to run all of the tests.

A

What I see is the fake object, checking the default is successful, and this is not cooperating with showing the names of these tests. There. We go Jeremy's behavior.

E

And if I use mock, behavior strict.

A

That I do not know I have not.

C

A

That is something that I will look at.

A

So Rob, how you you behavior strict in the past, I, really.

E

Like Mockbee, because I then need to provide implementations for all the things that I use, and so it's a really good way to validate that I'm, not getting unexpected side effects by calling things that I did not expect. Oh well,.

A

In this case, I want to I want to specifically call something. I I want to call something that I'm not setting up, because I want to use the default.

E

A

E

To very specifically tell it to call its based thing: instead of calling its default Mach value well,.

A

As I understand, that's what this call base is supposed to do, but I'll need to dig into that a little bit more yeah.

E

A

I, have we have another test here that actually provides an override for the get perimeter as in as part of the mock object? But you know at this point: I'm, not testing the defaults, I'm testing, something else right. So the moral of the story is at the present time.

A

Testing default implementation with a mocking framework is difficult and kind of my inclination Rob. To answer that question is that it's that that does not work, and the only reason for that is like I mentioned. Several of these frameworks have open issues around this and if they said oh well, if you just do this, then it will work. Then you know I'm sure I would have come across that solution somewhere. So but I will definitely dive into that Marcus. I love.

E

That it was easy we would have solved it by now. Yeah.

A

That's what I'm thinking you know cuz as soon as I saw this I'm like oh I, need to go figure out. What's going on and again, I I came across open issues on get projects.

A

huh Okay, so now we get into the fun part, which is ways that we can do those badly, and this is actually one of my fears. As you know, as was mentioned earlier, this new functionality can be abused and at first I was kind of hoping that it wouldn't be so.

C

For example, use it.

A

Already Jeremy, it's gonna get worse, I'm. Sorry. What did you say said you didn't abused it already. It's gonna get worse, oh I'm, not gonna abuse it but I'm afraid other people will so, for example, when c-sharp got a static using statement.

A

I don't know if you remember that I was actually a little concerned about that because, like I said, I came from Delphi and Delphi is very similar to c-sharp in a lot of ways, and it's really not a surprise, because Anders Hales Berg created both of those languages originally so there's a lot of similarities between them. Now in Delphi there was this concept of basically kind of a scope using where you basically say kind of like with console and then inside this block everything would be console dot. So you want to have to keep.

C

A

Console dot, write line, console dot, writing console dot right. You could just say right right, right line right and it would assume console and c-sharp added that feature, but it added it at the file level. So you put a static using at the top of your class file and I was kind of concerned about that, because it's like well people put like three or four static usings at the top and they aren't scoped. It could make it difficult to understand where these different methods are coming from.

A

These static methods are coming from so fortunately I didn't see that hit the real world. So when default, implementation first came out. I'm like okay. Well, maybe it's going to be that same thing where this is a concern. I have, but it's not going to see fruition so I, don't really need to be worried, calm down, Jeremy, you get too upset about things, but then I came across a blog article.

A

This is code from a blog article where someone was saying default. Implementation is awesome, look what you can do with it and so here's the example. The example is, I have an I file handler interface that has a delete method on it. Okay, he just had one method originally and then, or one member I should say, and then he said it. This is great because you can add another method with implementation without breaking any of your implementers.

A

So I can add this rename method and it will work without me having to change anything okay, so I'm gonna ask this as a question since I ask it as a question here: does anyone see a problem with this default implementation.

A

Nobody you're all okay with this I.

E

Have a question yeah.

A

E

If my file store is not the file system exactly.

A

So this actually makes an assumption that I'm using system dot file system, dot, IO dot file for my implementation. So if I'm doing that, this works fine but, for example, I actually wrote an article about this again. It's in the links for this talk and there's one of the projects on this I won't show it to you.

A

You can dive into it where I actually took this interface and implemented an in-memory file system, and it was very simple: I just did a dictionary that had a you know, key value pair, so the key is the file name and then the string is the file contents, so again, a very naive implementation of a file system, but you know I implemented this as well as other methods, and so the thing is, if someone were to add this rename method.

A

For me who did the in-memory file system, this would have unexpected results at best it would throw a runtime exception, because these files wouldn't exist at worst. It would rename something on my file system that was unintentional, so that kind of makes me nervous and then, if I had unit tests against this. Well, actually, unit tests should be okay, because I probably am not testing those rename method. If I don't know about it yet so, yes, this is making an assumption that I'm using the physical file system I.

A

Could you know again, my example is real, simple in memory file system, but something more realistic. You know I'm storing files on the cloud and I accessed those differently than I do on my local machine, so yeah that article really scared me and so I started thinking about. Well. What are these assumptions? How and how do we kind of figure out how to do with them? Well, a really easy way to kind of stay away from this problem is to only reference other interface members in your default implementations.

A

So if we go back to our logging example that we started with this is actually okay as far as default implementation is concerned, because if I look at my log exemption method, it's referencing the log method on this interface, it's not saying oh I'm, gonna log to the console or I'm going to log somewhere else, I'm going to log to wherever the other log method is going right. So it's not making assumptions about the implementation.

A

If we're going to the console, if we're going to a database if we're going to the file system, it's just calling another member. So as a general guideline, our default implementations really should only reference other interface members. Otherwise we can end up making assumptions that turn out to be incorrect and again, at best we cause runtime errors and at worse we corrupt data right. We don't want to corrupt data, so I was thinking a little bit more ok. So that's a pretty obvious one right, I can't assume somebody's using the file system.

A

Are there other ways that we could get into trouble, even if we are using the other methods that are on this? So here's another one and this one's a little more subtle. You know- is there something about this interface that you think might be you know, might cause problems.

A

C

I'm going to assume based off the link, it's slow, that's.

A

Actually, a very good observation, so you'll notice that the default implementation, the gate item at uses, the link element at on get items now get items. If that returned an ienumerable, then we'd probably be okay, but get items is actually returning a read-only collection. So it's returning an entire collection of items, and so the idea is that, if this collection is large, we're going to get all of those items back and process them on the client side. The other problem we might run into is if these.

A

uh If these items take a long time to calculate, then we could run into problems because again we have to populate that entire collection. Worst case scenario, I, say: get item at index 0, which is getting me. The first item in this and I shouldn't have to retrieve the entire collection of objects to get the first item and I shouldn't have to process the entire collection in order to get that first item.

A

So this one may or may not be an issue because, depending on how we're you know what our api's are for, if this is something that's internal and I know the specific datasets that I'm dealing with and I know the types of calls that I'm making this might not and I well, another thing is I know how often these things are called then I might not worry about it, but if it is something that happens, you.

C

A

I, don't know how many times this is going to get called I, don't know how big my collections are. I, don't know how much processing goes on behind that. Then I can slow this down and again. There's an example of this I'll just kind of point to it again- and this is in the dangerous assumptions section and the bad interface has the file system. So my memory file handlers in here and then the slow performance. What I have is an actual Fibonacci sequence.

A

So this calculates the Fibonacci sequence as you asked for them and what it actually does is over. It keeps going until it overflows the integer field. So it's not a correct implementation, Fibonacci, actually overflows integer, pretty quickly, I, think it's like after 32 items or somewhere around there, it overflows.

A

So what this will show is that if I use this default implementation, it will process all of those items, even if we're asking for the first or second one and then I also have another interface implementation and what this does is it it implements both of these. So, in this case, it's dealing, this Fibonacci sequence is an ienumerable.

A

So doing an element at on an ienumerable is fine, because it's going to stop it's going to calculate up to you know, item number three or whichever one we asked for, but it's actually going to stop at that point, whereas when we say Fibonacci sequence not to list it's going to calculate all of the items that it can, which again will be up until the overflow. So again you can explore some more on that there's an article that goes along with that, as well as the code.

A

So can you tell that I've spent a lot of time? Looking at this.

A

Okay, so all of this is kind of having to do with default implementation of methods, which is probably most commonly what we're going to do, but we can also add default implementation for properties, events and indexers, which are the other things that we can have on interfaces I'm not going to talk about events and indexers. Those are fairly similar to methods properties have some kind of extra concerns, so we'll look specifically at properties.

A

So when we're talking about default implementation for properties, this is really good for calculated properties, so things that only have getters, they don't have setters. So as an example, I have my I regular polygon again, but the difference is this: perimeter is a property rather than the get perimeter method that we saw earlier. So rather than this being a method, it's a calculated property.

A

So we can see that perimeter has a default implementation for the getter of this property and it just multiplies the number of sides times the side lengths which are two other properties that are on this interface. So this is actually a pretty safe thing to do. We can't really get into trouble with it. It's referencing things that are already on the interface, so we're not making dangerous assumptions, so it actually works pretty well.

A

If you need to do this use case for that again, if you have a use case great, if you don't I, don't know if you're going to come across one accidentally now when we are talking about properties, if we have a read/write property, we have to provide default implementations for both of these, for both the getter and the setter. So this one that says int not allowed. This has a getter that returns a default of 20, but it has no implementation for the setter, so you can see I've got red squigglies there.

A

So if we're providing a default implementation for a getter, we also have to provide a default implementation for a setter, and then the reverse is true. Also not allowed. Has the abstract yet and a default implementation for set now set just happens to be an empty body in this case, but it is that is actually a valid default implementation.

A

So I will put a big caveat on this one and that's because setting doesn't really make sense for default implementation. There might be a way that you can figure out how to do this, but generally, when we're talking about a property, that's not a calculated property, we're probably setting a backing field.

A

So if we're the problem is that we don't have any backing fields in an interface, a field is not allowed as part of an interface static field is which we'll talk about in just a bit, but just a standard instance field is not allowed, and the reason for that is that a field is data that belongs to an instance. So an interface can't have things that are specifically instance related. It really is an abstraction and that's why we can't have constructor constructors either, because constructors have to do with specific instances.

A

So if we try to have a setter on a property well, what would we set in a default implementation? Something that's tempting is to say well, I'll just set the property itself, which is what this little block of code is doing. This is not good. This actually generates a stack overflow, so yeah I know we think Stack Overflow is where we go to get answers to all of our problems, but Stack Overflow seems like a real exception and here's a really easy way to generate one now. This works without default implementation as well.

A

If I just have a normal class that has a normal property on it, and my setter sets the property value instead of the backing value, I will get a stack overflow, so this is not unique code, but if we're tempted to say oh well, let's just add a default implementation, because really what I'm trying to get to is, can I have like an automatic property. That's part of a default implementation, and the answer to that, sadly, is no.

A

We can't so I would love to be able to say a lot of the things that I have in my code are default, properties or I'm. Sorry are automatic properties, so you know I just have the syntax where I have you know, get semicolon semicolon and then I. Let the compiler build that out and the compiler actually creates a backing field and sets up the getter and sets up the setter to use that backing field. So that's just a bit of compiler magic.

A

It's really a developer shortcut, automatic properties, I kind of wish there was a way to flag something in an interface and say well. My default implementation is to make this an automatic property, and there's no way of doing that. So just so you're, aware of that, when we have these things and again an interface declaration of a property, the syntax is very similar to syntax for an automatic or an automatically implemented property, but this is actually the abstraction, so int number of sides, with a getter and inside length with a getter and a setter.

A

Those are just declarations in the class that implements that interface. We must provide implementations for both of these. These are just abstract properties that we must implement so kind of the bottom line when it comes to properties. Is they make a lot of sense if we have a calculated property that we'd like to add otherwise default implementation doesn't make a whole lot of sense.

A

Okay, I'll pause there for properties, so I've talked about default implementation for methods and default implementation for properties, I'm going to be moving on to access modifiers. So if there's any questions that we've got on, what I've talked about so far feel free to throw them at me.

E

I have a question: I love your rule of default implementation should only use the other interfaces and so I'm trying to apply that rule here. How do I do a setter that uses other properties?

E

It kind of doesn't make sense. I, agree, I,.

A

Have not come up with.

E

A

Where a setter makes sense.

E

Yeah exactly I get that it. You know, I implement all the things. So we implemented this one too, but it still doesn't make any sense. Yeah.

A

Where it, the only place where it might make sense is you could use a default implementation on a setter to set a static field. And again we haven't talked about static fields yet, but you could technically use it to set a static field, but and then you could have the getter return whatever's in that static field, but again a static is shared.

A

So it's it's probably a bad idea if you're doing that, if you're setting a static value from an instance member- and you can do it from any instance- you're- probably going to have a bad time. So, yes, I I'm with you I'm hard pressed to come up with a setter. That makes sense if anyone comes up with one instead.

E

Many field interfaces.

A

No no instance fields only static fields.

E

Yeah I was trying to find a spot where, like I, create an instance field and then I create the automatic getter and setter properties, so that then the class need only implement the field and the properties just magically show up. But if I can't create instance fields, then that's not a thing, and if you're gonna do that, then just create your own automatic getter setter thing and leave it out of the default implementation.

E

A

I'm with you there, you Jeremy, there's a question in the chat. Okay, let's see.

A

Do the default property implementations have the same behavior of methods in terms of only being accessible when calling with the interface type and the answer to that Matt is yes. So it's it's the same thing: the default implementation. So, for example, if I have a let's go back to my calculated example, my calculated perimeter.

A

If I have a triangle that relies on the default, if I say triangle, dot perimeter, it's not going to be there so I would have to say hi, regular polygon, dot perimeter in order to get to that. So I still need the specific type and we can take our triangle and cast it to an eye, regular polygon and it would work, but we do have to reference it by the interface. So, yes, that does follow the same rules as the methods.

A

Okay, so let's move on to access, modifiers, I, I, really kind of wish. This wasn't a thing either I understand why it was put in there, but anyway it's it's complication. So we can now have access modifiers on our interface members, and so that's public private, protected internal, and you know the various combinations of those. So the the same access modifiers we can have on classes and structs and everything else we can have those on interface members as well.

A

The default access modifier is public, which is really good because that means, if you have any existing interfaces and you move them up to c-sharp eight- they will continue to work because they will be automatically public. So I am man if they would have broken that man I would be screaming bloody murder, so they do default to public I.

A

I'm kind of haven't decided yet whether I want to be explicit about public or not. Actually, I've got a slide on that. So I'll come back to that in just a moment. Now. What I found is that, if you do have private members on your interface, they must have a default implementation and privates are only available from inside the interface itself. So it makes sense because it doesn't make sense to have something abstract, because a class wouldn't be able to see the private member so I'm glad that restriction is in there.

A

So if you try to mark something as private and don't implement it, you're going to have a bad time. So let's just take a look at these and a little more detail. So, like I mentioned, the default access modifier is public. So if we look at the interface we have here where one of them does not have an access, modifier and the other one is explicitly public. These are both public members.

A

So again, if you do have existing interfaces that do not have an explicit access modifier, they will be public now, I'm I haven't quite come to a decision yet, but I've kind of been waffling back and forth of whether I want to start putting public explicitly on interfaces as I move forward, and the reason for that is because, first of all, I try to avoid default visibility, because you have to think about it.

A

If I have a class and I put in a member that does not have an access modifier on it, its private by default. If I have an interface that does not have an access modifier on it, its public by default. So rather than my brain trying to figure that out, I think I'm, leaning towards I'm, probably going to start putting public on all of my members explicitly as I go forward, I'm not going to go back and retrofit things just to enhance readability.

A

Since it is now an option, you know make it clear that hey this is. This is what we're doing so. Public is kind of what we've been doing now. Private is new, and private members can only be accessed from inside the interface itself, so this you'll you'll note the little asterisk on this. This specific sample is a bit contrived to show I'm specifically looking at private members must be implemented here, but I have a public, a public, read-only property called item type. The second item on the line which actually calls a private read-only property.

A

So in this case the private member, the default item type, it does need to have a default implementation. So the first example where we're setting the default to an unspecified calendar item type that works just fine in the second example where I just have an empty getter and again this would make it an abstract member that would have to be implemented somewhere else it. The compiler will actually generate an error, so it does not allow you to do this, which is good. So if you have a private member, you must implement it now.

A

Why would we want to use private members well kind of the place. They'd be I would say. Most obvious is, let's say: I have a default implementation that is kind of large and complex, and I would like to split that up into smaller methods. I could split that up into smaller private methods on the interface, so that I can enhance the maintainability of this interface and call those methods from the the public default implementation, and so that makes sense from that standpoint.

A

So I can kind of factor my code to make it more readable, but I kind of have a philosophical problem with this, because if my code inside my interface, which is an abstraction, is getting so complex that I feel like I need to break it up into multiple smaller pieces. I might have a bigger problem with my design.

A

So even though the private is there I'm kind of leaning towards, if you feel a need to use it, you might need to rethink what you're doing so, that's kind of where I've landed there, so public and private again pretty straightforward. If I have a public member, you know it's there, it can have a default implementation or not. If I have a private member, it must have a default implementation.

A

It's only visible from inside the interface itself, where things get weird is with protected members and I'm, not sure why this exists, I kind of wish it didn't, because it's confusing and to kind of show this I'm gonna go to code because it'll be easier than looking at these screenshots on the slides. So let's go ahead and close everything, and in here I've got another project for access, modifiers and there's folders for private protected in public. Let's just look at a protected one and yes, okay, so here's an interface called I inventory controller.

A

Let's just implement this now the protected member is contrived. I probably would not have a protected member here. This is strictly to kind of show how this works. So, let's add a new item and with the thing called inventory controller, so say my inventory controller.

A

Oh wow, that's completely wrong!

A

It's here for touch-typing, okay, so if I do control dot to implement the interface it's you know it's going to just give me the public members which is kind of what we saw before public members without a default implementation, but you'll notice I still have red squigglies on this. So it's saying you must implement the other member. The pull inventory item. Okay, so I'm just going to copy the method signature here so I have that.

A

A

And we'll just return a new inventory item.

A

Okay, so it's not useful, but it works, but you'll notice that my interface is still not happy. It's saying this does not satisfy what I need so I might say: oh well, does this need to be protected as well.

A

No, that's still causing me a problem if I have a protected member I have to implement it explicitly. That's what I found through a lot of trial and error so and when you do an explicit implement, oh wait: I did that in the wrong spot should actually be on the method name out the return type so, and actually I'll just put that back.

A

So if you do an explicit implementation, you are not allowed to have an access modifier on it, and we saw that earlier when we were looking at explicit implementation. So we would need to get rid of this protective. So if I do this now, my interface is happy. It's saying: okay, you have implemented this sufficiently. You've provided an implementation for the public member and for the protected member. You've provided a explicit implementation. So this all sounds okay, but then what I found is there's no way to actually call that method.

A

So this is something I created earlier. Let's just go to that one. So this is a fake inventory controller and it implements this the same way. It actually has functionality so I have actually it looks like I did explicit both ways here. Yeah so I did explicit implementation on both the public member and on the protected member just to keep things the same in this case, but I did try it in all different ways, so on line 21 I knew up an instance of that object and assign it to a variable.

A

That's of the type of the interface and the push inventory works. Just fine. So if I say controller dot will see, push inventory item shows up, but pull inventory item does not show up here so, even though I'm being forced to implement this, there's no way for me to call this method using this class, even if it's cast to the interface type I'm pointing this out for strangeness and to say that I have not come up with a good reason to use protected members on an interface.

A

So again, there's a blog article and comments and discussion around it. So one comment was well. If you have a protected member on your interface, then that's something that would be visible to anything that inherits this interface. So you could have another interface that inherits from I inventory controller that can see this pull inventory item and potentially do something with it and at that point I'm thinking, okay!

A

Well, if you have a complex, if you have a hierarchy of interfaces that that's that complex, that you might want a protected member at one level, that is either used by default implementation or re-exposed at another level, there might be something else going on with your design, so that would technically be possible where an inherited interface could provide a default implementation that uses the pull inventory item method and that would go back to the class that implements the protected member. Theoretically, but again, that's I, just confused myself. Talking about that.

A

So I put that out there just because you can do it and just because you can't do it doesn't mean you should so again. If you do have a protected member, it must be implemented explicitly. Otherwise, the code won't compile, but there's no way to call it so yeah and then my opinion down here at the bottom of the slide: stick with public and private and you'll probably be okay.

A

Okay, so I'm gonna pause there. Any questions on.

A

What did I just talk about access modification.

E

Private, it even feels like private, is stepping a little bit too far. If the goal is to create an abstraction, yeah.

A

E

Implementation details about my abstraction feels like overreaching.

A

It's not that much. It's not any more overreaching than a default implementation, though, because really again, the way that you would probably use it is to take a default implementation and break it up into smaller members so and default implementation again that was I talked about.

A

There was kind of a discussion of people talking about other languages and there were some I'm, not a comp sy person, so just as a warning, I will not be able to talk intelligently about this, but some cops I people on a Twitter conversation about this back in September we're talking about how there's two different forms of abstraction and the old version of c-sharp adheres to one of them, one type and not the other, and the new one adheres to both of those types or supports both of those types or something to that effect.

A

So it is still an abstraction, because the default implementation belongs to the interface rather than belongs to an instance. So it's still an abstraction, even though it has code, but it's a different way. It's a different type of abstraction than we're used to dealing with in the c-sharp world. That's probably the best way to say that that make.

E

A

Well, let's move on to statics, and this is going to go pretty quickly through here. So basically, you can have static members on an interface now and Static members. If we talk about a static method, for example, static method on an interface is exactly like: a static member on a static method on the class.

A

So in the again there's an example code project, that's talking about static methods and I, take the same class, which is just purely static members there's no instance, members at all and I implement it with a reader factory class and with an eye reader factory interface, and when you use it, there is no difference because it's either reader factory, dot, get reader or I read or factory get reader. So when we're talking about static methods, a static method on an interface is equivalent to a static method on a class.

A

So there's really nothing scary there other than it's something new. Now something that is new, which you have to stop and think about a little bit is you can have static fields on a on a on an interface now static fields behave exactly the same way as they do on a class, and previously fields were not allowed on an interface and instance.

A

Fields are still not allowed on an interface, but a static field is so a static field is a piece of data that belongs to the abstraction itself, so it is still something that is not an instance member, so from again kind of that pure abstraction standpoint. It's still okay, because we're talking about you know the the pure abstraction that has to do with the interface as opposed to implementation, details that go along with the class.

A

So there's some things about this that are kind of interesting, because, again, the static field is a shared value. So it's something that belongs to the entire interface. You would access it the same way. You know static field or static or I'm. Sorry, interface type, dot, static field name, and so you might say well. Why would you want to use this I'm going to point to a Microsoft Docs example where they use a static property or I'm? Sorry, a static field to provide parameterization for a default implementation of a method?

A

I'm, not going to say that this example makes me happy in any way at all, but it is something that's out there, so there's basically two tutorials and that are on the Microsoft Doc's site. Right now and again, I do have links to both of these on my materials and then, if you go to the github repo, all of these same links are in the readme, so these two tutorials are in here. So this particular one.

A

There is a an item here on the on the right that says, provide parameterization, and this is an example that shows how you can use a static field to provide parameters for a default implemented method.

A

This example, this entire tutorial, makes me cringe a little bit because I understand what they're trying to do and what they're trying to do is show how you can use default implementation to add functionality to an existing object.

A

And then maybe you need some additional information that you can put into a static, and maybe this is a good idea, but I kind of I went through this example and I I don't feel good about it, but it's there so I'm going to point to it, and so, if you're curious about how we, you can use static fields as parameters for default implementation. There's an example: that's out there that you can go through okay now, one other thing: that's new to interfaces and completely not new.

A

At the same time is we can have abstract members now. I know that kind of sounds like a a no-brainer, because in the old world interfaces were all abstract members write an abstract member is a member with no implementation code. Now abstract is default for m4 interfaces, but we can actually explicitly mark things as abstract as well. So in this example, here we have a getcustomers method which is not marked. That is abstract.

A

We must provide an implementation in the interface implementation and then get customer is also abstract, and we must provide an implementation in the implementer of this interface.

A

Now the question is: why would you explicitly want to use the abstract IDenticard? There's like key word, the key word here and the answer is this- may be something that you would do if you had a complex hierarchy again, because in theory you could have a base interface that has a default implementation and then, in a descendent interface, something that inherits from that interface. You could react it and make it abstract. Now, if again, if you're doing something like that, there's probably something else going on that you might want to look at so again.

A

That kind of makes me uncomfortable, but I just want to point out. The abstract keyword is available and it's there it's possible to use something else. That's new! That's not a huge deal is you can have partial interfaces now, so that's kind of cool like we have partial classes. So this means that we can have a partial interface and have another partial of that same interface in another file that maybe we add to at a later time. So the same way, the same reasons we would want to use partial classes, we could use partial interfaces.

A

So that means that we can actually extend interfaces in a separate class or I'm sorry, a separate file that has default implementation in it again. Whether you want to do that or not is a good question. I know, I was talking to again. I was talking to Barry Stahl a couple weeks ago about something he specifically wanted to do and he wanted to extend an existing interface, so extend ienumerable. So can we do something for that?

A

Well, if ienumerable was marked as a partial interface in the base class library, you could totally create your own second part to our phone, but it's not so you can't extend it in this way. But if you are creating your own interfaces, they can now be partial.

A

That's the partial keyword and then something that's curious is you can now have a static main method in an interface? So this example here this I hello, world interface- is a valid console application.

A

So I hello world has a static main, and this has a default implementation, which is doing some console dot, write lines and also reading arts from the command line. So this is actually a valid valid program now, if you've never played with static main before so static main is the entry point to an application and it can be in any class in your project. It does not have to be in something named program, so you can have a static main anywhere. You want in your project.

A

You can only have one, however, if you try to put two static mains in different classes or different interfaces. In this case, you will get a compiler err, it'll say: hey, I, don't know what your entry point is, so the static main can only appear in one location in your application, but it can now be in an interface I have no idea why we, you would want to do that, I, really don't other than to confuse people and that's actually the example that I did see.

A

It's go back to visual studio because there is a static.

E

More than one static main in your application, if you know.

A

E

An attribute that tells you which class you want to use.

A

Yes, actually thank you for that correction, Rob, that's something that I did come across when I was playing with this, but I forgot to put that in my notes. So thank you. I will add that to this life you can so, as Rob said, you can have multiple static means as long as you have something in your application that points to you what the real one is.

E

But like you just mentioned, this falls squarely in the category of just because you can doesn't mean it's a good idea. Yeah.

A

But here look at this cool thing: I did so I built that.

E

You have to implement this class to get that interface to work. Nope.

A

So I just created an empty program class for fun. Oh you actually don't need this, and then you have I have the eye hello, world interface. That has a static main in it and that's all you need to do and since it's static, you don't need an instance. So no you do not need to implement this anywhere this okay.

A

So here's my favorite thing in the language to sign notes. So I read through these language design, notes a lot to figure out all of these features and try to figure out what's going on so my favorite thing is these language design notes have all kinds of questions Oh. Should we should we? Let people do this? What about this scenario? What about this?

A

What about that and so there's literally a question in the languages I notes that say: should we allow static main in an interface and the response, my favorite thing and the whole thing is: why not question mark and that's it? So should we allow this? Why not you know? So that's a little frustrating, but that's why I pointed out because it's there and why not yeah nobody will be able to find where your application starts, but other than that. You know why not okay, so we've actually gone through all of the features. Now.

A

What I want to do is just kind of talk about the reasoning behind them and my thoughts on why we might want to do this, why we might want to shy away from it again. We've and I appreciate the discussion so Rob and Justin and Mike and everyone else, who's been chiming in I, appreciate that, because otherwise I'm just talking into my camera, so we've we've kind of discussed. You know some of the reasons why we may or may not want to do this and what's kind of strange about it.

A

So, let's kind of just look at the the reasons and say hey what about this so again, there's three reasons why this was put into place: compatibility with Android and iOS to extend existing api's and to allow for mix-ins. So when we're talking about compatibility with Android and iOS, both Java and Swift offer default implementation.

A

So if you're a mobile or cross-platform developer and there's a library or something you have to use that has default implementations. It's great. That c-sharp now supports that, because I'm assuming I'm, assuming because I'm, not a mobile developer, I'm, assuming that that makes it easier to integrate with the native libraries and it actually might not be something that that an application developer would use.

A

It might be something that the you know: xamarin the the people who build xamarin are using so that they can hook into the the native libraries for the things that they're doing so. From that standpoint, it's a great reason for to support default implementation. I would say limit usage as much as possible. So if again, you have to integrate with a library that uses it then yeah, that's a good reason, but you know otherwise kind of stay away from it.

A

The the one that really gets me is extending api's, because I I might be old, school and I might be just an old old cranky person. Now I am a cranky old man, I'm trying I even have the cranky old man classics right, so I've got the cranky old man glasses and so the idea of changing an existing API by using default implementation.

A

The this this bothers me from like a couple fundamental levels.

A

First of all: well, actually, these are in a specific order, so I'm not necessarily going to talk about I'm gonna talk about the last one first, when we're talking about default implementation and the ways to do this, I'll say safely without making bad assumptions we're calling existing members of the interface, and so it's really difficult for me to come up with scenarios that are not trivial. So, for example, that log exception method to me, that's a trivial reason to extend an existing API I.

A

Don't think that that warrants a language change of the type that we're talking about to allow for something like that when I think about non-trivial examples like well, maybe I'm, truly adding new functionality that wasn't there before in a default implementation. Well, at that point again, how can I do that safely without making too many assumptions about?

A

What's going on so just the idea of doing that kind of feels wrong to me, and we do have a way of extending interfaces through interface inheritance and that's actually still the direction I lean in towards so, for example, if I me, if I had an ilogger and it needed to support a special exception message for some reason, then you know what I'd probably inherit and create a new interface and inherits from ilogger, but then provides the additional functionality and I've done that so, for example, when I'm doing repositories so accessing data a lot of times, I'll use a credit repositories, update, delete and I'll often break that up and say: okay well, I'm gonna have one interface that is just read operations, so I just have my read-only operations in one interface and then I have my update operations in a separate interface that inherits from the read-only interface.

A

So that way I can say well. If my application code only cares about reading, then it doesn't have to worry about the update code and really what that is. Is the interface segregation principle. So when we talk about the interface segregation principle, that's saying that interfaces belong to the callers, not the implementers. So that means the people calling these interface methods are really the ones who should be making the decisions of or that's how we should be making the decisions of what belongs in this interface.

A

So if I have a class or if I have a block of code, that is only doing read, operations against my data, then I should not be giving them a readwrite interface. I should be giving them a read-only interface, because if I give them a read, write or something that implements readwrite now they have more stuff than they need right, and so that's not keeping the interfaces you know nicely separated now. I would say that I might have my rewrite.

A

Interface would be a combination of both because, if I'm doing update operations well, I might want to do read operations in conjunction with that to say oh well before I update, something. Let me go ahead and read, make sure I get the latest one so I'm. If it's changed, I, don't update it and bla bla bla transactions, or whatever else and I just described that badly. Now, if I'm again, that's if I'm building like a crud repository, if I'm doing you know a reader/writer situation, then you know I'd separate things differently.

A

So really, when I think about extending api's this way, I'm thinking about well I'm, either doing something trivial or I'm doing something that this might not be the best road. Because am I following the interface segregation principle now I'm, not one of those people that says you must always follow the solid principles.

A

What I am is I'm a developer with experience, and so when I was a young developer and actually a young developer, because I started programming at 29 professionally, when I got my first programming, job I was 29 and now I'm, some old old enough for old cranky man glasses.

A

So back then I saw the you know the best practices, people and the people that had been doing this stuff for 30 years longer than I have and I'm like yeah I got this I got this and I messed things up very badly. A lot of times and then eventually, when I kind of figured things out, I came to the point where it's like you know. If I had listened to these people that have been doing this for 30 years longer than I have I would be in a much better position today.

A

So I will say: I, don't like the term best practices, because it makes it sound like you should always do it, but I like the idea of best practices, which is here's something that is generally a good idea and we understand it, and there are times where we say you know what this generally good idea doesn't fit. My specific circumstances, so I'm going to do something different and in that case, I'm not ignoring this best practice. What I'm doing is I'm saying I'm, specifically not doing this for a particular reason, so I have considered it.

A

It's not appropriate in this in this situation, so I'm not saying that you should never violate the interface segregation principle I'm, just saying in generally generally, it's a good idea. It's a good place to start and if you do need to step outside that guideline, make sure that you have a good reason for doing that. So when I see something that's kind of like making it easier to just kind of step out of that guideline without having to think about it very hard.

A

It kind of rubs me the wrong way now, like I said, I was talking to Barry a couple weeks ago and he came up with a really good scenario, where I think default. Implementation could be really useful and that's in an internal situation. So, let's say I'm in a situation where, at my company, I have control over both the implementation and the interface right, so I'm doing the abstraction and the implementation and the calling right.

A

So you know kind of all three pieces there: the contract, the person implementing the contract, the person using the methods on that contract. Now, if I want to extend an interface to add more functionality to it, I could use default implementation as a temporary measure so that I don't break the build. So I could create a default implementation that either does nothing or I. Don't like the idea of throwing an exception in a default implementation.

A

Theoretically, in the scenario you could get away with it, and so that way you could add a new member to the interface without breaking your existing callers without breaking your existing implementers and then the people who are responsible for the implementation of the interface can go through and update the implementations to add the new member. Add the new functionality, I won't say at well, actually I did say at their leisure on my slide, but hopefully quickly right.

A

So it's not there for a long period of time and the same thing: the people who are calling those members hey, look, we got this new piece of functionality and based on the interface segregation principle. It actually fits in here. So this is a good thing and then the caller's can start using that method and then, once you know all of the implementers are in place, you can go and remove that default implementation. So in this case a default implementation would just be something.

A

That's there temporarily, while we're modifying this piece of functionality and then we go and remove it later and that way again kind of we've seen how, with default implementation, we kind of run into these quirky things when it comes to how we call them the types of variables we use. If we have to use dynamic, how unit testing works so I, I kind of want to minimize the use of default implementation kind of as a general, a general idea in my world now.

A

The third reason for building these things, I think, is a really cool idea, and this is the idea of mix-ins and the you can think of a mixin as I have this piece of functionality that it's truly all of the functions. So let's say I have an interface that only has members with implementation and so maybe I'm, adding as a bad example. Logging functionality so now I have this eye logger.

A

That knows how to log to wherever and I can just add, that to a class and the class doesn't have to do anything else, other than say, I implement this interface and it automatically gets that logging functionality.

A

What this really is is multiple inheritance, so in the c-sharp world we do not have multiple inheritance and if I did some C++ programming before that, which did have multiple inheritance and you could run into problems, and one of them is known as the diamond problem, where basically I have like we'll say the same method name coming from two different base classes, which one do I call and so the way that they've gotten around the diamond problem with default implementation is that whole thing of you have to reference it by the interface type.

A

So, if I have multiple default implementations with the same method, signature I don't have to worry about which one to call, because the only way to call it is to say I want the one. That's on this interface or I want the one that's on this interface. So by saying you have to be explicit when you call these with the interface name that actually gets rid of the diamond problem and if you've looked and actually, if you go look at the language design notes, they have you know.

A

Well, let's say you have interface a and interface B and interface, see these all inherit and they all blah blah blah blah blah blah blah they've thought through all of this, because you don't want to cause unexpected issues so really mix-ins are a way to add pieces of functionality to existing classes without having to modify the classes. So from that standpoint it's a cool concept and there's a lot of languages that support makes sense. The thing that I wish was different is I wished that they had not used interfaces to implement this I wish.

A

There was some other thing, even if it was a different, just a different keyword like a new keyword that says mixin where you could put this in, and then that way we could kind of think of interfaces as one thing right, I want to think of interfaces as one thing which again it's the capabilities of an object, but with mix-ins you kind of expect all the implementation to be in the interface, whereas with other things you don't and kind of having those things mixed together in the same type, type of thing kind of rubs me the wrong way.

A

Now I will say that the mixin example that's on the Microsoft duck site is really kind of interesting. Let me just flip back to my browser and like I mentioned I, have a link to that one as well, because this uses an IOT example. So the idea is that I have an eye light. That knows how to switch on and switch off, and it has an is on property, and then you can have different things, but now I have an eye timer light. That knows how to switch on for switch on.

A

For a particular duration and in that situation, what we can do is add a default implementation that basically says well: I'm gonna use switch on I'm gonna use the duration to wait and then I'm gonna call switch off so I'm using everything. That's existing on that base, I liked interface, but I've, just added timer functionality for free right, so someone doesn't have to say well: I implement the on/off and the the boolean I can add timer functionality by just bringing in this new interface.

A

So that's kind of cool and then what was the other example they had in here there's another timer like Oh blankie light so the same thing so I'm using switch on and using switch off I'm using a duration I'm using a number of iterations and based on that I can now mix in blinking functionality to my IOT light. So this concept is pretty interesting.

A

I haven't thought through this in, like my real-world code, enough to figure out how to you know how this, how this works in the things I normally build, but this example is actually a really good example of mix-ins and the and the usefulness of them, so I would say, take a look at that.

A

So again, kind of my opinion on mix-ins I, really like the idea of mix-ins, but I wish they had been implemented a different way in the language: Wow, okay, okay, it's 8:20 I've been keeping you here a really long time, so I'm gonna grab things up so hopefully in going away. You now know that the interfaces are more than default: implementation in c-sharp bait right, so we do have default implementation, which is cool, but we also have access modifiers. We also have static members.

A

We also have partial interfaces, and then we kind of have all of the things that go along with that as far as where it makes sense to do default, implementation or not again, with properties getters make sense for calculated properties, setters, not so much and again, protected I'm, not sure why you would use protected I will I am still looking for a practical example of that. So that's! Actually what I've got for you this evening again, you head out to my website.

A

Jeremy bytes comm you'll, find a link to this talk, so you can get to the resources on my website and also to the github repo and the links for the articles and code samples are on both of those lists, so they basically have duplicates of that list and if you do have, questions that come up later feel free to shoot me an email because I'm still, this is still forming in my brain. This has been out since September, so and I still haven't like completely solidified on where you know.

A

I want my specific position to be on the subject when it first came out. I was like 100 cent against it there's a terrible idea. We shouldn't do this that hasn't changed, but now I'm trying to figure out okay, it's there. We can't do anything about it. How do we figure out how to how to do this appropriately? So that's where I am and I wish.

A

I could just say you don't have to worry about default implementation at all, but there's a chance that your favorite and you get a package decides to use default implementation at some point in the future. So even if you're not using it in your own interfaces, you might be using libraries that decide to use it. So you kind of have to know what the implications of that are.

A