Tips for the Object Oriented Programming novice

The following is written for programmers who don't really understand object oriented programming yet. They probably understand the language semantics, but don't really understand how to use them correctly.

If you find yourself misusing object oriented semantics that probably means you don't have the skills to develop good software. This is a problem because bad software is much harder to develop and even harder to maintain.

I'll try to avoid reinventing the wheel. Most likely the mistakes you are making are so common that they have been immortalized as anti-patterns:

"Anti-patterns, ... [are] specific repeated practices that appear initially to be beneficial, but ultimately result in bad consequences that outweigh the hoped-for advantages."

In my experience, the following anti-patterns are especially common amongst Object Oriented beginners:

• Big ball of mud

• God object

• Cargo cult programming

  Cargo cult programming happens when you mimic some of the superficial externalities of OOP without a real understanding of the underlying concepts.

  "The term 'cargo cult', as an idiom, typically refers to aboriginal religions which grew up in the South Pacific after World War II. The practices of these groups centered on building elaborate mock-ups of airplanes and military landing strips in the hope of summoning the god-like airplanes that had brought marvelous cargo during the war."

It's very important to understand that Object Oriented Programming isn't magic. Using the syntax / language facilities isn't enough to make your code truly object oriented, and it certainly isn't enough to make your code any good.

One of the most important principles you need to understand and master is called Separation of concerns. Without it, you programming methodology will be deeply flawed.

Another common pitfall is Programming by permutation without constant code refactoring. This usually results in code lacking in adequate abstraction which gradually accumulates a huge amount of accidental complexity.

Eventually bad programming tends to solidify into a Lava flow: "Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences", is what you get when you put such code into production.

Dear novice, let me assure you that the smell of your code has nothing to do with your intelligence and everything to do with your lack of experience. All beginners make these mistakes, because they are attracted to the short term rewards while insufficiently aware of the long-term problems these anti-patterns introduce (famously called "the tar pit" in Brook's Mythical Man Month).

In fact, in the early days of software engineering, the entire field made these mistakes, resulting in the routine catastrophic failure of even the most well funded software development projects. This period was called the software crisis: "The causes of the software crisis were linked to the overall complexity of the software process and the relative immaturity of software engineering as a profession."

Anyhow, a lot of extremely smart people thought long and hard about these problems for many years and came up with various processes and methodologies that can help us tame the software crisis.

That means you don't have to reinvent the wheel here or discover everything on your own, but can stand on the shoulders of giants.

However you probably won't "get it" just by reading a few Wikipedia articles. You probably need some good old fashioned theory. In other words, you need to hit the books. I couldn't possibly hope to reproduce the quality and breadth you can find in the best literature on the subject. So I did the next best thing and compiled a list of a few good books:

• The Object-oriented thought process.
• Refactoring: improving the design of existing code.
• Design patterns: elements of reusable object oriented software.
• Code complete
• The mythical man month.

A book, even a really good one is still no replacement for quality mentoring. After you do your homework, try to get a more experienced programmer to review your program's high-level design before you actually implement it. One way of doing that is to plan out your object schema in advance using CRC cards.

Here's a related, excellent tutorial on teaching object-oriented thinking to procedural programmers using CRC cards:

http://c2.com/doc/oopsla89/paper.html

It starts out: "It is difficult to introduce both novice and experienced procedural programmers to the anthropomorphic perspective necessary for object-oriented design."

In other words: relax, at least you're in good company.