# Wednesday, August 5, 2009

Back To Basics

Key Object Concepts

Objects are essentially a collection of structured data stored in memory. An object is based on a class that defines how to create an object.

In this section, I will describe the following concepts.

  • Classes
  • Class members
    • Properties and Fields
    • Methods
    • Events
  • Instances
  • Static Types
  • Interfaces
  • Message Passing

Because all these terms are interrelated, it is difficult to discuss one without mentioning the others. So be patient if I mention a term before I define it – I will get to the definition shortly.


A class is a definition for an object. It describes the attributes, such as properties, fields and methods (more on this later) of an object. It may also set default values and implementations for these attributes. Think of a class as a blueprint we can use to help us build an object. Generally, we work with classes only at design-time, defining the attributes appropriate for that class. In most cases, we do not work directly with classes while a program is running.

In C#, a class is defined with the following code

public class <CLASSNAME>{} 

So to create a class named MyClass, we use the declaration:

public class MyClass{} 

Public Members

A class (and an object) exposes a finite set of publicly-exposed members. Members are methods, properties and fields (defined below). This public interface is how you interact with an object. An object may be capable of far more than what it exposes by its public interface, but these other capabilities are not seen directly by the outside world. Keeping object interfaces simple is one way that an object can help simplify a complex system.

Properties and Fields

Properties and fields describe static data associated with a class. In C#, fields are implemented with the following syntax:


as in the sample code below:

public string Color = “White”; 

You can access this property with syntax like the following

obj.Color = “Black”; 
string thisColor = obj.Color; 

A property is similar to a field, but a property provides a “Getter” and “Setter” – methods that run when you attempt access the value of a property. This allows a developer to add code that will automatically run whenever a field’s value is retrieved or assigned. This code might perform validation or calculate a value on the fly. The C# syntax for fields looks like the following

private string _color; 
public string Color 
    return _color: 
    _color = value; 

 Beginning with C# 3.0, this syntax can be shortened to

public string Color{get; set; }

The syntax for working with a property is identical to that for working with a field.


A method is a discrete section of code that is associated with a class and therefore with an object. Some methods return a value; others just run code and return nothing. In C#, sample syntax for a method that returns nothing is shown below.

public void WriteSomething(string messageToWrite) 
Console.WriteLine (messageToWrite); 

To return a value, in place of “void” in the method declaration, we specify the data type returned. Below is an example. 

public Int32 AddNumber(Int32 num1, Int32 num2) 
Int32 sumOfNumbers = num1 + num2; 
return sumOfNumbers; 

We can call a method of an object with syntax like the following

obj1.WriteSomething(“Hello World”); 
Int32 sum = obj1.AddNumbers(2,2);


So far, we’ve been talking about objects without defining what an object is. An object is an instance of a class – it represents a specific set of data.

We said before that a class is like a blueprint. Think of an object as the house, machine or other device built from that blueprint. Methods, properties and fields defined in a class become methods, properties and fields in any object based on that class.

It is possible to produce more than one house from the same blueprint. Similarly, it is possible to create multiple objects from the same class.

To instantiate an object in C#, we use the following syntax


In the Methods sample above, assume the methods were defined in a class named MyMathClass. Before calling the object's methods, we would first instantiate the object like this:

MyMathClass obj1 = new MyMathClass();

Static Types

It is possible to instantiate a class without explicitly creating an instance of that class. You can do this if the class is defined as “static”, as in the following example.

It is possible to instantiate a class without explicitly creating an instance of that class. You can do this if the class is defined as “static”, as in the following example.

public static class Math
  public static Int32 MultiplyNumbers(Int32 num1, Int32 num2)
    return num1 * num2;

Call this method with the following syntax

Int32 product = Math.MultiplyNumbers(2, 4);

Notice that we did not need to explicitly instantiate an object of type Math.  For static classes, the .Net framework takes care of this for us.


A constructor is a special type of method that runs when an object is first created. This is a good place to put initialization code for your object. In C#, a constructor is written by creating a method with the same name as the class.

public class MyClass 
   public MyClass()
   // Initialization code goes here

You may create constructors that accept parameters, such as in the following C# code

public class MyClass 
   public MyClass(string x, string y)
      // Initialization code goes here


An event is a notification by an object that something has happened. This something might be user input, such as a mouse-click on a form or it can be something less tangible, such as a customer exceeding his credit limit. Other objects may or may not respond to these events. Generally the object raising an event does not know how it will be consumed.


An interface looks like a class in that it can have properties, fields and methods. The difference is that the properties and methods contain no implementation code. Interfaces are used only to define the public members of a class. A class implementing an interface inherits all the public members of that interface and it is up to the class to provide implementation.

Below is sample syntax for creating an interface

interace IPerson 
  string FirstName {get; set;} 
  string LastName {get; set;} 
  Order GetAllOrders(); 

Use code like the following to create a class that implements an interface

class Customer: IPerson 
  public string FirstName {get; set;} 
  public string LastName {get; set;} 
  public Order GetAllOrders() 
    Order ord = new Order(); 
    // Code omitted for brevity 
    return ord; 

Message Passing

Objects communicate by passing messages. These messages can be primitive data types, such as strings and integers; they can be XML; or they can be other objects.  Generally speaking objects expose public members to accept these messages. This helps to simplify the communication between objects.

In this section, we learned the basics of objects, their definitions, their members and how to work with them. In the next section, we’ll introduce Object Oriented Programming constructs and how these concepts are implemented using objects.

Thanks to Chris Woodruff, who contributed to this article.

Wednesday, August 5, 2009 5:36:25 AM (GMT Daylight Time, UTC+01:00)
# Tuesday, August 4, 2009

Back To Basics

What is OOP?

Most people think of their business systems in terms of the interactions of people, institutions and systems. When describing a system, they often speak in terms of these interactions between entities. For example, they may describe how a customer communicates order information to a salesperson that inputs this information into an Order Processing program. Describing entities and defining how those entities interact with one another maps very well to Object Oriented Programming (OOP). OOP is a programming paradigm that focuses on the objects in a software system and the messages passed between those objects.

Object Oriented Programming is not a new concept. The ideas behind it were first published in the 1960s and the SmallTalk language, developed in the 1970s, formalized many of the programming constructs used in this paradigm. However, OOP gained popularity in the 1990’s with the increased use of the C++ and the last ten years have seen an explosion in object-oriented languages C#, Visual Basic.Net and Java.

In earlier programming models, a program was viewed as a set of methods or subroutines. A main method would call one or more subroutines that might each in turn call other subroutines. Each subroutine would complete its task and return control to the method that called it. Using this approach, developers viewed their programs as a set of tasks. These tasks became central to their application design.

Managing Complex Systems

It was difficult to manage complexity in this task-oriented approach to programming.

For example, one couldn’t be certain that a subroutine would not substantially change variables, files and other parts of the environment. The only way to know for sure was to examine that subroutine in detail to learn how it worked. In fact, you would need to also examine any subroutines called by that subroutine, to verify that they didn’t cause any unexpected side effects.

Another complexity arises because there tends to be a tight coupling between the subroutines. Changes to a subroutine often require changes to any routine that called it, making maintenance difficult.

Often in such systems, you find code duplicated in multiple places. Making a fundamental change to how a rule is implemented requires changing code several times – another maintenance difficulty that adds to complexity.

The Development process itself adds to the complexity of writing software. On most projects, we need to consider how to divide development tasks among team members; merge this code together; manage code deployment; test code modules independently and together; deploy updates to our application; and fix errors as they are found. The entire process can be quite complex, particularly if all our modules are tightly bound together.

Finally, we cannot ignore the fact that many of the problems we are trying to solve are complex. This complexity is often our motivation to automate these problems in the first place. Anything we can do to mitigate that complexity – such as splitting a problem into manageable components – will assist us in building a solution.

OOP attempts to address these challenges by focusing on objects instead of tasks. The whole goal of OOP is to manage complexity. This is done by splitting a complex system into manageable, independent pieces and only exposing enough of each piece to allow other objects to work with it. Much of the complexity of the object can be hidden from the outside world, making the system as a whole easier to understand.

The following basic principles help to accomplish OOP’s goal of managing complexity.

  • Inheritance
  • Abstraction
  • Encapsulation
  • Polymorphism
  • Decoupling

The above concepts are interrelated in that some are used to accomplish others. In a later article, we will dive into more detail about each.

Before we can do that, it’s important to understand the basics of objects before you can grasp Object Oriented Programming.

Next: Intro to OOP, Part 2: Understanding Objects 

Thanks to Chris Woodruff, who contributed to this article.

Tuesday, August 4, 2009 2:23:52 PM (GMT Daylight Time, UTC+01:00)
# Monday, August 3, 2009

Episode 39

Episode 39: Jamie Wright on Getting Real

In this interview, Jamie Wright, president of BrilliantFantastic Consulting describes how he has applied the Getting Real software development process from 37 Signals to his own consulting practices.

Monday, August 3, 2009 10:58:51 AM (GMT Daylight Time, UTC+01:00)
# Thursday, July 30, 2009

NPlus1 is an organization designed to assist architects and lead developers and those aspiring to these roles.

The organization began last year with the launch of the NPlus1.org web site. This site features articles written by and for architects; links to screencasts and other resources; and announcements of upcoming events.

Recently, NPlus1 decided to expand its reach by organizing events of its own.  One of these events - the Architecture Summit - takes place Friday July 31 at the Microsoft office in Southfield, MI.  This event will feature three topics: "Introduction to Object Oriented Programming"; "Software Patterns"; and "How I Learned to Love Dependency Injection". The first topic is optional, as it is aimed at those who are new to Object Oriented Programming and, therefore might struggle with the concepts presented in the other two presentations.

I will be delivering the first two presentations (Intro to OOP and Software Patterns) while James Bender will deliver the Dependency Injection presentation.

It is not too late to register for this event and you can do so at https://www.clicktoattend.com/invitation.aspx?code=139245

Thursday, July 30, 2009 4:00:45 PM (GMT Daylight Time, UTC+01:00)
# Wednesday, July 29, 2009

Episode 38

I have been a fan of TechSmith products for years.
In this interview, TechSmith Chief Evangelist Betsy Weber describes the products offered by her company and the uses of those products.

13 mins, 13 secs
Wednesday, July 29, 2009 2:57:56 PM (GMT Daylight Time, UTC+01:00)
# Tuesday, July 28, 2009

Michael Eaton slumped in his chair and allowed his arms to fall to his side. Ten minutes earlier, he had been rushing up the stairs to find a designer to help out a team in need.  But now, relaxing in a quiet room with the door closed, the lack of rest began to catch up to him.  Two hours sleep Friday night on a classroom floor with a coat for a pillow seemed an appropriate way to cap off months of preparation for the 2009 Ann Arbor Give Camp.

Michael EatonIt was Saturday afternoon and the 3-day camp was about half over, but every indication pointed to a successful event. Sixty developers descended on Washtenaw Community College (WCC) and were huddled together in teams - furiously designing and writing code for charities. Many representatives of these charities were on hand, providing clarification of requirements or content or moral support.  In all, the teams were supporting eighteen charities. They wrote web sites and contact management systems and various pieces of software that the charities would be unlikely to afford on their own. They donated their weekend because they believed in this cause.

It was going well.

So, of course, I asked Mike about next year.

"Fifty charities", he insisted.  Fifty is nearly triple the number of charities helped this year, but Mike was determined to make it happen.

As he spoke about this, his energy returned. He talked of lessons learned and how to handle the scale for next year.  One key is to get started planning earlier - within the next few weeks. The goal is to get the charities and developers lined up early next year in order to be ready for the Give Camp in July. Bringing back the same planning team is important, he said. This year, Mike drew heavily on the knowledge of Jennifer Marsman, who organized last year's Give Camp.

He had already spoken with WCC and reserved their conference center - a building with facilities and rooms large enough to accommodate the hundreds of developers needed to support 50 charities.

Mike talked about the challenge of picking teams. Identifying appropriate skill sets was difficult, given that there were a lot of people unknown by the planning team.  Next year, he plans to gather more specific information from each developer in order to better evaluate their experience and place them on the correct team.

Mike stopped short of committing to take charge of next year's Give Camp, but it was clear from his enthusiasm that he wanted to be heavily involved. He did not hide his passion for what everyone was doing this weekend.

The energy of this event was infectious. A developer in Phoenix, AZ plans to put on a Give Camp in his area, so he flew to Michigan to experience one for himself and learn what worked.  WCC donated the facilities and accommodated the numerous requests they had over the weekend.

In the end, the 2009 Ann Arbor Give Camp was a great success. Sixty developers joined together to write code to help out eighteen charities. People worked hard and slept little and learned a lot and had fun and made the world a better place. Charities came away excited by their new software and inspired by the time committed by the development community in Michigan.

This can only increase excitement for next year.

Give Camp volunteers. Click for full-size photo.

More photos

Tuesday, July 28, 2009 2:25:54 PM (GMT Daylight Time, UTC+01:00)
# Monday, July 27, 2009


Martin Shoemaker is the UML Guy.
In this interview, Martin explains what UML is and how to use it to improve your development process.

25 mins, 45 secs

Monday, July 27, 2009 6:30:01 PM (GMT Daylight Time, UTC+01:00)
# Friday, July 24, 2009

Next week will be a busy one for me. I wrap up my current billable project on Monday and I need to prepare for Friday and Saturday when I will present three different talks in two cities on two days.

In addition, I am scheduled to speak at the October meeting of the Microsoft Developers of Southwest Michigan.  Sadly, a death in my family forced me to postpone last week's MEF talk at the West Michigan .Net User Group. Thank you to Jeff McWherter for filling in on short notice.

Date                  Event Location Topic Description  
Fri. July 31 NPlus1 Architecture Summit Microsoft office, Southfiled, MI An Introduction to Object Oriented Programming
Are you new to OOP? Do you want a refresher on the benefits of Interfaces and the differences between implements and extends? The morning session is a two hour introductory course of Object Oriented Programming. If you are new to OOP the lessons in this session will prepare you for the more advanced topics in the afternoon. link
Fri. July 31 NPlus1 Architecture Summit Microsoft office, Southfiled, MI Software Patterns
Patterns are an important tool to use as architects and developers. They provide a common vocabulary for us to design with, as well as a common approach to a common problem. Come learn about useful patterns, and how to use them in your everyday code. link
Sat Aug 1 Lansing Day of .Net Breslin Center, Michigan State University Using Microsoft Distributed Cache to speed your application
Retrieving data from a disc or a database can be a time-consuming operation. Data that is accessed frequently can be stored in an in-memory cache, which can speed up its retrieval considerably. Microsoft Distributed Cache (aka “Velocity”) provides a framework for storing and managing cached data. In this session, we will discuss how to use this framework in your application and demonstrate some code that implements this framework. link
Thu Oct 22 Microsoft Developers of Southwest Michigan TBD, Kalamazoo, MI Using Microsoft Distributed Cache to speed your application
(see above) link


Friday, July 24, 2009 6:08:56 PM (GMT Daylight Time, UTC+01:00)
# Wednesday, July 22, 2009

Episode 35

In this interview, Jesse Murray shares his opinions on how to implement SharePoint solutions "the right way".

17 mins, 52 secs

Wednesday, July 22, 2009 3:15:42 AM (GMT Daylight Time, UTC+01:00)
# Monday, July 20, 2009

Episode 37

I spoke with Michael Eaton halfway through the 2009 Ann Arbor Give Camp. We talked about what went into this year's event and his ambitious plans for next year.

19 mins, 21 secs

Monday, July 20, 2009 3:54:10 AM (GMT Daylight Time, UTC+01:00)