Learning C# Part 4: Classes and Objects

Written By: Kevin Jordan

- 14 Oct 2006 -
















Description: This series aims to take a beginning programmer to an intermediate level in C#. Topics covered in Part 4 include: classes and objects, accessibility and scope, methods, constructors, static class members, namespaces, and XML commenting.

  1. Classes and Objects
  2. The Stack and the Heap
  3. Defining a Class and Creating an Object
  4. Defining Accessibility and Scope
  5. Passing Parameters to a Method
  6. Overloading Methods
  7. Using Constructors
  8. Static Class Members
  9. Namespaces and XML Commenting
  10. Aww Man... Not Homework

Introduction

The goal of these articles is to take a beginning programmer to an intermediate level in C#. By the end of this series you should be able to use object oriented to techniques to create database or xml driven websites and Windows-based applications.

I think practice problems can provide a significant benefit rather than just reading material because that's where you realize if you really understand a concept or not. So, at the end of each section there will be a small practice. If you run into any problems along the way, feel free to , or post it on the forum.

Classes and Objects

These days, there are two major families of programming languages, structured and object-oriented. Classes are what make C# an object oriented language and allow you to create user-defined types.

Some people like to think of a class as a blueprint. They describe the characteristics of an object, including its properties (data that an object can contain) and its methods (behavior of an object). An object is an instance of a class. You can make tons of objects from the same class, just like you can make tons of items from the same blueprint.

Since we used blueprints as our metaphor, let's use a house as an example. If we created a class called House, we could have numerous properties: the color of the walls, style of carpet, or whether or not ceiling fans are preinstalled. When you instantiate an object of the house class (build a house from the blueprint) you have to set those properties (decide what color the walls should be), but you don't have to make any changes to the class. The trick is, however, you don't want to define properties until you're going to use them. If we were creating a program for a real estate office then we might want all of these properties plus some.

Getting away from the blueprint.. We've now started to create a real estate program. We've got a class that defines what a house is, and properties that tell us what makes the house unique. Next, we must define the behavior that's relevant to our program (methods). Maybe we want to keep track of when people look at the house, or we could define the behavior of a house being sold.

I know the concept is a little abstract, and it takes a lot of practice to think in an object-oriented design fashion, especially if you've come from the structured side of things.

Next >>