File size

File size

File size

File size

File size

151.1 MB

Now that you have a good sampling of basic C# syntax under your belt, it's time to tackle some more challenging topics. Classes are integral to the .NET Framework, particularly the .NET Framework Class Library. This lesson demonstrates how classes are defined and new instances are created, how to define Properties (using the prop "code snippet" to create auto implemented properties), and how to both set values and get values for a given instance of the class as well as creating Methods in our classes. We talk about how the classes you create are really custom dat types that can be used as such in helper method declarations and more.

I've been in some form of programming for the past 15 years but, as a largely self-taught student, I have gaps in my knowledge. This is true both in theory and environment specifics (VS 20xx). I really appreciated this lesson and look forward to viewing the rest of the series. I highly recommend this series for new(er) developers!

In a nut shell, a static method is a method you want to call without having to create an instance of the class that contains it. Think: utility function. The .NET class library has a bunch of these. For example, the DateTime.Parse() is a good example ... I don't necessarily have an instance of the DateTime class right now, but I want to use the Parse() method anyway.

A static constructor will run once prior to an instance of the class is created (once for all instances of a non-static class) or whenever a static method is called (again, once).

The question you probably have is "why would I ever use this stuff"? The answer becomes evident when you're creating an API that encapsulates functionality for your organization. If you are assigned to create a component / API / whathaveyou that can be utilized across many applications and used by a set of developers tasked with creating apps that consume your API. In that case, you are more likely to need to initialize some things, make some utilities, etc. You could ignore these adornments to your classes (I.e., not make things static, etc.) however these adornments constrain developers and guide them to the usage of the API's methods.

Most likely, as I said in this series, you'll see .NET framework classes / methods created in this manner, and they exist to constrain and guide YOU, the consumer of THEIR API. So, even though you many not have a project for a while that needs this sort of fidelity of control over how people call your methods TODAY inside your own projects, at the very least, you are using these in the .NET Framework. Hope that all makes sense?

@kapil: Hi. Have you been watching these videos? What specifically is challenging to you? Since you posted this in lesson 14, Classes ... can I assume that (1) you have been watching from the beginning? (2) You have been following along doing the code examples while I write them? Honestly? Some concepts take a few passes to really understand them. You may need to hear the same ideas from different sources. There are innumerable other tutorials online ... videos, articles, ebooks, physical books, etc. Just find something that resonates with you and then treat it like it's the most important thing to you -- you will not be denied! That's how you learn -- when you struggle and refuse to give up. The materials you use are (almost) irrelevant. Best wishes!

@Maha: So, the difference in SIMPLE scenarios is mainly conceptual. In larger systems, the difference is more obvious and more practical. The difference: what you've defined in your code example are called "public fields". A public field allows any other code to set them at any time with no restrictions. I can set your values to non-sensical values like so:

car car = new car();

car.make = "bob";

car.model = "cat";

In the history of the automotive industry, there's never been a make of "bob" or a model of "cat", but tell me ... as a programmer, how are you going to stop me -- the consumer of your class -- from setting those public fields to those crazy values?! I dare ya to stop me! You can't! Ha ha ... I just broke your code. I am teh hax0r.

If you defined Public Properties, and inside the Set for each property you validated my attempts at creating nonsensical values, you could have prevented me, the consumer of your class, from breaking your code. Yay for you! And in the Get, you could have validated that the user attempting to retrieve those values has the proper authorization (i.e., roles) to view that data. If not, your class would not allow it.

So, conceptually, that is the value of properties. They are the gate keepers to class members.

But ...

When you you auto-implemented properties you might argue that there's no practical difference since you don't create the Set and Get. True ... BUT ... SOMEDAY you might, and if you change your class's public interface from a Public Field to a Public Property, you may potentially be breaking code written against the old Public Field version of the class.

So ...

It's a generally accept best practice to prefer Public Properties and create Private fields for keeping track of internal information, only exposing that information through the gate keepers, the Getters and Setters. Auto-implemented properties in C# are a short cut towards creating those so that you can go back and add the Get and Set later if you want without repercussion.

Also, please note ... your naming conventions are important here ... generally, anything public should start with an upper case letter. Also, you should put a 'Public' in front of that 'class' otherwise the compiler will complain. Re-writing:

Ty you Sir. This series helped me a lot already although i didn't finished it still. Huge respect!

When I'm here already I will be free to go off-topic and ask a serious programming guru like you are about few concerns i have. First of all can Desktop Windows 8 application interfaces be made with html/css/js? Also in future how you see js versus c#? Do i need to focus on mastering js or c#? I know in base js is a lot simpler, but can be "extended" with libraries and be as near as powerful. So who will prevail for front-end development? Thought my heart is on the side of so called Web Standards Model.

@VladimirKrstic: No, you cannot create DESKTOP Win8 apps (today) with the web stack. You CAN create WINDOWS APP STORE Win8 apps with the web stack. As to the future, I have no earthly idea. I think BOTH are viable paths to go down and if your heart is leading you to Web Standards, to design, to web-based development, then you already have your answer. With node.js and other open source libraries that will convert your js into native mobile apps, I'm sure it's just a matter of time before you'll be creating DESKTOP apps with js as well -- heck, you might be able to today, just not with anything from Microsoft I'm aware of. Hope that helps!

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.