Back To Basics

Today I was reading an article about software design and that got me thinking about the basics of programming. In my opinion, the root of any form of programming has everything to do with Separation of concerns (SoC). So what is separation of concerns? I would like to put it simply as SoC = Encapsulation + Abstraction + Decoupling.

Being a good programmer is not about how many languages you know, how well you know the Java or .NET API, and definitely not about how many years of experience you have. To be a good programmer, it all boils down to understanding good software design, and constantly renewing and updating this knowledge; after all, software design is language and technology agnostic.

Let’s divert for a second, to how I picked up my favourite buzzword, Separation of Concerns.

When I started my first job as a programmer, I was hired as a .NET developer in a Java dominant consultant firm. I spent my first month on the bench, waiting for my first gig, and in the meantime I spend my days reading about the .NET framework sitting amongst some Java developers.

After about a week, one of the senior programmers walked over to me one day, and asked me “Ed, what do you think is the most important thing about programming?” Intimidated by his sudden query, I shrugged and smiled back like an idiot. His reply was “Separation of Concerns”. I stared back at him, clueless, waiting for him to bring me enlightenment. He walked away and came back a few moments later, with a book in his hand.

He handed a book to me, and said “throw away that book you are reading, it teaches you nothing useful. Read this instead, and hopefully you will learn something about programming”. He handed over to me a book about Design Patterns, called Head First Design Patterns….and the rest is history.

Many people tend to have misconceptions about Design Patterns, heck some folks have even come out with anti-patterns. Regardless, I find patterns to merely guidelines for solving common recurring problems in software engineering. Throughout my work, I have found opportunities to apply patterns which have proved to be quite effective. Here’s a summary of some patterns I found useful:

Command Pattern A command object is used to encapsulate a call to a method at runtime.
Effective when used in event routing.
Factory Pattern Encapsulate the creation of objects. Useful for creating objects with polymorphism. Also investigate Dependency Injection which provides an even higher level of abstraction.
Facade Pattern Imagine a facade as an interface that allows you to hook into different operations in multiple subsystems.
Effective in Data Access Layer (DAL). A Facade can provide a unified interface that allows you to call operations from different DALs.
Decorator Pattern Decorator allows you to extend a class’s behaviour without having to modify it internally. This follows the Open Closed Principle, where class should be open for extension but closed for modifications.
Proxy Pattern Essentially a placeholder/interface to another class. This is really useful when you need to load something expensive, like large data. You would use a proxy object to exhibit a “wait” behaviour (like “loading” text) while loading the data asynchronously. The real object would be substituted when loading is complete.

Please feel free to form your own judgements about patterns. My advice is that there is no harm in learning about them. With the knowledge in your head, you will be able to recognize a pattern in code written by others, or during design discussions. This is where the benefit starts and your path to learning how to apply them opens.

A word of caution. Nobody should regard patterns as a means to an end, along with any other programming principles you will and have encountered. Patterns and principles are recipes at best. It takes a good programmer to know when best to apply them, and it takes an even better programmer to know when you can break them!

So let’s remember what programming is all about and get back to the basics! 😀

Below are some interesting links on this topic:

The Ferengi Programmer

Dependency Injection and Inversion of Control Pattern

Model View Presenter Pattern

SOLID Principles

Gang Of Four

Share this post : it! digg it! dotnetkicks it! live it! technorati!

2 Responses to “Back To Basics”

  1. Perfect match: Composite and Visitor Pattern « Code Blitz Says:

    […] match: Composite and Visitor Pattern July 29, 2009 — Ed Foh In one of my earliest post, I talked about the importantance of understanding principles of good programming, and the […]

  2. johnadulleck Says:

    Interesting coincidence! This is the 2nd blog I’ve read today about “Head First Design Patterns”.

    I am an advocate of using patterns. I believe that when properly applied, they can improve our code in many ways.

    I can well appreciate one of your closing comments though, patterns are not a means to an end. They are recipes, and as such it takes a practiced eye to discern when (or even if) a recipe should be used in a given situation.

    Thanks for writing.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: