I haven't come across any channel or source that explains things like you explain in your videos. I like understanding to the core and used to think how exactly things work at memory level. You content makes it all clear. Thank you so much.
I did not understand over 90% but that’s because I am learning C# and watching videos explaining static. However, thank you very much for taking the time to explain it so detailed.
Well explained Shiv.. am watching your channel many years by now. It would be really good if you show examples(code) at the end after explaining the concepts. Good job Shiv for your effort.
Thank you Loyola! I appreciate you taking the time to comment. Good point about showing code. Of course in my mind I didn't think code was required since I was primarily explaining the memory model for objects and statics. I'll take a look at the video to see if I could/should have included code. I'll be more mindful going forward. What/where do you feel code would have helped explain things better? What should be code have shown?
@@Matlus I suppose he is asking, how do you unit test your static methods?? Really like your channel btw. It is very refreshing to listen to someone who knows what he is talking about. Keep it up.
@@ChowdhuryMRahman I understood his question and I thought I answered :). What's so hard about testing static classes and methods? I guess I don't understand why you have the questions :).
You have so much clear understanding on all topics. I am very much eager to know where do you work?? I didn't find any info in your LinkedIn profile.. Thanks for this wonderful lecture
Great explanation Shiv, one scenario I'd imagine static wouldn't make sense is IOC containers. Since it's not possible to dependency inject static classes, there may be a case of dependency hiding if the class refers to static methods. I maybe wrong, I'd like to know your thoughts on this.
Sounds good, thanks for your great video. Do you have a chance to make a video ever with yours overview regarding legacy stuff and about of moving legacy's logic in some of a ways via application engine currently supporting and developing and looks modern.
Hello Alisher, I haven't made a video on this subject. I've done a few of these types of project and all I can say is there is no "one size fits all" solution or approach. If the legacy code can be modified to use new applications, or is the legacy systems are already using services, then building services the support specialized functionality will be the way to go. The legacy system will either have to support the idea of services (if it's a monolith) or learn to talk to the new services.
@@Matlus Thank you for explanations. We are currently working on a supporting big one legacy system(payment processing) and any opinions are useful for us. Same time we are moving another one legacy project(payment processing as well) using a modern core abilities(it has rest api, but we use its business layer)
@@alisherletifov154 I think you'll need to have the design and architecture of the final system (the services and their interactions). If you have this, you should then be able to plan a migration (from A [legacy] to B [final system design]). It's impossible for me to help in any way without spending a lot of time understanding the existing systems as well as the business and its future direction. Depending on the size and complexity of the business that could take months. I'm sorry, but I don't feel qualified to make any suggestions. You may want to take a look at my videos on API design (parts 1 & 2) and the Playlist I have on Programming with Intent. The reason is, no matter what the architecture of the final system, where things go wrong is in the design & implementation and the Programming with Intent series focuses on design and implementation.
So whether or not a class is static, the dotnet runtime will ensure that there is only one TYPE instance of that class in memory. Is shiv saying that the use of statics is his way of reflecting this better in code? So by having a static, the code looks closer to what actually exists in memory, and it's therefore more desirable?
Shiv, thank you so much for your efforts. This was very much informative video. PS: I created a Reddit post yesterday to spread word. It got around 40 upvotes. Hopefully some people have subscribed. As you don't have ads enabled, I think RUclips is not promoting your channel. I might be wrong when I say so. So only option to reach out to many people is through word of mouth :) Edit: got over 65 upvotes
Wow! Thank you so much Vinay. Yes, I believe RUclips promotes channels that have ads turned on more so than those that don't. Maybe it's time to turn on ads :)
I'm a premium subscriber and I know that means something different to content creators. If nothing else, my stats are different. I've shared Shiv's video on pipelines on an internal chat board because he pointed out something to me that was absolutely blocking me in understanding how to get code to Azure. I was so freaking happy. My company is using Azure for most everything but I'm one of the few that use MS tools. I was once just a standard grunt, now I'm a trailblazer.
I've never been a great exponent of static for the obvious reasons what you've mentioned. On the flip side what you're saying in favor of static does make a lot of sense. I'm pondering to use static a bit more. But I've got a small query on the 'autonomous' methods. If these methods are allowed to change the STATE then there might have plenty of rooted objects. And they will survive GC 0 & 1 and eventually reach Gen 2 because of the reference to the static. Which might degrade the performance of an application and potentially could cause a memory leak. If so then is it safe to allow these methods to change the state? I might have missed something about the autonomous methods though.
Static class should have no state. Autonomous methods operate only on method arguments and local variables. So they don't hold a reference to anything. Even if they change state (of an object passed in as an argument) they're not holding a reference so at least insofar as the static class/method is concerned there is no implication to GC gen 1, 2 you mention. Static classes (all classes for that matter) have a type instance. Not class instance. Also, in my other video I talk about DTOs being immutable and behavior classes not having state, so net net no state change. Its possible I don't fully understand your question, if so if you could provide a code example I that will help.
Please clarify my understanding is write or wrong from above video .... C# compiler always generated * type instance * of each .cs file. Of particular .dll file which are used by my programm In the memory before .dll file is expecuted in jit compiler... And jit compiler cannot create instance of static class Thanks for this valuable lecture
A Type instance it created at run time (not compile time). So it occurs after the JIT compiler has compiled the code. A type instance is created "just before use" and so is not related to .cs file or .dll. This is a run time phenomenon and depends entirely on what is being used at run time.
That's very unusual and could be bad design. I mean the reason you have an object is because you have multiple instances where each has their own data. I know I've seen this in various places on the Internet, but in a production system, you won't use a static field, you'd use a database or a thread-safe cache or some sort. The static member is not threadsafe so if two instances are trying to update this value the incrementing of this value is not automic and could result in exceptions.
Singleton's are an instance. They're not static. If you understand static, then there should be no confusion. Statics can't be passed to methods or returned from methods. So sometimes (due to Dependency injection) folks will resort to singletons instead.
@@Matlus I know that sir. But in this video too, i believe listening you saying Static is implemented internally as instance of a class. So was my question!
@@vishnupv2008 All classes have to have a "Type" instance. This is not the same as a "Class" instance. Static classes only have a "Type" instance, while non static classes have a "Type" instance as well as a "Class" instance. Hope that makes it clear?
@@Matlus Completely agree with the other person. Honestly, had my professors 20 years ago explained all of this stuff and plainly as you did, it would have been a lot easier to process (I obviously "got it" eventually, but it certainly would have made it a hell of a lot easier). Edit: Of course, C# was literally just coming out that far back (I remember going to the .Net release event in Redmond as a college student), but that's besides the point! :D
Shiv, this is absolutely fantastic. Usual format of teaching any programming concept is to show a demo with simple example but missing the under-the-hood details. We code all the day but sometimes we just want to listen/talk about the code. Let's talk - much appreciated.
I love your Explanation and way of teaching style.I confused static classes now i got good clarification thanks a lot for ur support.when i am creating static class you only come to my brain.Once a again,Pleae make video for Interface and Threading.Once again Thanks and god bless u.
Shiv, I read that static data exists even before program executes and till program terminates in context of an appDomain. But my understanding is that static data is loaded into memory only when type which defines those static data is used somewhere in program. 1. So when does static data actually load into memory? 2.Also please throw some light on what is appDomain in technical terms?
Hi Vinay, Static data (not constants), that is data that is a member of the Type. Will only come into existence when the instance is created. It can't before that. Once a Type instance is created, it stays alive for the lifetime of the app domain. So this data will exist till the app domain is shut down. An app domain is similar to a Win32 process (they're not exactly the same, but for the sake of this discussions they are the same). If you run a console applications by double clicking on the exe file then there is one app domain associated to that instance. When you double click on the exe file again, and the console app runs (so now you see 2 console windows) again, you have another app domain. These are completely separate. They don't share any memory. So that mean on your machine there are 2 app domain (1 for each exe running) and each app domain has Type instances for all types you've touched in your applications.
Yes. But that's probably only because F# lives in a runtime that inherently object oriented. Or that easiest way to translate between a functional and object oriented language it to present the functional side as a static class. But in C# static classes actually have a meaning since we have instance classes as well.
@@Matlus Very true, dealing with static classes could be cumbersome until they added the "using static" statement. Now that we have global using, it saves a whole lot of time importing namespaces and static classes.
Most of the code posted on this channel has examples. But if you're prefer an entire solution that has a ton of static classes, you can find one here: github.com/matlus/MovieServiceRUclips
Thanks Shiv for this fantastic series. Just a query, as you have said in video that you have 50% of static classes in your code. So does it impact the performance of having more static classes because static classes are long lived and they reside in Generation 2 of garbage collector ?
Thank you Himanshu! And you're most welcome. Long lived objects don't cause a performance issue, since they don't need to garbage collected. Long lived objects that weren't intended to be long lived are a memory leak and over time can cause issues as you'll run out of memory in left unchecked. Remember that static are really type instances as runtime and are allocated exactly once per app domain. This is true even for instance classes. That is, instance classes also have a type instance that is allocated exactly once per app domain. So effectively static classes don't add any more pressure to the GC and thus don't cause performance issues. In fact calling methods of static classes is faster (albeit microseconds faster) because calling these methods does not require passing the "this" argument.
Hi shiv sir, I have a question regarding static. From memory allocation point of viee happens when we create generic class with generic methods and when we use these static method then at time of calling the somehow we have to provide concrete type for that generic parameter. Sir can u plz explain how memory is allocated for those methods and class when use these methods for different types? Is there a new copy is created for each type or what? Sir please help me understanding this?
If I understand your question correctly Firoz, I don't think this has anything to do with Static but more to do with code at the call site or Generics, or rather how is generics implemented in C#/.NET. Can you please provide a code example and then reference the particular line(s) of code when you ask the question.
Following this series... Absolutely loving it.
Thank you Far Horizon! Please also watch the other videos and let me know what you think.
I haven't come across any channel or source that explains things like you explain in your videos. I like understanding to the core and used to think how exactly things work at memory level. You content makes it all clear. Thank you so much.
I did not understand over 90% but that’s because I am learning C# and watching videos explaining static. However, thank you very much for taking the time to explain it so detailed.
Great advice and video from an architectural point of view.
Thank you Zapanath. Glad you enjoyed it.
Well explained Shiv.. am watching your channel many years by now. It would be really good if you show examples(code) at the end after explaining the concepts. Good job Shiv for your effort.
Thank you Loyola! I appreciate you taking the time to comment.
Good point about showing code. Of course in my mind I didn't think code was required since I was primarily explaining the memory model for objects and statics. I'll take a look at the video to see if I could/should have included code. I'll be more mindful going forward.
What/where do you feel code would have helped explain things better? What should be code have shown?
another excellent video!
thanks for sharing your knowledge Shiv! 🚀
Glad you liked it Humberto! And Thank you.
This is what I was looking for ❤️ Perfect
Thank you!
what about testing static classes?
What about them? They are classes :)
@@Matlus I suppose he is asking, how do you unit test your static methods?? Really like your channel btw. It is very refreshing to listen to someone who knows what he is talking about. Keep it up.
@@ChowdhuryMRahman I understood his question and I thought I answered :). What's so hard about testing static classes and methods? I guess I don't understand why you have the questions :).
You have so much clear understanding on all topics.
I am very much eager to know where do you work?? I didn't find any info in your LinkedIn profile..
Thanks for this wonderful lecture
Thank you Pawan! IF you look at my LinkedIn profile you should be able to see that I for at Applied Information Sciences (AIS).
Great explanation Shiv, one scenario I'd imagine static wouldn't make sense is IOC containers. Since it's not possible to dependency inject static classes, there may be a case of dependency hiding if the class refers to static methods. I maybe wrong, I'd like to know your thoughts on this.
That's true Abhishek. But I don't care for Dependency injection :) You should see my videos where the Title starts with "Lets Talk" :)
Sounds good, thanks for your great video. Do you have a chance to make a video ever with yours overview regarding legacy stuff and about of moving legacy's logic in some of a ways via application engine currently supporting and developing and looks modern.
Hello Alisher, I haven't made a video on this subject. I've done a few of these types of project and all I can say is there is no "one size fits all" solution or approach. If the legacy code can be modified to use new applications, or is the legacy systems are already using services, then building services the support specialized functionality will be the way to go. The legacy system will either have to support the idea of services (if it's a monolith) or learn to talk to the new services.
@@Matlus Thank you for explanations. We are currently working on a supporting big one legacy system(payment processing) and any opinions are useful for us. Same time we are moving another one legacy project(payment processing as well) using a modern core abilities(it has rest api, but we use its business layer)
@@alisherletifov154 I think you'll need to have the design and architecture of the final system (the services and their interactions). If you have this, you should then be able to plan a migration (from A [legacy] to B [final system design]). It's impossible for me to help in any way without spending a lot of time understanding the existing systems as well as the business and its future direction. Depending on the size and complexity of the business that could take months. I'm sorry, but I don't feel qualified to make any suggestions.
You may want to take a look at my videos on API design (parts 1 & 2) and the Playlist I have on Programming with Intent. The reason is, no matter what the architecture of the final system, where things go wrong is in the design & implementation and the Programming with Intent series focuses on design and implementation.
@@Matlus great! Thanks a lot for helping out.
This series is awesome. Thanks a lot
Just great, thank you!
So whether or not a class is static, the dotnet runtime will ensure that there is only one TYPE instance of that class in memory. Is shiv saying that the use of statics is his way of reflecting this better in code? So by having a static, the code looks closer to what actually exists in memory, and it's therefore more desirable?
Great talk, very useful!
Thank you Javi! Glad you found it useful
Shiv, thank you so much for your efforts. This was very much informative video.
PS: I created a Reddit post yesterday to spread word. It got around 40 upvotes. Hopefully some people have subscribed. As you don't have ads enabled, I think RUclips is not promoting your channel. I might be wrong when I say so. So only option to reach out to many people is through word of mouth :)
Edit: got over 65 upvotes
Wow! Thank you so much Vinay. Yes, I believe RUclips promotes channels that have ads turned on more so than those that don't. Maybe it's time to turn on ads :)
I don't keep a track of the subscribers, but it sure looks like there are at least 50 new subscribers!!
Shiv, no problem :)
I'm a premium subscriber and I know that means something different to content creators. If nothing else, my stats are different.
I've shared Shiv's video on pipelines on an internal chat board because he pointed out something to me that was absolutely blocking me in understanding how to get code to Azure. I was so freaking happy.
My company is using Azure for most everything but I'm one of the few that use MS tools. I was once just a standard grunt, now I'm a trailblazer.
@@bgroesser Thank you Barry! Thank you also for taking the time to comment. I'm very encouraged by it.
Excellent, thanks!
You're welcome Ross! And thank you.
Thank you for this great explanation!
I've never been a great exponent of static for the obvious reasons what you've mentioned. On the flip side what you're saying in favor of static does make a lot of sense. I'm pondering to use static a bit more. But I've got a small query on the 'autonomous' methods. If these methods are allowed to change the STATE then there might have plenty of rooted objects. And they will survive GC 0 & 1 and eventually reach Gen 2 because of the reference to the static. Which might degrade the performance of an application and potentially could cause a memory leak. If so then is it safe to allow these methods to change the state? I might have missed something about the autonomous methods though.
Static class should have no state. Autonomous methods operate only on method arguments and local variables. So they don't hold a reference to anything.
Even if they change state (of an object passed in as an argument) they're not holding a reference so at least insofar as the static class/method is concerned there is no implication to GC gen 1, 2 you mention.
Static classes (all classes for that matter) have a type instance. Not class instance.
Also, in my other video I talk about DTOs being immutable and behavior classes not having state, so net net no state change.
Its possible I don't fully understand your question, if so if you could provide a code example I that will help.
@@Matlus Fair enough. A great video as usual.Thanks a ton for the clarification. 👌
Great content as always. Would it be correct to summarise by saying static’s are type objects and instances are class objects?
That is correct!
At 17:55 you mentioned type instance of type object , isn’t instance and object same? -am I missing something
Hi Smitha, good to see you here!. I believe I said Type instance OR Type object :). You're correct, instance and object are synonymous.
Shiv Kumar thank you for instant reply shiv
Can’t wait to watch all of your videos
@@smithakalluparambil yes, please do!
Please clarify my understanding is write or wrong from above video
....
C# compiler always generated * type instance * of each .cs file. Of particular .dll file which are used by my programm In the memory before .dll file is expecuted in jit compiler...
And jit compiler cannot create instance of static class
Thanks for this valuable lecture
A Type instance it created at run time (not compile time). So it occurs after the JIT compiler has compiled the code. A type instance is created "just before use" and so is not related to .cs file or .dll. This is a run time phenomenon and depends entirely on what is being used at run time.
Thanks for ur valuable information
You're most welcome!
what about storing data between instances. like hit count, here it has state ? but static is used right ?
That's very unusual and could be bad design. I mean the reason you have an object is because you have multiple instances where each has their own data. I know I've seen this in various places on the Internet, but in a production system, you won't use a static field, you'd use a database or a thread-safe cache or some sort. The static member is not threadsafe so if two instances are trying to update this value the incrementing of this value is not automic and could result in exceptions.
Pls provide link of your video about difference between static class and single ton class...
Thanks for this video
Singleton's are an instance. They're not static. If you understand static, then there should be no confusion. Statics can't be passed to methods or returned from methods. So sometimes (due to Dependency injection) folks will resort to singletons instead.
How a singleton class differs from a static class in C#, internally?
Singleton is not Static :). There is a instance (class object, in addition to type object), but just one instance.
@@Matlus I know that sir. But in this video too, i believe listening you saying Static is implemented internally as instance of a class. So was my question!
@@vishnupv2008 All classes have to have a "Type" instance. This is not the same as a "Class" instance. Static classes only have a "Type" instance, while non static classes have a "Type" instance as well as a "Class" instance. Hope that makes it clear?
@@Matlus Thank you very much! I will do further reading.
Fantastic content Shiv!
Your style of explanation is really in depth and thorough, yet still simple to understand
Thank you semco! Your comment is much appreciated.
@@Matlus Completely agree with the other person. Honestly, had my professors 20 years ago explained all of this stuff and plainly as you did, it would have been a lot easier to process (I obviously "got it" eventually, but it certainly would have made it a hell of a lot easier).
Edit: Of course, C# was literally just coming out that far back (I remember going to the .Net release event in Redmond as a college student), but that's besides the point! :D
Shiv, this is absolutely fantastic. Usual format of teaching any programming concept is to show a demo with simple example but missing the under-the-hood details. We code all the day but sometimes we just want to listen/talk about the code. Let's talk - much appreciated.
I love your Explanation and way of teaching style.I confused static classes now i got good clarification
thanks a lot for ur support.when i am creating static class you only come to my brain.Once a again,Pleae make video for Interface and Threading.Once again Thanks and god bless u.
Thank you Thirumala! I appreciate your comment. I'll try and make videos on the topics you've requested.
Shiv, I read that static data exists even before program executes and till program terminates in context of an appDomain.
But my understanding is that static data is loaded into memory only when type which defines those static data is used somewhere in program.
1. So when does static data actually load into memory?
2.Also please throw some light on what is appDomain in technical terms?
Hi Vinay,
Static data (not constants), that is data that is a member of the Type. Will only come into existence when the instance is created. It can't before that.
Once a Type instance is created, it stays alive for the lifetime of the app domain. So this data will exist till the app domain is shut down.
An app domain is similar to a Win32 process (they're not exactly the same, but for the sake of this discussions they are the same). If you run a console applications by double clicking on the exe file then there is one app domain associated to that instance. When you double click on the exe file again, and the console app runs (so now you see 2 console windows) again, you have another app domain. These are completely separate. They don't share any memory. So that mean on your machine there are 2 app domain (1 for each exe running) and each app domain has Type instances for all types you've touched in your applications.
A C# Static Class is pretty much preforming the function as a module. If you create module in F#, when import into C# it will be a Static Class.
Yes. But that's probably only because F# lives in a runtime that inherently object oriented. Or that easiest way to translate between a functional and object oriented language it to present the functional side as a static class. But in C# static classes actually have a meaning since we have instance classes as well.
@@Matlus Very true, dealing with static classes could be cumbersome until they added the "using static" statement. Now that we have global using, it saves a whole lot of time importing namespaces and static classes.
Great explanation of static class.
Thank you Nandkishor
26 minutes without any practical example in code???????????
Most of the code posted on this channel has examples. But if you're prefer an entire solution that has a ton of static classes, you can find one here: github.com/matlus/MovieServiceRUclips
Thanks Shiv for this fantastic series. Just a query, as you have said in video that you have 50% of static classes in your code. So does it impact the performance of having more static classes because static classes are long lived and they reside in Generation 2 of garbage collector ?
Thank you Himanshu! And you're most welcome.
Long lived objects don't cause a performance issue, since they don't need to garbage collected. Long lived objects that weren't intended to be long lived are a memory leak and over time can cause issues as you'll run out of memory in left unchecked.
Remember that static are really type instances as runtime and are allocated exactly once per app domain. This is true even for instance classes. That is, instance classes also have a type instance that is allocated exactly once per app domain. So effectively static classes don't add any more pressure to the GC and thus don't cause performance issues. In fact calling methods of static classes is faster (albeit microseconds faster) because calling these methods does not require passing the "this" argument.
Thanks for the clarification. I really appreciate your efforts that you are putting in your videos as well as in resolving queries.👍
Excellent and thorough eye-opener. Thank you!
Thank you Stephen! Glad you think so.
Do you teach one to one or in batch?
Generally in a batch or folks on my various teams.
Hi shiv sir,
I have a question regarding static.
From memory allocation point of viee happens when we create generic class with generic methods and when we use these static method then at time of calling the somehow we have to provide concrete type for that generic parameter.
Sir can u plz explain how memory is allocated for those methods and class when use these methods for different types?
Is there a new copy is created for each type or what?
Sir please help me understanding this?
If I understand your question correctly Firoz, I don't think this has anything to do with Static but more to do with code at the call site or Generics, or rather how is generics implemented in C#/.NET.
Can you please provide a code example and then reference the particular line(s) of code when you ask the question.
For generics, please take a look at this video ruclips.net/video/MIZFp5m3Pus/видео.html
@@Matlus ok sir,
I will share code with you.
@@Matlus drive.google.com/file/d/17s3Vs8IoJlmXDS43lbYAcgTRYtUnxJrs/view?usp=drivesdk
@@Matlus Sir,
Please let me know if this clears my intentions for question .