Divide by Nought

Archive for the ‘design’ Category

Object Design

leave a comment »

Too often developers and engineers miss the point of objects within object oriented programming (OOP). Many create ever-larger containers, objects sets with lots of implicit knowledge about each other, and seem to have disdain for passing variables.  Object oriented programs are still procedural even if they also have a nice way of packaging related data and operations.

Objects should behave like objects.  They are not massive amalgams of things that are sort-of related because that’s how they’re needed right now.  If objects aren’t treated as automatic components, the whole point of object orient programming is being missed.

When creating an object some simple considerations can increase the readability of the code as well as reducing the amount of knowledge needed to update it (which should avoid a whole lot of maintenance).  In almost every situation all of these things are easy to do.  In fact, if they’re not easy to do, that probably means there are extraneous complexities in the overall design.

Things to remember:

  1. Objects represent a single instance of some logical grouping of data.
  2. Objects can contain only 2 types of things: operations (methods) and properties (variables).
    • Properties represent something about the Object.
    • Operations do something based on the Object’s properties (internally provided) and/or passed Parameters (externally provided).
  3. Operations are always initiated externally; method calls, event callbacks, etc.

This implies that:

  1. Properties specific to the Object should be stored in the object.
  2. Parameters specific to an Operation should not be stored in the Object.
  3. Parameters specific to an Operation should be passed to subsequent Operations.
  4. Parameters created in/during an Operation should be treated as though they are Parameters; i.e. they are not Properties and should not be stored in the Object.

You may have noticed that all of these statements say “should”.  While this is nice and soft language in almost every case you should replace “should” with “must”.  If you’re not, your code is probably lower quality than it could and probably should be.

A good rule of thumb is that if you can’t explain it easily, it’s probably overly complicated.  You should be able to explain how and why something works to anyone.  Not any engineer, but anyone (using laymen’s terms of course).  These are some other good rules-of-thumb:

  1. Prefer generic types.
    Using generic types lowers the amount of dependencies and knowledge of a system need by the implementing engineer.
  2. Avoid using generic types if it overcomplicates the code.
    While generic types are great, they aren’t always appropriate.  It’s a balancing act.
  3. Prefer enumerations over generic types (int, bool, etc).
    When passing a political party “3” doesn’t mean anything.  And there are always more options than on and off, running and idle, even male and female.
  4. Prefer parameter only input into methods.
    Using parameters helps to keep methods constrained as automatic units that can easily be called by anyone, at any time and in any order.
  5. Avoid using globals or class-globals as input into methods.
    Using class-globals reduces the reusability and concurrent usability of a method.

Written by me

Thursday, October 22, 2009 at 11:53 pm

Posted in coding, design, Software