Geeks With Blogs
Lee Brandt's Blog You're only as smart as your last line of code

I realize that this is probably WAY beginner stuff for most people who read these blogs, but I am giving these classes to some people who come from a structured programming background and it may help others in the same boat. I like to think I know OOD pretty well, but if you see something that you think (or know) is wrong drop me a comment (no flames please).

In the Beginning...

There was structured programming; and the developers saw that it was good. The coded and rejoiced at the marvels they created. The programs read (and were executed) like books: top to bottom and left to right. They were able to make a computer do anything they wanted, so they were content. But not ALL were content. Some realized that when programs got be large, they were unwieldy. Some programmers spend weeks reworking the flow of a program to add very simple functionality. simple changes would cause "ripple effects" through large programs that caused many coders untold hardship. And it was these developers that went in search of a better way.

And they were bore unto the land of object orientation, and they wondered at its flexibility, extensibility and modularity. It represented the way we deal with things in the real world, and how those things interacted with us (and OTHER thing). But as they began to study the ways of object orientation they began to notice one thing: it was hard.

They were used to the structure of their old ways and these new paradigms were strange. Classes? Methods? PolyWHATism? They were confused.. and not like Confucius, like health nuts in a doughnut shop. They wondered whether to use an abstract class or an interface. They wondered about coupling and dependencies. Why was their and interface here and implementation over there? How would they ever be able to write functional software if their code was spread out in the little classes? How would they tell others about what they had created? They would define terms.



The class is the foundation of object-oriented design. A class is a blueprint for making an object. It is the plans used to create an object. When you create a new object, you basically ask the class to create you one from scratch.


So what IS an object, then? It is the concrete instance of a class. It is the thing that your code uses; the things you (and your code) interacts with.


The interface is the outward-facing piece that objects use to interact with each other. It is the "face" that objects see and use to "inter"act with each other. your face, hands, feet, etc. are your interface to the world. The telephone's interface is the number keypad, the receiver and the "hang-up lever" (can't figure out what that thing is called). If you pick up a phone, you automatically know how to use it, because you recognize the interface.


This is what happens when the interface is used. When you dial a phone, a call is made. You probably don't know exactly how the call is made; you just know it will be made.


This is a fancy word that just means "hidden". The details of how something is done is hidden from the person (or object) that asked for it to be done. This is one of the most important aspects of object orientation, as it allows for objects implementing the same interface to be used interchangeably. In the example above, the phone encapsulates the details of how the call is made.

You mean, I'm not in your class?

There are lots of things that go inside you classes, but here are the things you'll see most often.


The constructor does just what the name says, it constructs an object using your class and sets any preliminary values.

So a constructor for an Employee class, might look like:

   1:  public Employee(string firstName, string lastName){
   2:    this.firstName = firstName;
   3:    this.lastName = lastName;
   4:  }

This constructor will instantiate a new object from the Employee class and set the initial values of the firstName, and lastName instance variables to the values received.


Properties read and change the state values in the object. They are just what they say they are; they are properties of the object your creating. If it's a person object, some of your properties might be height, weight, gender, etc. Properties have accessors and mutators, which are more commonly called getters and setters respectively. Again, the purpose of these are pretty obvious: accessors or getters, get values from properties, while mutators or setters change (or mutate) the value.

So your Height property might look like:

   1:  public int Height{
   2:    get{ return _height;}
   3:    set{_height = value;}
   4:  }


Methods are anything that an object can do. A person object can walk and talk and make spaghetti. Methods have a method signature. This is a group of words that uniquely identify a method (like YOUR signature uniquely identifies you). The signature is made up of four basic parts:

  • The Access Modifier - This determines the visibility of the method (e.g., usually something like public, private or internal)
  • The Return Type - This is the type of the return value (e.g. string, int, object, Employee, etc.)
  • The Method Name - The name that the method will be called by (e.g. MyMethod, WalkTheDog).
  • The Parameter List - These are the values (none to as many as you want) that will be passed to the method when it is called.

So your WalkTheDog method might look like:

   1:  public void WalkTheDog(Dog dogToWalk){
   2:    // sweet elegant code used to actually walk the dog
   3:  }

This method has a public access modifier, returns nothing (void), has a name of WalkTheDog and takes a Dog object parameter.

Private Members

These may be variables, properties of methods, but they are private to the object. I usually use the term in reference to instance variables, or variables that are used within the instance. Properties are sometimes used to get and set these values.

So, an instance variable type private member might look like:

   1:  private string firstName = string.Empty;

The code above will create a private string variable called firstName and initialize the value to an empty string.



Putting It All Together

The code for an Employee class might look like this:

   1:  public class Employee{
   2:    private string firstName = string.Empty;
   3:    public string FirstName{
   4:      get { return firstName; }
   5:      set { firstName = value; }
   6:    }
   7:    private string lastName = string.Empty;
   8:    public string LastName{
   9:      get { return LastName; }
  10:      set { LastName = value; }
  11:    }
  12:    public string Greet(string name){
  13:      return string.Format("Hidee ho {0}!", name);
  14:    }
  15:  }

Obviously, these are very simplistic examples, meant to demonstrate the pieces of a class and how they are used to create an object. Everything that is visible for other objects to interact with the Employee object, make up its interface. Everything inside that actually does the work, is the implementation.

This has definitely been a long enough post. If you're still reading I hope you got something out of all this. In the next installment I'll discuss, inheritance, abstract classes, polymorphism, and the separation of the interface and the implementation.



Posted on Tuesday, April 22, 2008 4:29 PM Learning , Software | Back to top

Comments on this post: Object Oriented Design Part I

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Lee Brandt | Powered by: