The Science of Software Development (Part 1 - Rules & Principles)

Introduction

In the programming world, we have a large range of skills. One programmer may take a month to create a program, and another might be able to do the same application in a day. The first program may be full of bugs, and un-maintainable, while the 2nd is stable and easy to extend. In this series of articles, I will explore different facets of these facts. My objective is to provide you with tools you can use to improve your abilities as a software developer.

This first article deals with helping you evaluate how much you know of the basics - object-oriented programming and design. I'll do this by breaking down object oriented programming into 3 tiers. Hopefully, you will be able to find your own level within those tiers, and use that to find the next steps to improving your knowledge. Right then, on with the show....

The Program

I thought this would be easier to follow if we discussed it in terms of an imaginary program. My example that comes to mind is a simple form with a data grid, and a popup data entry form that is used to enter new data into the grid. Note that any code samples in this article are pseudo-code - there is no downloadable code for this article.

Rules

When you first learn the game of chess, you learn the rules. Pawns can move like that, and knights like that, and the game is over when the king is trapped - checkmate!

Programming is the same, in that the first thing you have to understand are the rules. In programming, this is the syntax, and the programming environment (e.g., Visual Studio). Once you know the rules, you can write a program. In terms of our example, someone who has just learned the rules would probably write the code something like this:

sub MyDataGrid_RowClicked()
   Dim MyDataForm as new DataForm()
   MyDataForm.ShowModally
end sub

sub MyFormSaveButton_Clicked
   MyGridForm.DataGrid.RefreshData
   Unload Me
end sub

The application will work. When a user clicks on the data row, then the data form will display. Once the data has been updated, then the grid will refresh.

Principles

Once you have learned the basic rules of chess, you start learning the principles. A queen is more valuable than a pawn. Knights and Bishops are roughly equal in value. Try and control the center of the board.

In programming, we have principles too. They are fairly well known, and have been for a while. Coupling, cohesion, use of functions...there are many more. Once you know the principles, your programs become "better". This means that they are easier to write, understand, and extend. They may scale better, and interface easier.

Once a programmer has learned some programming principles, they may recognize that the sample code in the previous section was flawed. MyGridForm and MyDataForm refer to each other. In object oriented terms, this is known as coupling, and it is bad because they are now dependant on each other. When one changes, it can cause problems in the other. Multiply by a thousand, and you have spaghetti code.

Armed with knowledge that coupling is bad, we may re-write the previous code as follows:

sub MyDataGrid_RowClicked()
   Dim MyDataForm as new DataForm()
   MyDataForm.CustomShowMethod(myRowData)
   MyDataForm.ShowModally
   MyDataGrid.Refresh
end sub

sub MyFormSaveButton_Clicked
   Unload Me
end sub

This is superior to the previous version, because MyDataForm is no longer coupled to MyGridForm.

Patterns

If you want to succeed in chess competitions, you have to start studying. You study the games of the grandmasters, and you study the patterns of the opening moves. You study your own games, and you study the games of your peers and rivals.

In January 1995, almost 10 years ago, a group of four authors ganged together and published a book called Design Patterns. This book contains some of the knowledge of the programming grandmasters. They describe patterns as "simple and elegant solutions to specific problems in object oriented design". There are only 23 patterns in the book, but each summarizes years of hard-earned experience. In terms of concentrated knowledge per square inch of text, the book is very dense. (That's just my way of saying that it is not light reading material).

With new-found knowledge of patterns, we can revisit our application. Some of you may have noted that although MyDataForm is no longer coupled to MyGridForm, the reverse is not true. MyGridForm is still coupled to MyDataForm. With a little knowledge of patterns, we can remove that dependency.

abstract class FormCreator
   function GetForm(rowData) as Form
end class

concrete class MyFormCreator
   function GetForm() as Form
      MyDataForm = new DataForm()
      return MyDataForm
   end sub
end class

sub MyDataGrid_RowClicked()
   dim MyDataForm as Form = MyFormCreator.GetForm()
   MyDataForm.CustomShowMethod(myRowData)
   MyDataForm.ShowModally
   MyDataGrid.Refresh
end sub

sub MyFormSaveButton_Clicked
   Unload Me
end sub

The above is an implementation of the Factory Method pattern. I won't go into details, because that is not the point of the article. Suffice it to say, MyGridForm is no longer directly coupled to MyDataForm. If I wanted to, I could easily substitute another form MyOtherDataForm, without touching MyGridForm.

My Advice...

If you are learning the rules, then...

• Be aware that there are principles too.
• Understand that programming is not just about solving the problem at hand. There are consequences to the ways that you solve the problem. Try and be aware of that when you program.
• Understand that programming is not just about solving the problem at hand. Yes, I know I already said that. It's important, because that understanding is what will help you see the reasoning behind OO principles.

If you are learning to apply OO principles, then...

• Start by tackling one or two principles at a time; don't try to learn it all at once.
• Don't get caught up, or intimidated by the terms - encapsulation, inheritance, interface inheritance, coupling, cohesion, Liskov substitution principle, etc.
• Try to understand the reason for a principle. It can slow down development if you apply principles just for the sake of it, without understanding why. It can even lead to whole layers of your application that serve no real purpose. Once you understand the reasoning behind the principles, it becomes much easier to choose how and where to apply principles.
• The most important thing is that you try - the rest comes with experience. You will make mistakes, but your programs should still be superior to the ones you developed beforehand.

If you are learning patterns...

• Accept that you will never know them all. Some will be easier than others to pick up, and some you will never find a use for.
• Start by thinking of a particular challenge that you have, and then try and find a pattern that seems to help.
• Buy and read books on programming and design techniques. Try and expand your horizons.
• There are other patterns besides the original 23 - there are even some for business-domain specific stuff, such as accounting. Sometimes, it is worthwhile looking into those.
• Lastly, beware of overusing patterns - they can be overkill. Not every solution needs to be the most elegant and extensible one that you can devise.

Conclusion

Every developer has to be a designer as well. Even if you have someone who provides the broad brush-strokes of the application design, you still have to code the details. That said, if you never learn design patterns, you can still be a good programmer.

The same is not true of the principles. You absolutely need the principles to be able to design your own applications in such a way that they can survive the test of time. Experience has taught me that a medium to large program that is written without the use of principles will be re-written or scrapped. A small program that is written without applying OO principles will always stand on its own, and never integrate well with others.

For many of us, it's been a difficult (although exciting) few years picking up yet another language (C# or VB.NET or ASP.NET). We have to remember that there is more to it than just the language and the framework, and the latest technical how-to article.

There is such a huge wealth of knowledge available on the Internet, and in books (some of which are listed below). Enjoy.

References and Further Reading

Most of the references here relate to Principles and Patterns. For the rules, check your online help/SDK.

• Service-Oriented Architecture: Considerations for Agile Systems - Microsoft article that introduces some OO principles.
• GOF - Design Patterns.
• http://www.martinfowler.com/ - some good articles on OO.
• http://safari.oreilly.com/ - online technical book library.
• http://msdn.microsoft.com/architecture/patterns/ - Microsoft's implementation of some patterns.
• I'll take other suggestions from reader-comments... specifically, looking for recommendations for learning object oriented principles.

I believe the originator of the chess-programming analogy was Robert C Martin. I have not been able to find that reference though.

Article History

• 9 Jun 2004 - Altered introduction text.
• 14 June 2004 - Changed title, added some references, tweaked the intro and the conclusion based on feedback.