[tlhIn`toq]

Learning C# Series

Classes and Objects

---

---

C#, VB.NET, JAVA, Objective-C and others are all Object Oriented Programming languages (OOP). Think about that. Object Oriented - meaning the language is Oriented around the use of Objects. Its not just a buzz word. Its the single most important foundation concept in the development of your programs, and your skills as a coder. Period. You can't think of it as an advanced concept that you're afraid of and will pick up later (after you establish lots of bad habits that will be hard to break).


Why is this important to learn about?

Its only the most basic of underlying principals upon which you will build all of your code for the rest of your career. Objects are what this entire language is Oriented around. If your code doesn't use them then its going to be a thousand times harder to do anything - if not nearly impossible. Making your code not follow established styles and technology is going to hinder you and make your code something that no co-worker or employer will want to deal with.

---

Terms you should be familiar with:

Spoiler

WinForms

Short for Windows Forms. The project type used for years for building Windows applications. Due to its age and demand for more advanced GUI, combined with rapid advances in web programming and other technologies like Silverlight, WinForms is falling out of favor with most developers. Microsoft is pushing everyone towards WPF (Windows Presentation Foundation).

WPF (Windows Presenation Foundation)

WPF is the new foundation technology for building Windows application GUI's. A few of its advantages over WinForms includes: Built on Direct3D to leverage the power of the video card processor, strong hierarchical design allowing any kind of control to house another controls so one can nest a Lable inside an Image for example. Strong ties to data binding making it more natural to de-couple GUI and data. Developer has a much wider control over look and feel: If you want rounded corner radius of 5 points you can do that. Because it makes use of XAML the developer can establish a style template much like an HTML CSS making it easy to define a style for the entire app: If you want all textboxes to have a blue border you define that in one place.

Field

A simple variable.

Method

Also known as function, subroutine or sub in other languages. Methods are blocks of code consisting of a signature and the code to be executed when the method is called.

Event

An event is how a classes yells out a notification to whomever is listening. You've probably placed a Button on a form and wired up a method to execute for the .Click event. Well .Clickis the event that the Button is trying to notify you about. For an in-dept look at events:
Quick and easy custom events

Class

A class is a construct that enables you to create your own custom types by grouping together variables of other types, methods and events. A class is like a blueprint. It defines the data and behavior of a type.

Object

The instance of a class. If a class is a blueprint, an object is the built manifestation of the blueprint - the actual house built according to the blueprint. For more about classes and objects:
Classes and objects tutorial

Example

// Using statements tell our assembly where to look for commands.
// They let us abreviate our code a little.
// For example bool is really  System.Bool but nobody want to type
// System.Bool each and every time you use it.  So we place a 
// using System statement at the hed of the file.  When the compiler
// sees 'bool' it will start looking through all of our usings to 
// find where this object is defined.
using System;
using System.Windows;

namespace DicTutorial
{

    public partial class MainWindow : Window
    {
        // Constructor method (Note lack of return type and name matches the name of the class)
        public MainWindow()
        {
            InitializeComponent();
        }

        //Event - Events generally are public so other classes can see them in order to subscribe to them.
        public event EventHandler Alert;
        
        //Field - As a rule fields are private so they are not seen by other classes
        // Since this field is defined within the braces {} making up the MainWindow block
        // the scope of this field (its visibility) is for the entire class.
        private int NumberOfWidgets = 4;


        // Method - bool is the return type. 
        // SomeMethodThatDoesSomething is the name. 
        // IncomingParameter is the parameter being sent into this method from the caller
        // Methods can be either public or private depending on whether or not outside classes need to use them.
        // The method signature is the unique combination of return type, name and parameters
        public bool SomeMethodThatDoesSomething(string IncomingParameter)
        {
            bool success = false;
            // Since this field is defined within the braces {} making up the method block
            // the scope of this field (its visibility) is only within this method.
            // Once this method finishes this field will be disposed of.


            // Do some fancy processing of the IncomingParameter.
            // Decide if it is valid for our needs.
            if (!String.IsNullOrWhiteSpace(IncomingParameter)) return true;

            return false;
        }
    }
}

Class

---

Note: All examples were created using Visual Studio 2012, targetting the .NET Framework 4.5, using a WPF project. We'll do our best to point out anything that might not work in older versions or ways of using the same techniques in WinForms.

Classes and Objects

---

---

For those just looking for a quick block of code as an example or reference (which we all do from time to time) here ya go

Spoiler

Think of objects in coding just as you would objects in the real world.

A Dodge Ram is an object.
It is made up of smaller objects: Engine, doors, tires
Each of those is made up of smaller objects: Bolts, pistons, etc.

Objects in coding can inherit from each other, usually from the general to the specific.

• Class vehicle
  
  • Class truck : vehicle
    
    • Class Ram : Truck
      
      • class 2500FWD : Ram

A class is the blueprint for instanciating (making an instance of) the object.

DodgeRam is a class describing how to make an instance, but itself is not an actual thing you can interact with.

myDodgeRam is an instance of the class DodgeRam

I can do things with the object instance myDodgeRam

myDodgeRam.SerialNumber = 123456789;
myDodgeRam.FillUpTank();
float fuelLevel = myDodgeRam.FuelTankPercentageFull;
if (myDodgeRam.IsReady) myDodgeRam.StartEngine();

Anything defined in the base class is available to a child.

class truck : vehicle
{

    public float FuelTankPercentageFull
    {
       get; set;
    }
}

class DodgeRam : truck
{
    // I don't have to define a FuelTankPercentageFull here because I inherit it from my parent
}

Methods defined as virtual in the base class can be overridden by the child class (at least in .NET languages like C#). This is often to account for more specific needs.

class truck : vehicle
{

    public virtual bool StartEngine()
    {
       // Do something to start the engine
       return true; // No checks or requirements
    }
}

class DodgeRam : truck
{
    public override bool StartEngine()
    {
        // Do a safety check first
        if (IsSeatBeltsEngaged && IsFootOnBrake)
        { 
            return true;
        }
        return false;
    }
}

You can even have a child class call the base classes methods which is often the smart way to go.

class truck : vehicle
{

    public virtual bool StartEngine()
    {
       // Notice there are no safety checks before trying to start up.
       try
       {
          // Do something to start the engine
          return true; // because we succeeded
       }
       catch(exception error)
       {
           return false; // because there was an error
       }
    }
}

class DodgeRam : truck
{
    public override bool StartEngine()
    {
        // Do a safety check first
        if (IsSeatBeltsEngaged && IsFootOnBrake)
        { 
            return base.StartEngine();
            // Now all the electrical work is in the base class
            // and not repeated in every child.
        }
    }
}

Objects and Classes aren't scary
I don't really care what your classmates said. I don't really care if you went "huh?" when you read the description of a class on MSDN or in your textbook. These are easy and I'm going to present this for you in an easy to pick up way. So stop, breathe and relax. You've got this.

The reason objects aren't scary is because they aren't new to you. You've been dealing with objects since you were a baby. Remember that first playtoy where you put the cubes through the square holes and ball through the round hole? Well those are objects. You're reading this tutorial on an object: A monitor. Which is connected to another object: A computer. Which is made up of lots of smaller objects: Cards, drives, case, fans.

Its no accident that objects in code seem to mimic objects in the real world. Its on purpose because we already understand them, and because we tend to code for things that are in the real world. So if you are coding for the real world it makes sense to follow the same patterns. So as you can see, objects aren't new or scary. You've used them your entire life. This article is going to show you how to build them in C#. Easy peezey.

If you didn't read the term definitions above, read them now. The key points are:

• class - The blueprint for an object, but not something your code will interact with.
  
• object - The instance built on the class blueprint. This is 'physical' thing you interact with like the actual house that was built according to the blueprints.

Good program design dictates that objects be as unaware of the details of each other as possible. They should be 'black boxes'. You put something in, you get something out. But what happens inside the box is none of your business so long as you get what you expected. The reason for this is so your program is robust - it doesn't break and crash just because you made a simple change inside one of those black boxes. If you think of your program as a castle built out of Lego blocks then each block is a class. It doesn't know much about the block its connected to. The only thing that one block needs of the other is a common interface so they can connect: The dimples on the top and matching holes in the bottom. It could be 6 dimples long or 4. It could be blue or red but that won't affect the operation. If you stack 3 Lego blocks on top of each other you have 3 layers of code where the first layer is totally unaware of the third layer. The second layer has the job of binding the two together. Same with your code. See, I told you this object stuff was child's play.

C# classes can contain (amongst other constructs):

• Fields
  
• Properties (The characterists of a thing)
  
• Methods (The actions of a thing)
  
• Events (The notifications announced by a thing)
  
• Other classes. (Just like an engine also contains piston)

This is how they are able to be mostly self-contained. They hold data, manipulate data and so on all within themselves then they just hollar out the results when they are done (raise an event).

Look at the world as objects. Everything you look at you should be able to code in your head. A garden hose
Properties: Length, color, material, diameter, IsConnected
Methods: None really as a hose doesn't really 'do' much.

A Bycycle
Properties: Color, brand, NumberOfGears
Methods: ChangeGear(int GearNumber), ApplyBrakes, ReleaseBrakes

When you see the world as objects then writing code for them is almost so easy its boring.


I think the best way to understand something is to see it in action and to actually build something from the ground up, so let's look a common homework assignment that every student sees and study it for how we can build the application in an O.O. (Object Oriented) way. Along the way we will look at the common non-O.O. way this gets approached so we can see how much harder life gets when you don't do it the right way.

The assignment:

Build an order taking program for a pizza place. The customer should be able to pick any kind of crust, a variable number of toppings, include sales tax and tip, calculate the total.

The wrong (non-O.O.) way.
Jump on the keyboard and start banging out stuff that was covered in the most recent chapter of a book. Build an array of crusts, an array of toppings, an array of prices. Try to keep everything syncronized: If I pick the 5^th element from the ToppingsArray[] I need to use the 5^th element from the PricesArray[]. Hopefully nobody ever adds a new topping and gets things out of order. A couple hours in start wondering how you make a management list of ordered items and their prices. Wonder how to take these disperate arrays and offer a good looking GUI for the user. Realize you've just painted yourself into a corner. But at least you jumped onto the keyboard right away so you could get to this point faster.

The OOP way
Stop. Think. Plan. Visualize an actual pizza place. What are the real-world objects you have to deal with and how can you see them in a logical and hierarchical way? Start drawing and planning on your whiteboard.

Let's see... There are ingredients for a pizza that include crusts and toppings. Ok, that sounds like objects, right? And a group of ingredients make up a pizza. Then again alot of pizza places also do pasta and a group of ingredients also make up a pasta dish. So its fair to say a group of ingredients make up a dish the customer orders and that pizza and pasta are types of dishes. Hey, look at us: We're designing hierarchical classes that inherit from each other just like in the example at the top of the page.

Spoiler

public class Dish
{
        
}

public class Pasta : Dish
{
        
}

public class Pizza : Dish
{
        
}

What did we say about a Dish? That it contained Ingredients. I guess we should make an Ingredients class so we can include a collection of them in our Dish. We know that the ingredients for a pizza each have a cost associated with them because those ingredients are the toppings and the crust. Maybe certain crusts cost more.

Spoiler

public class Dish
{
    public string Name { get; set; }
    public decimal BasePrice { get; set; }

    public List<Ingredient> Ingredients = new List<Ingredient>();
}

public class Ingredient
{
    public string Name { get; set; }
    public decimal Price { get; set; }
}

Notice how this stuff practically codes itself if you just think it through then make your code objects mimic their physical counterparts in real-world? Because Pasta and Pizza are classes derived from Dish they inherit the properties and methods of Dish. So we don't have to duplicate the Name and Price properties of Dish inside Pizza and Pasta: They inherit these.

Both Pizza and Pasta will need to supply a total cost. So we need a method for calculating the total. But lets think ahead. Its possible that one day there will be different rules for how to calculate the totals. Planning ahead for unforseen changes is one of the hardest skills in development and really only comes from experience learned by NOT planning first. Maybe the cost of the ingredients for a dish of pasta are less than the cost for those same ingredients on a pizza because there are less of them in a bowl of pasta than on a 24" pizza.

What have we figured out here? All Dishes and their children need a Total() method, but each child needs to have its own version of that method. This is where the matched pair of statements virtual and override come in. Any method marked as virtual in the parent (base) class can be overridden in the child (inherited or derived) class. Take note of line 9 in the base Dish class and line 27 in the inherited Pasta class. The base is marked virtual the inherited override.

Spoiler

public class Dish
{
    public string Name { get; set; }
    public decimal BasePrice { get; set; }

    public List<Ingredient> Ingredients = new List<Ingredient>();


    public virtual decimal Total()
    {
        decimal total = 0m;

        foreach (var ingredient in Ingredients)
        {
            total += ingredient.Price;
        }
        total += BasePrice;

        return total;
    }
}


public class Pasta : Dish
{
    private decimal IngredientDiscount = .75m; // A bowl of pasta only uses 75% of the amount as used on a pizza
    public override decimal Total()
    {
        decimal total = 0m;

        foreach (var ingredient in Ingredients)
        {
            total += (IngredientDiscount * ingredient.Price);
        }
        total += BasePrice;

        return total;
    }
}

public class Pizza : Dish
{
        
}

So what we have is a the base Dish class calculates the total using the full value of the ingredients. Since that is the rule we want to follow for a Pizza we don't have to override anything: We'll just call the existing Total() method. But for the Pasta class we override Total() to multiply each ingredient price by .75, giving us a 75% reduction in the cost of those ingredients.

What other objects do we have to deal with for this program? Oh yeah, the order itself. What are the objects in an order? You see this every time you order a pizza: Its the stuff on the ticket that the counter guy wrote up. Well, there are several Dishes, and tax and tip and customer name and server name etc. Let's stub out all of that.

Spoiler

public class Order
{
    public List<Dish> LineItems = new List<Dish>();

    private decimal TaxRate = .07m;

    public string CustomerName { get; set; }
    public string ClerkName { get; set; }
    public decimal Gratuity = 0m; // We don't know this until after the customer pays the bill

    public decimal SubTotal()
    {
            
    }

    public decimal GrandTotal()
    {
            
    }
}

At this point we practically repeat for the order what we did for the Dish. Make a loop that goes through all the LineItems (which is just a list of Dishes) and total them up. That would be the subtotal. Then we can take that, calculate the tax, and the take to the subtotal and we have the GrandTotal. For fun and just to show the difference between a property and a method Tax is a read-only property that does our calculation for us. We can use this just like any other variable. Since it has no set{} method, it is read-only. For more on properties check out the properties article that is part of this learning series.

Spoiler

public class Order
{
    public List<Dish> LineItems = new List<Dish>();

    private decimal TaxRate = .07m;

    public string CustomerName { get; set; }
    public string ClerkName { get; set; }
    public decimal Gratuity = 0m; // We don't know this until after the customer pays the bill

    public decimal SubTotal()
    {
        decimal subtotal = 0m;
        foreach (var dish in LineItems)
        {
            subtotal += dish.Total();
        }
        return subtotal;
    }

    public decimal Tax
    {
        get { return SubTotal()*TaxRate; }
    }

    public decimal GrandTotal()
    {
        return SubTotal() + Tax;
    }
}

In Conclusion

Master Spliter to the Turtles said:

Possess the right thinking.

As long as you think in terms of "How small and self contained can I make these little Lego blocks of code?" you'll do well.



See all the C# Learning Series tutorials here!

This post has been edited by tlhIn`toq: 10 November 2012 - 11:12 AM

[JimPickens]

This is great for a beginner. Thanks for writing such easy to understand tutorials.

[TommoUK]

Have a lot of respect for the time you have put into your tutorials, Great work

[acProgrammer]

This is good. I still will have to read it over a few times. Question: where do I learn more about the - get/set? I've seen this other places & have never used it. Of course, I am very new to programming & specifically c# but everything I get taught we use the toolbox and then build our code behind the object. Any feedback or suggestions would be great!


Thanks for your time ~ it is appreciated!

[modi123_1]

Typically the MSDN is a good place to start.

http://msdn.microsof...v=vs.80%29.aspx

[tlhIn`toq]

Quote

where do I learn more about the - get/set?

Another good place would be the properties tutorial.
Its the very next one in the C# Learning Series.

[scjohnson243]

I just wanted to say THANK YOU for this tutorial - yours are some of my favorites, Much easier to understand than what I have been seeing all over the web and on the books I have bought.
I am a beginner, and I don't know if anyone else gets that feeling that your SO Close to a real understanding of the subject, I feel like I'm so close to getting it, and this tutorial is really helping...

Thank you again!

[tlhIn`toq]

Glad to hear it helped

[DADDYCARDONA]

This tutorial is so awesomely made. I took programming up many times, done Java, C++, VB and Cobalt in school, learned Javascript, PHP and other things but still have not understood it like this tutorial makes me understand it. You guys should teach programming in colleges because some of these teachers don't really teach they just use the outline for their students. You should teach in Phoenix Online classes

[tlhIn`toq]

I appreciate the compliment. But I couldn't afford the pay cut to become a teacher.

Just remember - Colleges aren't in the business of getting students ready for the world. They are in the business of selling course credits. That's what they earn their revenue with. So the more courses you have to take the more money they make. Its good for them to stretch a year's worth of learning over 4 years.

Personally I'd like to a see a change in the business model. Professors should get paid 1% of each student's salary for the first 5 years after graduation. If they get the student ready for a good paying job then they make more money. Now that's incentive!

[dsimer]

Fantastic. Thanks!

[rollerdyke44]

ugh... I hate classes. I understand that you have tried to write this in the most noob-friendly way but I am still confused

In your example, you have created some classes (pizza, pasta) as child class which inherits from the parent class (Dish). Then all hell breaks lose lol

I cant comprehend whats going on. As the class Dish will include values from class Ingredients, then why didnt you set it as a child class to Dish?? I comprehend the need for virtual property for class Dish (that is, the method will be implemented by the class Pasta) but then, what is the need for writing any code inside the Dish class if the method will be overriden by the child class? How and what values would be send to the parent class via the "get and set" commands? These are the kind of questions I face with classes.

Maybe the example you've given was too complex for someone like me (it had tax, subtotal,total, orders, pasta, pizza etc). Can you write a simple program and explain to me HOW the class work/interact with one another? for example, just DISH (parent class) with price for PASTA and PIZZA (child class)?

I understand the basic concept of class, object and the working of inheritances and also their properties like virtual, override etc but I cant seem to grab hold of HOW exactly a class works in an application. Maybe I'm just too dumb for programming

P.S I read this tutorial 2-3 times, while also writing the code in VS2013. And ive also read your guide about properties

[tlhIn`toq]

Ingredients are a property of a dish, they are not a child of a dish.
You are a child of your parents. Your eye color is a property of you. But your eye color is not a child of your parents.

If you make Spaghetti, that's a dish you prepare.
Spaghetti includes:

• Noodles
  
• Tomatoes
  
• Basil
  
• Meat

But the ingredient Basil is not an actual Dish you list on a menu, so as a class it would not inherit from Dish.

A Dish would have properties such as number of servings, whether or not it is kosher, what is its cooking time... The ingredients don't have these characteristics.


Don't over think it: That's what's getting you.

Animal is a pretty general class of living being
Mammal:Animal - Mammal is slightly more specific type of Animal so we inherit from it
Canine:Mammal - A Canine is more specific and can trace its lineage up the Mammal chain.
Poodle:Canine - Now we have a fairly specific type of Canine. It will inherit all the methods and properties of all the classes up the chain

Animal
{
   string Name
   bool IsWarmBlooded
}

Mammal
{
   IsWarmBlooded = True;//Property inherited from Animal
   SoundEnum MySound;
}

Canine
{
   MySound = SoundEnum.Bark;//Inherited from Mammal
}

Poodle myLittleDog = new Poodle();
myLittleDog.Name = "Brandy";//The Name property was inherited from all the way up the chain from Animal
//At this point myLittleDog "Brandy" has already inherited being WarmBlooded from Mammal
//and that its sound is a Bark from Canine.
//I don't have to set it more times than required.
//But if I had to I could set it different for a specific instance
Poodle rescueDog = new Poodle();
rescueDog.MySound = null;//This dog has no vocal chords

Vehicle - Vague general class of a form of transportation

Truck : Vehicle
Train : Vehicle
Car   : Vehicle
Motorcycle : Vehicle
Semi  : Truck
Pickup: Truck
DodgeRam : Pickup

But an Engine wouldn't inherit from Vehicle would it? It would be a property of a vehicle... A characteristic of a vehicle... You could even say that an engine is one of the ingredients that make up a vehicle, along with tires, seats and a radio.

Does that help at all?

[rollerdyke44]

OH MY GOD! THAT MAKES SENSE lol

I guess I was always getting confused between child classes and the properties. Your animal example totally cleared it up (especially the comments you wrote). Thank you so muuuch!!

Quote

Don't over think it: That's what's getting you.

This was a really good advice. I just cleared my head and recalled the basic concepts of classes and read your example and BAM, i understood it after reading it only 1 time. Thanks for this...

Just to make sure I understand it correctly, Since poodle is (indirectly) a child class of animals, therefore all properties of Animals would be properties of poodle (unless specifically overridden), correct?
For example, If we set a value (suppose) "noOfLegs = 4" for animals, myLittleDog would also have 4 legs?
And if I set hair color of myLittleDog to white, it would only be for the item "myLittleDog" in the class Poodle only, right?

and once again, thank you for such a basic explanation. I swear, I couldnt understand classes before, but thanks to you, I understand. I cant thank you enough for this

Couldnt find an edit button, so sorry for double post.

I understand classes. Sorry but can you also explain about using the "get and set" commands in a similar uber-noob-friendly language?

[tlhIn`toq]

All of your 'just to confirm I got it' statements are right.

As for the get/set question... That's for properties, not classes. There is a link in my signature block to my properties tutorial.
Click that show/hide button where it says "more tutorials" - There is one on properties, one on events and so on.