# Monday, August 31, 2009

Back To Basics

This series of articles provides an introduction to relational databases in general and Microsoft SQL Server in particular.

Part 1: What is a Database?

Part 2: Relationships

Part 3: Selecting data from a table

Part 4: Aggregating data

Part 5: Joins

Part 6: Inserts, Updates and Deletes

Monday, August 31, 2009 1:04:07 PM (GMT Daylight Time, UTC+01:00)

Episode 46

In this interview, Craig Berntson describes continuous integration and how he uses it to increase productivity on his projects.

16 mins, 10 secs

Monday, August 31, 2009 12:45:00 PM (GMT Daylight Time, UTC+01:00)

Live Mesh offers a folder synchronization feature that allows you to designate a folder on your computer and replicate all changes to files in that folder to a matching folder on one or more other computers. These other computers could be
computers that you own (so that you can synchronize documents or project files between a home and a work PC);
your friend's computer (allowing multiple users to update the same documents and keep make sure everyone has the latest changes);
or a virtual computer in the cloud (so that your documents are backed up and accessible anywhere you have an Internet connection).

Here's how it works. To get started, go to http://mesh.com and sign in with your Windows Live ID. (If you don't yet have a Live ID, you can get one at https://signup.live.com). Read the license agreement and click "I Agree" to proceed.

The first page displayed is the Mesh Devices page which shows all the devices on which you wish to manage through Live Mesh. The Devices page allows you to add computers and other devices to your Mesh so that you can view and manage them.
You will see an icon representing each computer currently included in your mesh.  One of these icons is the "Live Desktop". This is a virtual device that exists "in the cloud", meaning it is available from anywhere as long as you have Internet access. If the bottom arrow is not pointing to the Live Desktop, click the Live Desktop icon once to rotate it to the bottom. Then click Connect to view this device. You will see a screen that looks similar to the desktop of a computer running Windows XP, Vista or 7. 

Live Mesh

Although this Live Desktop computer has no start menu, it does have by default a couple empty folders - "Home Documents" and "Work Documents". These folders exist to hold documents that you can synchronize from your own physical computer.

Live Desktop

To be able to synchronize documents on your physical computer, you must add your computer to your mesh.

To do so, you must be sitting at your computer. From the Devices page, click the "Add Device" icon. The icon will rotate to the bottom. From the dropdown at the bottom of the screen, select whether your computer is running a 32-bit or 64-bit version of Windows. Even though Windows 7 is not listed in this dropdown, I am running it on 64-bit Windows 7 and it seems to work fine. Click "Install" to begin installing the Mesh tools to your local computer and to add your computer to the mesh.

You will be prompted to give your computer a descriptive name and it will appear hereafter on the Devices page with that name. Step through the Installation wizard to install the Mesh client software on your computer.

Once the Mesh tools are installed on your computer, you can begin synchronizing folders.

You should see two shortcuts on your desktop for "Home Documents" and "Work Documents". Click these shortcuts to create these folders and have them synchronize to the folders of the same name on the Live Desktop. Any files that you drag into either of these folders will be automatically synchronized the folder of the same name on your Live Desktop. Any subsequent updates to files in those folders will show up in the file on your live desktop.

But you are not limited to only synchronizing these two folders. You can synchronize any folder on your computer.

To synchronize a folder, you need to add it to your mesh. Right-click the folder in Windows Explorer and select "Add folder to Live Mesh...".

Add Folder right-click menu

The "Add Folder" dialog displays.

Add Folder dialog

Here you can give the folder a more descriptive name if you like. Click "Show Synchronization Options" in the dialog. The dialog will expand to list every device in your mesh.

Add Folder Synchronization options

You can specify the devices that should synchronize with this folder and how synchronization occurs. By default, the folder is synchronized between your local computer and the Live Desktop and that synchronization occurs whenever a file is added, deleted or modified on either device. You can click the arrow next to a device to change the options. For example, you may wish to skip large files because those take a long time to synchronize and may use up your disk space quota.

It may also be useful to synchronize a folder with another physical computer. To do so, you must first add that other computer to you Mesh account (see above); then it will appear in the Synchronization Options dialog and you can specify exactly how you want to share the selected folder with the selected device.

When you are finished, the folder will turn blue to indicate it is synchronized using Live Mesh.

Live Mesh is a simple way to backup files, make data accessible from multiple locations, and collaborate with other users.

Monday, August 31, 2009 2:44:24 AM (GMT Daylight Time, UTC+01:00)
# Saturday, August 29, 2009

In Preview 6 of Microsoft's Managed Extensibility Framework (MEF), the framework changed the rules on matching multiple exports to a single import.

In previous versions of MEF, the attribute syntax was identical whether we were matching a single item or multiple items to an Import. Both scenarios used the [Import] attribute to tell MEF to find exports with a matching contract.

For example, if your application is using MEF to match a string variable, based on a string contract, you would use code similar to the following

string SomeString { get; set; }

This works if MEF finds exactly one matching export string, as in the following code.

string ThatExportedMefString
        return "This string was provided by an MEF contract.  It is from  an external assembly.";

If there is a chance MEF might find multiple Exports that satisfy the above contract, you would need (in previous versions) to modify the imported type, so that it implements IEnumerable, as in the following example

IEnumerable<string> SomeStringList { get; set; }

Beginning with MEF Preview 6, the rule for the attribute becomes more strict. If you are matching a number of items into an IEnumerable set of items on your import, you must replace the Import attribute with the ImportMany attribute. In the above example, the Import declaration becomes

IEnumerable<string> SomeStringList { get; set; }

The main advantage of this change is that ImportMany will not blow up if MEF finds no matching export for the contract. Import throws an exception if it cannot find a matching export.

Of course, your code will need to handle cases in which there are 0 matches, 1 match, or many matches when MEF seeks exports to match this contract. In the above example, that code might look like

foreach (string s in SomeStringList)

In my opinion, when you are writing an Import and you don't have control over the Export (for example, if you are allowing third-party vendors to supply the matching Exports), you should always use the ImportMany attribute. The only time you should use the Import attribute is if you are only looking for contract matches in assemblies that you have written and you can guarantee that there will always be exactly one match.

Saturday, August 29, 2009 8:41:51 PM (GMT Daylight Time, UTC+01:00)
# Friday, August 28, 2009

Episode 45

In this interview, Jessica Moss describes SQL Server Integration Services (SSIS): What it is; how it works; and how to get started learning and using it.

7 mins, 48 secs

Friday, August 28, 2009 9:12:57 AM (GMT Daylight Time, UTC+01:00)
# Wednesday, August 26, 2009

Episode 44

Chris Smith is a software design engineer on the Microsoft Visual F# team. In this interview, Chris describes the uses of F# and how it differs from object-oriented languages, such as C# and Visual Basic.

21 mins, 51 secs

Wednesday, August 26, 2009 4:54:12 AM (GMT Daylight Time, UTC+01:00)
# Monday, August 24, 2009

Episode 43

Kathleen Dollard is the only person I've met who is building a production application using Managed Extensibility Framework (MEF). In this interview, she describes how to use MEF and shares her vision of how it will affect the way we architect applications in the future.

17 mins, 37 secs

Monday, August 24, 2009 4:24:28 AM (GMT Daylight Time, UTC+01:00)
# Sunday, August 23, 2009

Those who attended DevLink last week should enjoy these photos I took. Even if you didn't attend, you may like to see shots of what you missed or people you know.  You can view over 200 photos here.

If you have a very short attention span or if you enjoy the heart-pounding music of Link Wray, the slideshow below is for you.  Turn up your speakers and move your furniture out onto the front lawn before clicking 'Play'.

2 mins, 28 secs

Sunday, August 23, 2009 11:26:29 PM (GMT Daylight Time, UTC+01:00)
# Saturday, August 22, 2009

I started using DasBlog for this blog almost two years ago.

For the past couple months, I've been struggling trying to add a permanent page to my web site. By permanent, I mean a page that is always relevant and is always available at the top of the site; as opposed to a blog post, which is dated and moves down as new blog posts are added.

My biggest problem is that I wanted the new page to have the same theme as all existing pages. It seemed simple enough but DasBlog did not provide an obvious way to do this.

Recently I discovered an old post by Omar Shahine at http://www.shahine.com/omar/FormatPageMacroInDasBlog.aspx

He described in detail exactly what I wanted to do.

Essentially, I create a file named xxx.format.html and add any static HTML I want on my new page. To apply the theme, I need to use FormatPage.aspx, which ships with DasBlog. FormatPage.aspx accepts a parameter path, which points to an HTML document and displays that document with the current theme applied.

After uploading my HTML page, I can apply a theme by linking to FormatPage.aspx?path=DaveSchedule.format.html.

Now I have a link in a tab at the top of every page pointing to my past and upcoming speaking schedule and that page has the same theme as the rest of the site.

Saturday, August 22, 2009 4:43:00 PM (GMT Daylight Time, UTC+01:00)
# Friday, August 21, 2009

Episode 42

The 2009 Lansing Day of .Net was held August 1 at the Jack Breslin Student Events Center in East Lansing, MI. This was the first event that Dennis Burton organized and he discussed it with us here.

8 mins, 28 secs

Friday, August 21, 2009 5:16:31 AM (GMT Daylight Time, UTC+01:00)

I will be presenting "An Introduction To Object Oriented Programming" at the Findlay Area .Net User Group August 25 (next Tuesday) in Findlay, OH. For more information visit the group's web site at http://fanug.org

This is actually my second time speaking at this group but it's the first time since 2002, so they have probably forgotten.

If you are in Northwest Ohio or central west Ohio, please come.

Friday, August 21, 2009 1:52:59 AM (GMT Daylight Time, UTC+01:00)
# Wednesday, August 19, 2009

Episode 41

Sara Ford is the Program Manager for Microsoft's CodePlex site. In this interview, she discusses the CodePlex site, open source software, and what she has in common with an Apollo astronaut.

19 mins, 50 secs
Wednesday, August 19, 2009 6:05:54 AM (GMT Daylight Time, UTC+01:00)
# Tuesday, August 18, 2009

John Kellar stood on stage in the final minutes of the DevLink closing ceremonies, gazing across the audience and smiling. In front of him, someone was introducing the members of the staff that had helped him organize and execute the conference. Behind me, the applause began. A few people in the back stood and clapped; then two more in front stood up; then I stood and applauded; soon, the entire auditorium was on its feet, cheering those who had put together an amazing conference.

John said he wanted to focus on the entire conference experience to make it worthwhile for the attendees. He succeeded at an amazing level.

Here are some highlights from my experience at DevLink 2009

'Configuration Management with Team Foundation Server' presented by Steve Andrews
The first day, all sessions were three hours long. Steve Andrews showed how to configure the automated build settings in TFS. He dug deep into the details of TFS and showed the various options available for continuous integration and how to customize the process.

'Good ways to use Live Mesh' Open Space
I called this session because I wanted to use Live Mesh as my backup strategy, easing my angst about rebuilding a laptop or PC. Jeff Blankenberg showed me the details of this very cool technology, answering all my questions and showing how he used Mesh to backup and share files.  Others looked over our shoulder as he did so, making this a successful Open Space for several people.

'MEF' Open Space
I have been delivering a talk on Managed Extensibility Framework (MEF) for almost year. But in this session, I got to ask questions of Kathleen Dollard, who has been working with this framework on a production application and has some very definite ideas about the future of MEF. It’s startling to me how much I learned during this hour.

'Enhance your .NET Application with SSRS' presented by Jessica Moss
Jessica had some hardware issues in this session, but recovered well enough to put on a solid presentation. I was glad to see because I have a customer looking for a class on SSRS and she looks like a good candidate for that.

'Dot Net Rocks' panel discussion
Prior to the closing ceremonies, Carl Franklin and Richard Campbell recorded an episode of their popular Dot Net Rocks podcast. A panel consisting of Josh Holmes, Jim Holmes, Kathleen Dollard and Billy Hollis discussed whether software development was becoming too complex. It wasn't one of Franklin and Campbell's best shows, but it was fun to watch them perform live.

Conferences are a chance to meet up with old friends, meet new friends and exchange ideas. DevLink was particularly good for this because so many people attended from outside my geographic region. The usual suspects from Michigan and Ohio were there, but I spoke with people from Atlanta, Virginia, Colorado, Canada and Great Britain.  Hallway conversations were as good as any I’ve had at a conference.  We were even able to meet in a more relaxed atmosphere at several organized evening events. The 3-day format made it possible to establish relationships with people through multiple conversations. John Kellar reminded me that this is not an accident and it's the reason the word "Link" appears in the conference name.

Technology and Friends
I recorded thirteen interviews for my show at this conference. I've already released one episode and cannot wait to produce and share the rest.

This was the best-run community conference I have attended to date. From the time I woke up to the time I went to bed, there was not a minute that I lacked something to do and learn. Often I had to choose between two or three options. I am already looking forward to next year.

DevLink web site

Tuesday, August 18, 2009 1:22:12 PM (GMT Daylight Time, UTC+01:00)
# Monday, August 17, 2009

Episode 40

On the third and final day of DevLink 2009, John Kellar sat down and talked about the planning and work that went into the conference; what the conference accomplished; and what it meant to the developer community.

13 mins, 35 secs

Monday, August 17, 2009 1:14:34 PM (GMT Daylight Time, UTC+01:00)
# Sunday, August 9, 2009

A year ago, I was surprised to find myself on a bus rolling toward Tennessee.  Although I had made it a habit of attending as many community events in the area as I could, Tennessee seemed too far to travel for a conference. So I originally balked at the idea of going all the way to Murfreesboro, TN for the DevLink conference.

Matt B But I found myself between jobs last August and I decided I needed to use this free time to network with others in the IT industry.  So, at the eleventh hour, I found an unused ticket; reserved a hotel room; and signed up for the community bus ride from Michigan to Tennessee.

For so many reasons, going to DevLink turned out to be the right decision.  I saw some very good sessions (Joe Wirtley's WPF presentation remains one of the best I've seen on the topic) and I got my first real taste of open spaces done well. But, more importantly, I met so many passionate people from the developer community. Looking back, it's startling to me how close I've become with some of them in just a few months.

This was one of the events that triggered for me an intense involvement in the developer community.  Since returning from DevLink, I've spoken at numerous user groups and conferences; I've become an officer for a local .Net user group; I've blogged with a vengeance; and I've become one of those loud opinionated guys you see on Twitter and at local events.

I won't say that DevLink is solely responsible for my community involvement over the past year. But I definitely found inspiration in the passion folks I saw there.

Carl F and Matt C This year, I'm planning a return trip to DevLink. The speaker lineup and the agenda look amazing; the event has expanded to three days and moved from Murfreesboro to Nashville; and the Open Spaces area promises to provide more stimulating discussion.

I spent most of my time at the 2008 DevLink in the Open Spaces area, but this time, I plan to attend more sessions. I'll also bring my still camera to capture the faces of the attendees and I'll bring my video camera to capture fresh ideas from passionate developers for my Technology and Friends show.

I hope to reconnect with many in the developer community and meet new people there. If you see me at DevLink - even if we haven't met before - please approach me and say "Hello". I'm looking forward to talking with you.

Sunday, August 9, 2009 9:56:57 PM (GMT Daylight Time, UTC+01:00)
# Saturday, August 8, 2009

Cliff Atkinson's Beyond Bullet Points proposes a radically new approach to creating presentations based on Microsoft Power Point.

Atkinson provides a template (available for download); an outline that splits a presentation into lengths of 5, 15 and 45 minutes; and an abundance of advice on improving your presentations.

After reading the book, I discarded the template and the outline but I embraced many of his ideas.

Here is some of the book's best advice:

Allow your presentation to tell a story.
The first presentation I did after reading this book included a story about consultants Juan and Amal, who had nearly identical skills and accomplishments but received very different performance reviews. Most of my presentations are instructions on how to use software, which doesn't lend itself well to a story format. If possible, however, I try to weave a story into the presentation.

Minimize the text in your slides.
Atkinson recommends eliminating all bullet points from every slide. The only text on each slide should be a headline. I haven't gone that far, but I have drastically reduced the amount of text on each slide. When I open an existing deck, I move much of the slide text into the Notes section. This simplifies the presentation, but keeps the text with the slides when I distribute them to users. During presentation, I make the former bullet points part of my verbal presentation, rather than something the audience reads off the screen. This keeps the audience's focus on me, rather than on the screen.

Use simple graphics
A simple graphic communicates an idea visually. I have been replacing the bullet points in my slides with a headline and a single photograph that relates to the slide topic. The slides become more interesting but less distracting.

Rehearse your talk
I already knew this but the book's reinforcement helped remind me how important it is to be familiar with one's material. Nothing achieves this goal like a couple dry runs through your presentation. Ideally this should be in front of other people (to provide feedback) and in a room similar to the one in which you will be presenting; however, filming your presentation and reviewing it yourself is also very helpful.

I have not bought entirely into the Beyond Bullet Points approach. But I have internalized many of the ideas in this book and my presentations have improved as a result.

Link: Beyond Bullet Points Online

Saturday, August 8, 2009 11:21:54 AM (GMT Daylight Time, UTC+01:00)
# Friday, August 7, 2009

Lynnne Truss is a stickler - a stickler for proper punctuation. 

I don't know if she wanders the streets with a marker to add missing apostrophes - such as on posters for the movie Two Weeks Notice; or with white stickers to conceal extraneous punctuation - such as in a store signs that read "Boat Motor's", but I know that she is tempted to do so. I know that it pains her to see such misuse of common punctuation in public places. She agonizes each time she sees "its" and "it's" misused.

She put together "Eats, Shoots & Leaves" - a small volume designed to clarify the proper usage of punctuation in the English language and to pursuade us that it is important. 

Like Ms. Truss, I agree on the importance of punctuation, particularly in public or professional communication; but I don't always know the correct rules, so her advice is useful.

The book devotes a full chapter to the use and abuse of the apostrophe; another to the comma; a third to the dash; and so on. For each punctuation mark in question, Ms. Truss lists the proper usages of that punctuation and some common, and annoying, violations of those rules.  For example, her book lists 17 distinct uses for the comma.

It’s a difficult task because punctuation rules are sometimes vague and open to interpretation; and because the rules are often broken by respected writers; and because the rules change in a living language like English. 

But Truss does her best to clarify the vagaries and to evangelize the static, unambiguous rules. It's important because the meaning of a sentence can change dramatically, depending on the punctuation: "Extra-marital sex" does not mean the same as "Extra marital sex";

The poor punctuation of "Eats, Shoots & leaves" (the title; not the book) misrepresents the characteristics of a panda. An extraneous comma suggests that a panda employs firearms after its meal and before its exit. Correctly punctuated ("Eats shoots and leaves"), the phrase describes a panda's favorite meal.

Most of Ms. Truss's advice does not sound like a textbook. Regarding comma usage, for example, she dictates the rule: "Don't use commas like a stupid person". What she means is that one should step back and read a sentence to verify that the punctuation conveys the correct meaning. 
For example, the sentence
"Leonora walked on her head, a little higher than usual."
is grammatically correct, but probably not what the author intended.

Despite her passion for the topic, her style is light and engaging. I laughed out loud several times while reading this short volume. She parenthetically refers to Gertrude Stein as a "strange woman" (presumably because she disagrees with nearly every opinion Ms. Stein holds on punctuation); and she once described a long, over-punctuated sentence as exhaustedly slipping into a comma.

I really enjoyed this book and will keep it on my bookshelf beside Strunk and White's excellent The Elements of Style because it is concise, accessible and extremely useful.

Friday, August 7, 2009 12:37:50 PM (GMT Daylight Time, UTC+01:00)

Back To Basics

This series of articles provides an introduction to the concepts used in Object Oriented Prorgramming and OOP code samples in C#.

Part 1: What is OOP?

Part 2: Understanding Objects

Part 3: Object Oriented concepts


Friday, August 7, 2009 3:15:45 AM (GMT Daylight Time, UTC+01:00)
# Thursday, August 6, 2009

Back To Basics

In this section, we will discuss the key concepts important to Object Oriented Programming (OOP). An object-oriented system has the following characteristics

  • Inheritance
  • Polymorphism
  • Abstraction
  • Encapsulation
  • Decoupling

Some systems (and some languages) don’t fully support all the above constructs and still refer to themselves as “object-oriented”. This is a matter of some debate, but it is my opinion that a language or system must implement each of the above concepts in some way in order to be considered object oriented.


Inheritance is the ability to create a class based on an existing class. In this model, the existing class is known as the “parent class”, or “base class” and the new class is known as the “child class” or “derived class”. By default, a child class will inherit all properties and methods of its parent class.

In C#, we inherit a class from a parent class by appending a colon and the name of the parent class to the child class definition, as in the following example:

public void ChildClass : ParentClass {} 

Marking a method as virtual in a parent class allows it to be overridden in a child class. This means that the method can be replaced in the child class with new code.

public virtual Int32 DoMath (Int32 num1, Int32 num2) 
  return num1 + num2; 

We can then use the “override” keyword in the child class’s method to replace the code in the parent’s class method, as shown below

public override Int32 DoMath (Int32 num1, Int32 num2) 
  return num1 - num2; 

It is possible to have multiple child classes that inherit from the same parent class. In some languages (but not in C#), it is also possible for a child class to inherit from multiple parent classes.

As a general rule, if I find myself writing a lot of conditional logic in a class’s methods – depending on how the object is created or the environment, the class runs one of several blocks of code – I will consider refactoring that class into a number of subclasses. Each class will inherit from a common parent class but the conditional logic is eliminated because each subclass contains only the code relevant to how it is created.

Interface Inheritance

Inheriting from an interface is similar to inheriting from a class, except the parent class does not contain any implementation, so each subclass contains all method code it needs to run. This is useful if a set of subclasses need to share the same public members but do not have any code in common. Interfaces also have the advantage that a single class can inherit from more than one interface.


Earlier, we said that objects communicate by passing messages via their public interface.

Polymorphism is the ability for different objects to respond to the same messages in a different, but appropriate, way. In OOP, this is done using inheritance. Because a child class inherits properties, fields and methods from a parent class, we can have several different child classes sharing the same public members. Each of these classes would therefore accept the same message types. However, each base class may override some of the behavior of the base class and may do so in a way appropriate to itself.

For example, we may create a Vehicle class that has a method Drive() that accepts no parameters.

We can derive two child classes - Car and Airplane - from Vehicle and they will each inherit the Drive method. But driving a car is not like driving an airplane, so each of these methods would be overridden and the overridden child methods would be very different from one another. Calling the Car’s Drive method would cause the axels to turn and rotate the four wheels beneath the car. Calling the Airplane’s Drive method would explode jet fuel and propel the airplane through the sky at a high velocity.

This is an example of two objects (Car and Airplane) that accept the same message (Drive) and respond differently but appropriately.

The C# code for this set of classes would look similar to the following

public class Vehicle 
  public virtual void Drive() 

public class Automobile: Vehicle 
  public override void Drive() 
    Console.WriteLine(“Turn axel and wheels and tires…”); 

public class Airplane: Vehicle 
  public override void Drive() 
    Console.WriteLine(“Explode jet fuel and propel through the air…”); 

The picture below shows the hierarchy of classes that inherit from a single parent class.


Abstraction is the process of simplifying an object or system by focusing only on those parts of the system relevant to the current problem. In OOP, abstraction is typically implemented using encapsulation.


Encapsulation hides implementation details of an object from that outside world. Again, this goes back to our goal of decreasing complexity. We don’t need to understand all the workings of an object in order to use it. Returning to our Automobile example, in order to start a car, I need only know to put the key into the ignition and turn it for a short time. A lot happens inside the car (gasoline is injected, battery is engaged, sparks fly, gas explodes) but I don’t need to the details of any of that in order to start the car. In fact, it’s easier for me to focus on starting the car if I ignore the other things going on within the automobile.


Finally, decoupling is a key point of object oriented programming that simplifies a system. In a decoupled system, the dependencies between objects are minimized. Encapsulation helps with this because external objects cannot change the internal attributes of an object if they cannot access it.

However, the responsibility for decoupling ultimately rests with the developer. Use messages to communicate between objects and maintain as little state as possible. Expose only those attributes needed by others and avoid coding side effects in your object’s methods.

In my experience, decoupling is the OOP concept that is ignored the most by people trying to build object oriented systems.


As we stated in part 1 of this series, the goal of Object Oriented Programming is to manage complexity. We do this by modeling our application as many people see their real world systems – as a set of loosely coupled objects that interact with one another. This helps us to split a complex problem into a number of more manageable objects. It also allows us to simplify the management of those objects by encapsulating complexity, maximizing flexibility through inheritance, and keeping the objects independent of one another.

Thanks to Chris Woodruff, who contributed to this article.

Thursday, August 6, 2009 12:53:29 PM (GMT Daylight Time, UTC+01:00)
# 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)