Coding Blocks - I is for Interface

Episode Date: September 9, 2013

The good, the bad, and the ugly side of interfaces. We list some minor gripes, their limitations, and some strange gotchas as well as some tips for how we like to (mis|ab)use them. Download the episode on iTunes or Stitcher. Show Notes Duration: ~44m What Are Interfaces? 0:00 – 5:21 Interfaces are a contract Interfaces […]

You're listening to Coding Blocks, Episode 1. I'm Joe Zack. And I'm Michael Outlaw. And I'm Alan Underwood. And this is the show where we'll be discussing various programming topics, our pains, our gains, tips, tricks, and etc. Today we're going to be talking about interfaces, what they are, why to use them, the good, the bad, and the ugly. So, let's start off with the first thing, right? Interview question number one. What's an interface? Basically, you look at them as a

contract of what you have to adhere to when you're programming. If there's something in the interface, then you have to make it do something, or you have to at least put some code to it so that it fulfills that contract. Yeah, so I think of it as like guardrails on the highway. So the interface defines how you should be using the class in that context. Or that piece of data. You're defining how you should use that piece of data, how you should interact with that piece of memory at runtime, but not necessarily giving them the keys to the castle.

Yeah, I want to – I mean, the stuff's here. The landscape's there. There's other stuff you can do with this class, but if you want to do something that's off the road, then you should talk to the person who did it. Yeah, or even, I mean, that's one way to think of it, but also another way to think of it is, like, if you want to use this as this, right?

I'm trying to think of, like, an example of, like, an IEnumerable, right, or IList, but depending on how you want to use it, then you can use it as that, or you can use it as this, right i'm trying to think of like an example of like an innumerable right or i list but uh depending on how you want to use it then you can use it as that or you can use it as this if your class implements multiple interfaces maybe yeah like that mostly it was like facets of your personality to jump into another analogy you know the the joe that talks to grandma on the joe that uh you know goes out on friday night it's it's same person, but two different faces, I guess. You have your work clothes and your club clothes. Well, I mean, that's a perfect analogy, actually, if you take the Joe that talks.

So Joe has a method called Speak. His interface is now Speak, and there's different implementations of that. There's Joe Speaks to Grandma. So when you implement that class, that's obviously going to be removing a lot of choice language and whatever else might be there. Whereas when Joe Speaks at the club Friday night, you know, it's a different ballgame. The voice gets a little bit deeper. Yeah, the voice does get deeper, a little Barry Manilow-ish. But at that point, though, you now have an interface that says Joe has a method called speak.

Now you need to implement it differently depending on which class you're actually doing. So all of these things that we've said here are describing a can-do relationship. All right, so given that, though, I mean, what's the real difference between that and an abstract class then? Because, I mean, you're kind of describing the same thing, right? So the main point of an abstract class is you want to provide some implementation as part of it, but you want to make sure that there's some concrete implementation defined, and then you want the user of that class to add on to that with their specific use cases and needs to it. But you're definitely trying to define some piece of it. And you're actually assigning storage for members that you want to have available,

whether they be public or private or whatever, right? I mean, you're definitely assigning storage space for that. Yeah, that's a great point because in an interface, there is none. It's a declaration, but nothing's actually been set aside yet. And, you know, that's a very good point to bring up. But another key point that they both do share in common is an abstract class has to be inherited, whereas an interface must be implemented. So even though you have an abstract class that has implementation in it, you can't just use it as is.

You cannot instantiate it. You need to inherit from it as well. And that's really important since you only get one parent, at least in C Sharp and most other languages. Well, yeah, a lot of the more common, or I'm sorry, more modern languages, Java is another example with single inheritance. C++ has had multiple inheritance since its get-go right and it's always been considered a train wreck of confusion among uh

among developers and then you can get in some really nasty situations too where like you have your class inherit multiple classes but then somebody inherits your class so now it like expands and then comes back together uh you know, diamond shaped and get weird. So you can do multiple inheritance or not inheritance, but you could implement multiple interfaces as a way of trying to establish the different things that you want your class to be able to do. And the importance there, the real difference between that and multiple inheritance is that multiple inheritance has implementations. So everybody does things slightly differently, whereas when you have multiple interfaces, you're actually implementing those things yourself.

So you know how they're going to be done and you're not calling some method that you don't know where it actually came from. Yeah, yeah. And I would guess too, well, not guess, but I would say too that another thing you don't have to worry about is like the virtual functions that wouldn't be as big of a problem in an interface scenario as they would be with multiple inheritance. You know, that could get really tricky in terms of like which method is going to get caught under certain scenarios and some unexpected behaviors that could arise from that. So, of course, I've got to mention some things that bother me.

First off, I want to say that I'm a big fan of interfaces. I use and abuse them probably much too often, and I really like them, and I hope that Anders and whoever else don't get offended. But there are a few things I don't like. One of those is the name and convention. Microsoft has some opinions on how you should be coding your C sharp. And they've got this written up, we'll we'll throw a link in the

show notes. But one of those things is that they want you to name your interfaces with a capital I in the beginning. And I like that. And when you see it, it's it's instantly recognizable. But what I don't like about it is that I is like the ninth letter of the alphabet, which means it ends up getting kind of stuffed in the middle of your folder when you're looking at a directory or in your solution explorer. And so you've got all these interfaces separated from what they're being interfaced with. And I don't want to put them in a subfolder because that's either changing the namespace or further removing these interfaces so out of curiosity would you prefer that there not be any kind of naming convention used for interface like like like there could be the joe

object and the uh you know whatever that you know, the implements would be, would start with the Joe int. Well, I don't have solutions for anything ever. But, well, no, I was just curious if maybe that was like something that had, like how you would like to see your directory structured, though. You know, it wouldn't kill me to see underscores. I know it's kind of weird to see an underscore in the beginning of a file. But wouldn't that do the same thing from a directory listing point of view? Well, at least it would put it at the beginning.

It would put it all at the top. So all the interfaces are somewhere, and they're not kind of mixed in with these other file names. So it would almost be the same then as if going back to like the C days, if it was like a header file. Right. You want the header file separated from the you know the body from the the content and that's because i don't like the idea of having the interface in

one of the classes that implements because you know often i'm using interfaces it's because i intend to use this with more than one class and so then it kind of becomes this weird case of which class file do i put it in and i'm not not really big on having multiple classes in the same file anyway, but especially when you're talking about an interface that could apply to something in completely different namespaces. I don't want that in the same file, and I don't want it in the middle of the directory either.

Well, here's a question. Have any of us taken a look at how they do IEnumerable or any of those where those actually live? I mean, it might be that they don't ever put those interfaces in the same directory as their class files. I mean, I've be that they don't ever put those interfaces in the same directory as their class files. I mean, I've never actually taken the time to take a look at it. So what I don't like about the different directory idea is that

ReSharper yells at me when the namespace is different from the folder structure. I get this little squiggly line and I just can't take it. So I put all my stuff in the same directory as the namespace and I don't want to have it in a different namespace either. To me, those things are logically grouped together,

and so I'm just making a separation based on where I want to see the files. It sounds like what your dream would have been is if the C Sharp files would have been.cs, but the interfaces would have been like.in. That would have been nice. And then you could sort so so i think you have a very specific use case here for like the works great at the file system level but then inside of your editor it's kind of like i don't know if that's an interface or not but but for all of you out there when you're looking the interface class starts with an i well or any interfaces that you

create you should you should prefix them with that i absolutely so that everybody else is aware that it is an interface even though it bugs you that it's in the wrong place in your directory yeah but do it begrudgingly it's okay you're not the only one so while i'm at it before i get off my soapbox there's a few other nits i've got and they're pretty minor you can't define constructor methods in an interface so i can't create an interface that informs the classes that implement me how those classes can be created and maybe that's a bit controversial but uh you know it's a restriction so basically you're saying you'd like to be able to define a, uh,

a constructor method signature that other, other classes would have to implement. But I think if you're, if you're going to go to that level to define how someone else needs to create their object, then really what you want to do in that scenario would be to define a base class that you intend for someone else to inherit from. So either an abstract class or another class that they can that they can

inherit. Yeah I mean maybe abstract might be the scenario if you actually don't want them to implement it but you definitely in that scenario you would want to have you know define what the constructor should look like and then they would be responsible for doing it Or maybe an abstract class isn't necessary for your particular use case. I mean, it would depend. But I think if you're trying to get to the level where you're saying, hey, you absolutely need to have a constructor that takes a string or an int, then you're getting into a different area, right, than what an interface is supposed to define. Yeah, and that's a good point. I think where I get hung up on it is with

when you're talking about generic functions, one of the restrictions that you can place on a generic function is the new keyword, which means that whatever class you're genericalizing needs to have a constructor that takes no arguments. And that's built into the language, but it stops at that empty constructor. So, you know, maybe it's a into the language but it stops at that empty constructor so you know maybe it's a nicety maybe it's bad practice but i like it and you can't do it i can't do it another thing you can't do is you can't attach interfaces to anonymous classes so um the the only thing that really comes to mind here is that if you're doing some sort of crazy link magic and you want to select some stuff and return it, then you've got to create an actual concrete class of what you're trying to return and just kind of do this weird transfer before returning it from whatever method you're returning.

But when you're talking about anonymous class, you're actually talking about just returning an object that you're defining in a lambda or something like that, right? Right. And I wish that I could say this function returns an ilogable. And then I say select new something or other that's got all the data that ilogable has and return that. But I can't do that directly. I've actually got to create a real class to return it because I can't tell C Sharp that this anonymous object I'm creating that has the same methods as ilogable, there's no way for me to associate those. Can't say that I've run into a scenario for that one yet, though.

Need more interfaces. It's all turtles man if you start incorporating more and more interfaces eventually you get the point I could probably see something like that with like a web API type call when you're passing in like JSON objects or something and you want things to adhere to a particular signature

like I've done some things that would that would potentially benefit from like JSON objects or something, and you want things to adhere to a particular signature. Like I've done some things that would potentially benefit from, potentially. But, I mean, to this point you can't do it, so you just have to find a workaround for it. It's a minor nit. So pretty much to get around that, though, you create private classes within your code, I'm assuming, right? Yep. Okay. Yep. Another thing, static classes.

So if I wanted to have a factory class that creates other classes, and one of the standard examples has been like a pizza factory, and you've got the New York pizza factory and the Chicago pizza factory, and both of them know how to make a pizza, but it's a different kind of pizza. I can't have this generic IPizzaFactory

that has create methods and slap that on both of those classes. I can enforce that that functions there, but there's no way for me to say that there is a relation between Chicago pizza factory and New York pizza factory. Yeah. So modern it. I've only run into it. I was trying to do in factory stuff that I didn't understand then. And then I maybe don't understand now. But I've got the Gang of Four book, and it's like the first one.

So I'm working through it. Yeah, except now that that, I mean, that is, of course, the most popular one, right? Except there's a whole bunch more that have been added onto it in terms of patterns. It's definitely grown. And some people hate the patterns. I don't think. If anybody says they hate the patterns. Then maybe. Especially during an interview.

It might be a good one. That might be a candidate. You just hold off to the side. For a little while. It's these Ruby guys. Now the hate mail is going to come in. So we'll send the hate mail to Joe at Magic. The last nit really was that you're not able to attach interfaces

to existing assemblies. And this one is one that really does bother me. And maybe it's another one of those things that doesn't make sense, but there's a lot of times when I need to do something with one of the built-in Microsoft third-party classes, and it's got a method that I want to use. It's got methods that I want to use, and I want to use it in conjunction with my other stuff, but I can't tell the system.drawing.color class that it's got the r and g and the b that i need to associate with it some other class that i'm using or i can't tell the function that takes in the i whatever

that the system.drawing.color class implements the methods that i need so i can't graft on an interface i can only only graft on methods. Nine times out of ten, what we're trying, well, maybe not even nine times, maybe a smaller number than that, but a lot of the time, what we're wanting to define in Interface 4, though, is to define what those methods are. Right. And so by using an extension method, we might not be able to say that, hey, any color object is going to do this,

but it is automatically able to say that, hey, any color object is going to do this, but is automatically going to have this. But, well, I guess you would be saying that with the extension method. Yeah, they don't all have that. So, again, going back to my comment before, this is another one of those putty kind of things where it was like, hey, you're right, you can't add on an interface to an existing assembly, but we will allow you to add on an extension method to it, which gets you most of the way there.

I mean, really, I guess the only thing that you're missing in that scenario would be you can't say, like, hey, I want to make sure that this color class has this property of my own that I'm defining. You're not going to be able to do that. Not to dive into specifics again, but the problem I ran into is specifically I've got this class, or Microsoft has this class in system.drawing.color that's got some stuff that I need, but I also need these different color spaces, XYZ, RGB, LED, and the system.drawing.color class has the same methods that I've got

and I want to be able to use these by the same functions. So now I can't pass that system.drawing.color around like I can my other objects. So what you end up doing usually is writing some sort of adapter that inherits the color class and then you assign the interface on top of it. It's just nasty. Yeah. Yeah, well, I guess sometimes it gets that way, though. But that's actually, no,

but what you just said is kind of why interfaces are important, because now you can take that primary color class that they have, right, and then you create your class, and you implement your interface, and between, so you basically inherit that class, correct? You implement your interface that now tells you this is the contract that you have to adhere to between that class and yours now. And that's kind of the whole point of the interface, right? Is now you've got your new class that has all the functionality of that color class and your new methods.

And anybody else who wants to do something along those lines can implement that same interface. So, I mean, that's kind of like the whole use case of an interface. And I get why you can't apply an interface to an existing one is because how are you going to make that implemented? Like without using extension methods or something along those lines, how are you going to force now implemented? Like, without using extension methods or something along those lines, how are you going to force now this class that you don't even own, for all intents and purposes you shouldn't even be able to get to, because it's not yours, how are you going to enforce, or how does that fulfill that contract now?

What if it's already there? Now, if it's already there, then why would you even want to put an interface on it? It's already got it. So I can pass it to the functions I have. As the I. I got you. Yeah. So, yeah.

It's something you can't do. It's a nit. I guess where it comes down, the rub is that you're wanting to pass around just the interface to your other methods rather than using that base class color as, hey, pass that around. And then at runtime, it'll figure out which method to call. Right. But you can do that by doing your own class, implementing the interface, inheriting from the main class, and then you have exactly what you want. And you can still pass around that eye color space or whatever it was. Yep.

So, you know, and the great thing about the Internet, too, is maybe our dear listeners will have some input that they'll feel free to contribute. Yeah, back to us with ideas on that. Yeah, maybe there's some weird bit weaving dependency injection, something or other magic that can do that for me. I feel like that would be a pretty good time for Alan to give out that address. You can hit us at comments

at codingblocks.net and you can also go up to the website at www.codingblocks.net and you can leave comments on either on this episode at codingblocks.net slash you can leave comments on either on this episode at codingblocks.net slash episode one or drop us some feedback in the contact form up there as well so you can you can reach us all three ways all right so a little earlier alan made the comment about

you know whenever you use an interface like you implement an interface and it's always private or public rather and you know i made, I made the comment about, well, yeah, that's mostly true, right? Except in the case of explicit. If you do an explicit interface method implementation, then that's not the case, right? So what is an explicit interface method implementation, right? So let's say, for example, we have some interface called, you know, ISave or ISavable, right? And there's a method in it called Save, and you have another interface that's called ICreatable,

and it also has one called Save. And these are off the top of my head kind of example so these might not be the best ones but the point is is that you have two interfaces they both have a save method that they want you to implement right okay and your class that you're writing needs to implement both of these interfaces right well when you're defining your class you cannot declare both of them with the same method signature, right? One of them is going to have to be defined as, let's say that it

was a, it took no parameters and just returned, you know, it was a void. So void save and empty parens, right? So that's going to be the signature for one of them. But the other one is going to have to be something like void isavable.save. That one is going to be private by default. So by default, the compiler, if you don't mark an interface as public, it's going to be public virtual sealed. But if you case of an explicit, it's going to be public virtual sealed but if you case of an explicit it's going to be private so so you're talking about actually calling out the particular declaration from one of the interfaces yeah that's a great way to put it great way to put it so so whatever the interface name is and then dot and the particular method that where there's some overlap between the two

interfaces that's the one that's going to be an explicit implementation right okay it doesn't necessarily have to be you could you could do an explicit not because you had to but just because you're like hey i got this you know i decided to create this interface as explicit just for no reason. In which case, you should really avoid that. You should rethink your life and reconsider your decisions that you've made. So why would you want to reconsider these? What's the harm in calling it explicitly? So I'm saying that kind of like half-jokingly, of course, right?

So you might have a very good reason why you want your interface to be explicit, but normally that's going to be because you have the multiple situation. Something smelly. Yeah, I guess. I'm not sure where you're going with that. So one example I was thinking of. No, no. Code smell, strictly code smell.

It smells great here. I was joking. But one of the examples I was thinking of was if code smell strictly code smell smells great here it's joking but like one of the examples i was thinking of is like if you're talking about like maybe uh some sort of physical object like a board and it's got a a length method and maybe one interface is i metric length and the other is i inches length empirical yeah empirical and if uh if one set of people want to get the length in inches and the other want to get theirs in centimeters, then... Keep going. Well, I think I understand what you're saying, though. Can you explain it back to me?

Well, probably, but I'm not going to. So, I mean, I understand where you're going with that, though. It's a great example of empirical length versus a metric length. And so you want to have some object that that can implement both of those and return back one. But in that scenario, you're going to have to explicitly define one of those length methods in that scenario, which means that, you know, from your user's perspective, they're publicly they're be able to have access to one unless they use the interface. So let's say this scenario, let's go with Joe's board example, right? Board.length. If I create an instance of that class, so I have an object called my board, and I try to call my board.length, I'm going to call the public one.

And let's say that explicitly I defined the metric length, but not explicitly I defined the imperial length, right? So if I call myboard.length, I'm going to get the public imperial length function. However, if I create an object, or not an object, but let's say i define a variable as i i metric let's say i have an i metric variable okay and and i somehow either from a constructor or a cast or whatever i got a board object into there and so with my the way you would do that is you would basically say i empirical my board equal new board, right?

Possibly, yeah. I mean, however it got in there. My point is that you define a variable as I metric. Now with that my I metric variable dot length, I'm going to get the explicit one in that scenario because it is the interface type so it reflects on itself to find out what it should be basically at that point you've defined which which interface you're using so it's going to go to that automatically um yeah there's some other gotchas, though, and I will never – as hard as I try to wrap my head completely around boxing and unboxing, I won't be able to do it justice. where in the case of explicit interface implementations that you'll end up using additional memory that you didn't think that you were going to use

in certain scenarios. It puts it on the stack. Because it'll end up recreating another version of that object. On the heap. Yep. And so it gets hairy, right? So, you know, I mean, like I said, if you have to use it, you know, do an explicit method implementation or interface implementation.

But under normal circumstances, you should just try to avoid it. There's no reason why you should do it. It might look cool and make it seem obvious to other developers what the purpose of that method is, but really you're doing yourself an injustice. Yeah, I'm sure there's a good use case out there for this, but everything I can think of, I would say, is bad practice. And you also create problems, too, in regards to derived classes because now your explicit methods, they're marked as private, so a derived class can't call them either.

So that gets into a hairy situation, which there's some workarounds that you could do. You know, try to try to with, with virtual functions, for example. But yeah, still it's,

I can't think of any like real good reasons that I would absolutely want to do it that don't involve. I had to do it because I need these two interfaces and they both implement the same thing. And really the only time that would happen is if you were basically stepping on the toes of another interface. Like you would never go out of your way to do this, but you weren't aware that iMetric had that or you weren't paying attention when you created your interface. And that's probably why that would happen, right?

Or more often than not, it's probably not even an interface that you created. Right, that's what I'm saying. It's probably just an interface that you need to use. Right. Oh, that, uh, that reminds me, it doesn't really remind me, but there is a bit of a problem with changing your interfaces once they're out in the wild. Yeah. I mean, cause one, cause you know, as we started this off, right.

The number one, uh, you know, answer you get back is that they're, they're a contract, right? So you can't change the contract once it's, it's out there in the wild right so you know the best rule of thumb is if you've already made that interface uh available unless you have it in your power to go back and refactor every use of that interface then if you need to modify it you should just create a new interface that inherits from the old one. Because more often than not, when we create our interfaces, we're not going to have the ability to go back and refactor every single use of it.

Right, and the whole point of the interface anyways was to basically let other people use it. I mean, at the end of the day, IEnumerable, I mean, what if Microsoft decided to change some of that? What would everybody end up doing? Your code would be bunk. You'd have to start over. And that's the whole purpose of the interface is to create the roadmap for people to use it properly. So if you go changing that, you break everybody's stuff. Nobody will ever use your interfaces again, right?

I mean, that's at the end of the day, the interface, it's the same thing. If you write a contract with somebody, if you sign a lease into place, you can't change the terms of that lease three months in. You create a new contract. Or you amend that contract, so you create a new interface that implements from that interface so that you get the features that you need. But chances are you're not touching that existing interface ever again yeah once you've once you've committed that interface out there and you should just consider that to be unchangeable all right so uh i used to work with this guy um awesome guy who kind of sold me on this concept of baking the rules of your application into the grammar and maybe this doesn't make a lot of sense when you're working by yourself, but when you're working with a team of other people who aren't as familiar with how things are

supposed to work, you can actually do a lot just by structuring what's available to them to kind of lead them into this pit of success and have your code be used as it's intended and enforced that way. And so one of the SOLID principles, the actual I in the SOLID, refers to this interface segregation principle. It basically just states that no client should be forced to depend on methods it does not use. So what I take that to mean is that if you don't need it, I don't want you to have it. I don't want you to try and use it.

I don't want you to have it. I don't want you to try and use it. I don't want you to see it and think about it. I want you to focus on, you know, doing as much with as little as you can. And as a kind of API designer, if there's something else that you need that I didn't anticipate, I'd rather we have a conversation about it than kind of hacking some stuff on there or maybe using something in an inappropriate way, which doesn't really apply so much in most places. But if you're working on a large enough team, I think that can be really important. And I think because I've seen Joe's code and I know what he's talking about, I think a way to kind of portray this a little bit is the way that he goes about using this and enforcing this type of interface is he'll have internal classes that do a lot of work.

And the way that he's talking about that he keeps people from basically being their own worst enemies when they're using his code is his internal class might have 50 methods. Well, when you go to get an object out of his factory or whatever the code is that he is generating, you basically say which type of interface object you're getting back. So it could be, I save new file or something like that. And if you're doing that, it's only going to give you a very specific set of sub methods that you can use. Whereas if you say I save old file, then it might have extra things you can do like back up the existing file or, or move the existing file or do something. Whereas the new, the new one's basically just going to give you the functions to basically tell

it where to go. So what he's saying is he only provides you back via the interface access to the, to the methods that are private in the class, but allows you to access certain parts of that. And so his interfaces that he returns back are the declarations that basically segregate what the real logic is from what you're allowed to access. Yeah, and I think that's a big deal when it comes to like third party libraries. Like if you're writing interface to a REST API and you want to implement all those fields because they're

there, you can change them, but you don't always want to. It doesn't make sense. And so it allows you to kind of refactor this object a little bit without actually changing it. So you can kind of add these different facets onto an existing class and inform the caller the kinds of things that they should be setting. Yeah, if you've ever dealt with any or if you ever have to deal with anything such as credit card processing, you'll find that there's like 100 flags that you can flip. If you start reading through the documentation, it'll say, well, if you flip flag one, then the only other flags that matter are flags 10 and 11. Well, as a programmer, if you just have access to this whole library of flags,

chances are you're going to improperly set some of them. Whereas if you define an interface that says, okay, you can only flip these flags if your particular goal is to accomplish this task, then you now set that contract that says, okay, if you do this, you've only got access to these three flags, so you can't really mess yourself up. Whereas if you had access to that entire service, like Joe was talking about, you could potentially set all 100 flags,

and you really don't know what your outcome is going to be because you don't know all the business logic behind it as the developer that came in on this. Yep, and the other thing I do a lot of times is using interfaces for testing, and that's because mocking libraries like MOQMock or RhinoMocks can only create these fake objects

when there's an interface. The reason that I want to create mock objects to begin with is because I'm trying to test the logic that I'm trying to test and not other things like database connections or file system. Event handlers. Event handlers that I don't want to focus on at the time I'm writing the test. So I create these little interfaces that I deal with writing to the database

or writing to the file system, and then I pass the real classes into that test when I want to use them. Sorry, into the class when I want to use them sorry into the class when i want to use them when it comes time to testing i can just kind of mock these out and just focus on the logic and dependency injection falls into the same thing right like i don't want to care what the actual object is i just want to be able to say like okay if as long as it adheres to this implementation then i'm gonna call this method here and over here and that method over there. And I don't care like what actually came in because I might flip that out

at runtime or maybe even as an install, uh, you know, maybe depending on your particular installation, I might include additional, uh, you know, libraries or, uh, you know or object types that I define in your config file, they'll get used and injected in, whereas in another configuration, I might do a different set of types. So, let's talk, I mean, we've talked about some good things, some bad things, some unfortunate things. Let's get into, like, one unfortunate thing that, for me, and I don't know about for you guys when it comes to interfaces, is that for all their glory, they can be a little bit tedious when I'm debugging. Right? When I'm trying to go through the code and, you know, I get to my breakpoint and i'm like okay we're where did this come from and you know at least in in visual studio right you could just click on the object f12 and you know

you see where that magically came from and f12 again and magically see where that came from i've had cases where with interfaces because i got back to the interface eventually i go back to the interface definition and i'm like well that's not really what I wanted to see. What I really wanted to see was where, where did I really come from? Right. At runtime. And maybe this is more of a complaint about, you know, you could argue maybe the, the debugger shouldn't have sent me to the interface definition or maybe

it should have, but you know, at least that's been one unfortunate scenario that I've found. I don't know what you guys think about that. I think you're right. It feels like there should be some sort of key you can press, and maybe there is, that takes you to the real class that's being called and not the interface. Because the debugger knows what's really going on.

It knows which function to call. But when I'm kind of stepping through and then F12ing and shift F12ing through, it can be really annoying. And again, obviously we're talking about the laziest approach here, right? Which is, let's face it, right? Like we're developers for a reason. I think Larry Wall was quite famous for saying that you know uh lazy was one of the three attributes right it was like what was it uh hubris laziness and uh i'm too lazy to remember the other

one so someone else can fill that in so so yeah i mean yeah there are ways someone is going to argue like oh no you could totally like just hover over it it'll show you and if you you click on the little plus symbol there you'll see all the object, and you'll know totally what it is. But that's not the scenario I'm describing here. I mean, I'm being a little bit lazier about it than that. By the way, the third one was impatience, which is – That describes most every program. I was too impatient to remember the whole quote.

But give me some credit. That is an old quote that I remembered. Beautiful. I think, I mean, if you've got a debugger already, and the Visual Studio debugger is nothing to shake a stick at, but it really is a minor nit, but gosh darn it. Well, yeah. Okay, so, I mean, that's like if i had to give it a negative right if i had to

like say name one negative thing about use cases that would probably be the the one that i would throw out there's that there are some weird scenarios in debugging where you know especially if you know that there's one of many objects that might have come back but you you're like, oh, crap, which one actually came back? Right. Well, for me specifically, a lot of times there is only one implementation. So it's especially annoying. I'm like, you know what it is. I know what it is.

Don't make me go get it. But I think on that note, though, even with that negative, and again, that's a nit, we can all agree, everybody should be using interfaces. Everybody should be thinking about how they can make their own interfaces to help make their code more ready for future expansion usage and all that, right? I mean, at the end of the day, they exist for a good reason, and it's typically roadmap and a contract for for what you want this thing to do right yeah i i know at least for me i i've definitely seen yeah you sometimes you look to your colleagues or you look at others that people that have contributed code in books or classes or are on the net sometimes you see other code and you're like that's just a brilliant way to do it yeah i wish i thought of that so yeah i mean there's definitely a lot of value in using it and uh you know we should all just

try to make it a better part of our lives yeah at least figure out a way to put it in there right yeah all right so uh moving on one of the things that we're going to do uh probably try and do in every future episode is we're going to give you like our tip of the week, or it might be a book pick. It might be something that we found that made our life easier and maybe it'll help make your life easier. So, uh, the one that I've got is I found it and I've never looked at it before, but being that we all typically work in other people's code at times. And as, as code evolves, things get, you know know left behind or they don't get used anymore or whatever in visual studio uh at least in 2012 might even be 2010 if you go up to the top section and your usings and you right click there's actually an option in there to basically clean

up your usings and you can even sort it by name so if you right click go in there it's just something you can do while you're in a particular uh cs file or you know probably even vb or so no it'd be cs because i don't vb doesn't have usings but right click say uh clean up your usings and it will get rid of any non-used statements in there and and order them by name so it'll be easier to find is that a resharper feature though no it's visual studio i haven't i haven't tried that one like so let's see if i were to do a using that system that text here that isn't in use man over here is going to try and debunk me no i'm i'm i'm curious though because i didn't i'm sorry i

that really is coming across as a jerk thing to do, I guess. But I didn't, you know, there's so many, like, right-click options that are hidden. And this is, you know, personally, like, Microsoft, if they were to ever listen to this, I think that one thing that has really annoyed me about the direction they went with Studio is if you set yours up as a web developer and I set mine up as a C Sharp developer and Joe sets his up as a, I'm sorry, Joe VB developer, then we all see like a different interface for stuff.

And that find that I find that so confusing. So I don't think I've ever noticed that one though. I'll have to go looking for that one. So, so, so along those kinds of lines though, with, with the interface in visual studio,

one that, that some people don't realize is that if you're, let's say, for example, you want to do a regular expression and you know that you just want a reg x dot is match, right? And, for example, you can't remember the namespace of this thing. But you know that that's the method name and everything. You know that's where it is, right? So you go ahead and write it out there. Of course, you're going to get little squigglies underneath that if you don't already have your using statement in place. Right. So, um, what you can do is, is a shortcut, right? Is you can just, uh, have your mouse curve, your, your cursor over the reg X in that example and do a control period and it'll automatically put in a using statement for you to appoint to system.txt.regular expressions in which

case and save you the trouble or you can also hover over it though and i think it'll also show you like oh do you want to do this in line you know so um so that's one scenario if you didn't know the control period save you a little bit of time and hassle. Yeah, Michael showed this to me. And I'm so used to having a resharper and just doing the control inner thing that I didn't think you could do this. And I was griping about it because when you go to someone else's computer who doesn't have resharper, there are a few people still. Then, you know, it's nice to kind of have this crutch. I feel like JetBrains should probably, like, write in to comments at codingblocks.net.

If you would like to support this show. I feel like we've mentioned that plug-in a few times. And so my tip of the week is Route Debugger. Just discovered this when messing around with some of those MVC routes. They look so pretty, but man, they can get you. They have teeth. So this route debugger, it's a NuGet package. You can just go and install it or type in NuGet install route debugger.

And it's really cool. It throws this little line in your web.config that you can turn on or off. And then you just take a look at a page refresh it and it shows all the information about the route at the very bottom of the page so obviously not something you're going to want to run in production but i was really impressed with how easy it was to install when i first installed the package i kept looking around like okay how do i do it how do i do it and it was just there at the bottom and there there's also one for Web API that Alan happened to independently discover recently and that is also just as cool.

Yeah, it's a Web API route debugger if you're looking for it and it's pretty sweet. If you're having any problems with your Web API calls, give that one a shot. It's also in the NuGet package repository. So that's pretty much our show for today. That, you know, hopefully that helps you out with some of the interface information. I'm pretty certain all of us

learned a little something going through all this. I mean, because, you know, like I said, a lot of us use interfaces a lot. Joe writes them a lot. And, you know, it's a good exercise, and it helps us find out what we should be doing and what we should be, you know, striving to achieve. So check us out on codingblocks.net. And if you have any comments that you'd like to send, any feedback, if you have anything that you have questions or you'd like to see future shows about or whatever, hit us up at comments at codingblocks.net. And you can find all the information, the show notes and everything at codingblocks.net

slash episode one. Finally, we're just getting started and we would love to hear your honest feedback. Please head on over and review us on iTunes.