Hi Tony, Thank you for your video, I like it so much I go back to it every now and then. With that said I hope you are still around and doing great work! I have a question about thinking and writing code on the high level. I still struggle with seeing the bug picture and always go berserk with implementation. Have you got any practical tips on how to achieve this mindset to really code to an interface. When and how did it click for you? How can I impose it my day to day. I would really love to be able to think about programming first in this high level abstract way and only then focus on implementation details.
Hi Tony, coming from Reddit, this videos are great. How about using this arcihtecture in really small but realworld application that uses for example MSSQL?
We will absolutely be making some small real word applications! I am hoping to get a video out today that looks a bit more at data access abstraction along with tests.
Thanks! This is using omnisharp-vim however I have used nvim-lsp with omnisharp as well and it is pretty good. Honest omnisharp-vim offers better features though, with one of the main ones I use being go-to-definition on compiled types and methods such as those in nuget packages or the System libraries. I do have a vim setup video on the channel and plan to do another one soon since a few things have changed since then - namely telescope was released!
I've been playing around with neovim for a while on my mac, and I really wanna move to linux, but I am not confident enough yet :p I mainly work in C#, and I was wondering if you have done some Azure function work in C# on your linux machine, building, debugging etc. in neovim?
I have not! I had done some on windows in neovim but that job wouldn’t allow me to use an OS of my choice. That being said after a quick read of the docs at learn.microsoft.com/en-us/azure/azure-functions/functions-run-local?tabs=v4%2Cwindows%2Ccsharp%2Cportal%2Cbash#v2 nothing seems to stand out as windows only. I’d give it a try in a VM and see how it goes!
@@tonydwire btw. The configs in your GitHub, are those the ones you are currently using? Is there any capability that they might be missing for c# development off the top of your head?
I like the topic, but did everyone put the program together while watching him? I followed his programming verbatim and the file is created but no data is put into the file. Maybe provide the ability to download the project for comparison.
Would be great to see this stuff but a real example. perhaps CRUD for a database or something. Great video though. it's helpful to see it. Also put the code on github or similar :)
Really nice video. Thank you for putting it together. I learned a whole new approach. Question: if you wanted your processor to return a value then would you need an generic interface for the processor and create a write method to return data?
I tend to think of the “processor” as basically the new entry point into the program once all your dependencies are set up (from main). With that in mind it’s much like main itself - usually returning void or in some cases an error code. Having it return something breaks the point of keeping your logic outside of main. I hope that makes sense! That said, you can certainly have it return something, generic or not. But I would generally say just do what you would do with that return inside the processor itself.
Great video. Thank you. I’m also trying to write in this way. But whenever I write such code I always ask myself: “Why don’t I just write a function?” Class with one method could be replaced with partially applied function (using lambdas) and passed to other functions using generic or specific delegates. And we don’t have to create interfaces and class implementations for them. Such code will be much more compact. One thing that stops me from doing this: my colleagues are not familiar with FP. Maybe you know other benefits of using such classes over the interfaces?
This is definitely true in some situations. The most common one we see in C# are the LINQ extension methods. Imagine if we had to use a class instance every time we needed to call IEnumerable.Where. It would be a nightmare! I would suggest using functions where they make sense, which is when most call sites will have a unique implementation, and use classes and interfaces when things will usually use the same implementation or there are very few potential call sites.
This video is very useful! I have one small question: is it good to use abstract classes instead of interfaces in situations like that, or better to stick with interfaces?
Thanks! I would say interfaces cover most situations except when you need to provide functionality in the abstraction itself. One of my favorite uses of abstract classes is the Template Method pattern. This lets you write the skeleton of an algorithm in the abstract class and then put abstract methods on the class for subclasses to fill out details. I’ll try and get a video for abstract classes going soon I don’t think I’ve really covered them.
Hi friend. Super useful video. I'm looking forward to watching your video on SOLID principles. Just a thought. You also teased a tutorial involving dependency injection at the end, which is exactly what I need to learn next, so I clicked your page and looked up that video. I bet if you included links in this video description to the SOLID and DI videos, it would boost your view count. Also, a theoretical question. I asked on Reddit recently why, when we create an object, it's of the interface type rather than the class that already implemented that interface. (From the responses, the answer involves dependency injection, which is why I'm going to be looking into that). Anyway, some of the ensuing discussion involved whether the principle involved is the Liskov inversion principle or the Dependency inversion principle. I wonder if you have a thought on that.
It all really depends on how it’s used. If you’re just creating an object it doesn’t usually matter what type you assign it to (this is why the var keyword works so well), however when you design methods that use these objects, it is best to design them to use the interface of that object so that you can later pass in different types that implement that interface if needed. This isn’t something you have to do literally everywhere and as you grow as a software developer you will get the hang of when it makes sense. As for your question, It is both liskov substitution and dependency inversion. Taking an interface into your method allows you to use the liskov substitution principle to substitute any types that implement the required interface. It is (or can be) dependency inversion because you are allowing the passed in type to determine behavior - relying on an abstraction instead of a concrete type. I would recommend picking up the book Clean Code by Robert C. Martin, that is the original source for most of this stuff and it is a really good read!
Afraid I can’t agree with you here. Was only 2 minutes of introduction and had some complex concepts to introduce. It might benefit from a visual slide or two in that time, so the introduction isn’t entirely dependent on speaking.
These videos are aboslutley amazing. Couldn't recommend Betterc# more. Many students of the code, have no idea what they are missing..
These videos are aboslutley amazing!!!!!
Hi Tony,
Thank you for your video, I like it so much I go back to it every now and then. With that said I hope you are still around and doing great work!
I have a question about thinking and writing code on the high level. I still struggle with seeing the bug picture and always go berserk with implementation.
Have you got any practical tips on how to achieve this mindset to really code to an interface.
When and how did it click for you? How can I impose it my day to day. I would really love to be able to think about programming first in this high level abstract way and only then focus on implementation details.
your videos are very very good. thanks for those lectures!
I loved it. Thank you so much for the explanation👏
Honestly, Clean code is one of the best books I could have read, it literally changed the way I code.
I couldn’t agree more! I go back and reread it every year or so
Love these videos... Thank you!
Hi Tony, coming from Reddit, this videos are great. How about using this arcihtecture in really small but realworld application that uses for example MSSQL?
We will absolutely be making some small real word applications! I am hoping to get a video out today that looks a bit more at data access abstraction along with tests.
Nice video! Are you using nvim-lsp or CoC for completion? Would be interesting with a "setup Vim for C#" video :)
Thanks! This is using omnisharp-vim however I have used nvim-lsp with omnisharp as well and it is pretty good. Honest omnisharp-vim offers better features though, with one of the main ones I use being go-to-definition on compiled types and methods such as those in nuget packages or the System libraries. I do have a vim setup video on the channel and plan to do another one soon since a few things have changed since then - namely telescope was released!
I've been playing around with neovim for a while on my mac, and I really wanna move to linux, but I am not confident enough yet :p
I mainly work in C#, and I was wondering if you have done some Azure function work in C# on your linux machine, building, debugging etc. in neovim?
I have not! I had done some on windows in neovim but that job wouldn’t allow me to use an OS of my choice. That being said after a quick read of the docs at learn.microsoft.com/en-us/azure/azure-functions/functions-run-local?tabs=v4%2Cwindows%2Ccsharp%2Cportal%2Cbash#v2 nothing seems to stand out as windows only. I’d give it a try in a VM and see how it goes!
@@tonydwire Thanks a lot for the reply! Yea, I think I’ll give it a go in a vm 😃
@@tonydwire btw. The configs in your GitHub, are those the ones you are currently using? Is there any capability that they might be missing for c# development off the top of your head?
I like the topic, but did everyone put the program together while watching him? I followed his programming verbatim and the file is created but no data is put into the file. Maybe provide the ability to download the project for comparison.
Needed to flush after each WriteLIne
_streamWriter.WriteLine( data );
_streamWriter.Flush(); // without the flush the file was empty
This structure is so practical and underused. Really nice video.
Thank you!
@@tonydwire missing your videos hope you are doing alright
You just taught dependency injections best way possible
Would be great to see this stuff but a real example. perhaps CRUD for a database or something. Great video though. it's helpful to see it. Also put the code on github or similar :)
So practical. Thank you!
Love you from Korea
Really nice video. Thank you for putting it together. I learned a whole new approach. Question: if you wanted your processor to return a value then would you need an generic interface for the processor and create a write method to return data?
I tend to think of the “processor” as basically the new entry point into the program once all your dependencies are set up (from main). With that in mind it’s much like main itself - usually returning void or in some cases an error code. Having it return something breaks the point of keeping your logic outside of main. I hope that makes sense! That said, you can certainly have it return something, generic or not. But I would generally say just do what you would do with that return inside the processor itself.
Great video. Thank you.
I’m also trying to write in this way.
But whenever I write such code I always ask myself: “Why don’t I just write a function?”
Class with one method could be replaced with partially applied function (using lambdas) and passed to other functions using generic or specific delegates.
And we don’t have to create interfaces and class implementations for them. Such code will be much more compact.
One thing that stops me from doing this: my colleagues are not familiar with FP.
Maybe you know other benefits of using such classes over the interfaces?
This is definitely true in some situations. The most common one we see in C# are the LINQ extension methods. Imagine if we had to use a class instance every time we needed to call IEnumerable.Where. It would be a nightmare! I would suggest using functions where they make sense, which is when most call sites will have a unique implementation, and use classes and interfaces when things will usually use the same implementation or there are very few potential call sites.
This video is very useful! I have one small question: is it good to use abstract classes instead of interfaces in situations like that, or better to stick with interfaces?
Thanks! I would say interfaces cover most situations except when you need to provide functionality in the abstraction itself. One of my favorite uses of abstract classes is the Template Method pattern. This lets you write the skeleton of an algorithm in the abstract class and then put abstract methods on the class for subclasses to fill out details. I’ll try and get a video for abstract classes going soon I don’t think I’ve really covered them.
@@tonydwire thanks for the answer, looking forward for new videos!
I'd say that typing too fast and making a lot of errors can get a little distracting from your video. Slow down the pace of your typing instead
Hi friend. Super useful video. I'm looking forward to watching your video on SOLID principles. Just a thought. You also teased a tutorial involving dependency injection at the end, which is exactly what I need to learn next, so I clicked your page and looked up that video. I bet if you included links in this video description to the SOLID and DI videos, it would boost your view count. Also, a theoretical question. I asked on Reddit recently why, when we create an object, it's of the interface type rather than the class that already implemented that interface. (From the responses, the answer involves dependency injection, which is why I'm going to be looking into that). Anyway, some of the ensuing discussion involved whether the principle involved is the Liskov inversion principle or the Dependency inversion principle. I wonder if you have a thought on that.
It all really depends on how it’s used. If you’re just creating an object it doesn’t usually matter what type you assign it to (this is why the var keyword works so well), however when you design methods that use these objects, it is best to design them to use the interface of that object so that you can later pass in different types that implement that interface if needed. This isn’t something you have to do literally everywhere and as you grow as a software developer you will get the hang of when it makes sense. As for your question, It is both liskov substitution and dependency inversion. Taking an interface into your method allows you to use the liskov substitution principle to substitute any types that implement the required interface. It is (or can be) dependency inversion because you are allowing the passed in type to determine behavior - relying on an abstraction instead of a concrete type. I would recommend picking up the book Clean Code by Robert C. Martin, that is the original source for most of this stuff and it is a really good read!
@@tonydwire I have a copy on my phone which I will crack open soon. Thanks for your thoughts.
fascinating.
Topics: high performance in C# tips
Just pointing out that it's way too much Needless intro. You may consider cutting some of that out so you don't loose people
Thanks, I’ll take that under advisement! I also agree it is a lot
Afraid I can’t agree with you here. Was only 2 minutes of introduction and had some complex concepts to introduce. It might benefit from a visual slide or two in that time, so the introduction isn’t entirely dependent on speaking.
@@davidbaker251 I agree I needed it, that is why I am here!
Don't write code as you present, have it done already and highlight bits of it
oh if only people would remember theres this cool thingy called zoom. Im watching these on mobile and all looks like ants lol
I know right! Sorry about that I think the same thing but at the time it didn’t cross my mind