www.gregd.org

I see this a lot at work – someone puts code in a function. No, that part isn’t unusual :) The part that “bugs” *pun intended!) me is that the code really belongs in the function that they have overridden (in the case of OO languages), or in the functions that they call (in the case of procedural and/or OO languages).

It’s really a variation on the classic theme – don’t repeat yourself; write as little code as possible; keep it simple; don’t make me think.

One of the best ways of accomplishing this is to approach creating software like deer hunting. The best hunters know that there are certain natural funnels  – places where deer tend to run. These are the best places to put up a tree stand. You wait for the deer to come to you. You don’t go running around trying to corral the deer. If there’s a river, you find a place that is narrow and shallow to hunt because it is a natural crossing. Over time you’ll see every deer in the surrounding area.

This technique also applies to software development. Find one place in the code to solve your problem. You have an additional advantage too – you can create the bottlenecks – the places where everyone crosses the river so to speak.

At work we have an OO based framework that all of our web apps use. The people who designed it didn’t take full advantage of the natural bottlenecks. Rather than adding code to our Page_Load base method to check if the application should redirect the user to a “sorry, but we’re down while the batch runs” page, they put code in EVERY page of EVERY application. Worse, they put a class in every application that is around 500 lines long. I did a diff between two of these classes. Less than 10 lines of difference. What does this mean? It means that 490 lines of code could be moved into a base class and the 10 lines of code could simply be overridden to provide the appropriate configuration values.

In short, the total amount of code in each application to support this feature could have been less than 10 lines of code instead of 500! In our current situation, if a bug is found in the duplicated code it would take us more than 100 hours of effort to update every application and deploy them. If this code had been put in a base class, we’d just have to update it in one place.

Good OO (object oriented) design is not flat. It is 3d and sometimes even 4d in nature. The problem with most object designs is that they are based on the concept of an object. Objects are too constrained. Too often, an object is demoted to the thing that holds the data. People need to get over that idea. OO is simply a way to organize your code into tools that can be reused. The power of OO is found when you use it to create building blocks and tools. Objects are nice, but you really should be intentionally creating re-usable, modular, code! An object is a byproduct of that organizational style. You are programming related functionality in a multi-dimensional manner.

Consider interfaces that allow “horizontal” relationships. An interface is considered part of good OO design. With it, you can relate things that are not related “vertically” via traditional inheritance. If your “object” has legs, then implement the legs interface. Now everyone else can use them… e.g. Object.Legs.Walk, Object.Legs.Run. Perhaps your animal doesn’t know how to run? Then let it walk instead :) Now your arthropoda spider and your chordata ape can both walk even though they are from different phylums. It’s cross domain functionality.

Excellent programmers understand this distinction. I’ve seen too many good OO designs muddied by people who still live in a functional/procedural world. This is possible because OO simply extends the procedural model. To be an OO programmer does not imply understanding of OO. In fact, it is possible to program as in the past and completely miss the benefits that OO can give!

Warning signs of bad OO programming … hmmm, sounds just like bad procedural programming…

• Repeated blocks code
• A single line of code repeated 10s of times.
• GoTo … LOL :)

Some features of good software design:

• Is deliberate
• Is well organized
• Object oriented
• Makes excellent use of Layering (and even layering inside layers)
  • Careful thought is put into the placement of code in layers
  • Scopes variables and functions appropriately (e.g. public, private, protected, etc…)
• Minimizes copy and paste
  • if you copy and paste, then it should immediately become a function and shared if at all possible.
  • Your aim should be minimal duplication and maximal reuse. But please do use common sense.
• Is invisible
  • Guides novice programmers – they should follow the design almost by accident.
• Each function should work as a generic tool.
  • The user of a function should not need to know how it works.
  • Thought should be given to this when creating any function.
  • Should be as simple as possible in implementation and functionality, but no simpler.
• Refactor, refactor, refactor
• Adheres to the principles of
  • High Cohesion
  • Low Coupling

  Makes use of deliberate CODE bottlenecks.