On the day I was born, the Egyptian military surged across the Suez Canal with 100,000 men and 1,350 tanks into the Sinai Peninsula. Simultaneously, the Syrian army sent 800 tanks into the Golan Heights. This simultaneous attack against a surprised Israel led to an amazing conflict over the course of the next several weeks that changed the state of affairs in the middle east.

At the time this was happening, Robert C. Martin (“Uncle Bob”) had already been in the software business for three years. Today, he is still a practicing programmer, working with code every day, and extending his knowledge of the art and skill of modern software development.

One of Uncle Bob’s largest contributions to our understanding of object oriented programming is a set of principles known as SOLID, which I’d like to share with you.

Today, I’m going to talk briefly about the Single Responsibility Principle, which is the ‘S’ in SOLID. This principle is very easy to remember. It simply states that any class that you write should only have one reason to change. We frequently change our classes after we write them, because the customer changes directions on us, or because our understanding of the technical requirements change.

Where we get into trouble is that our classes have too many things in them. Changing one thing causes a change to something else. Changing one thing requires us to re-test something else. Changing one thing requires us to change things somewhere else. We create extra work for ourselves. We create extra bugs for ourselves.

The Single Responsibility Priniciple is a discipline which can keep us from creating extra, unnecessary work for ourselves. By writing our code more simply, in smaller chunks, we can insure that WHEN change comes, it affects the smallest amount of code possible.

Uncle Bob’s book chapter on the Single Responsibility Principle provides a deeper view into the subject.