After reading Chris LaCroix’s blog entry on Requirements gathering (see Five Things Analysts Should Always Do To Ensure Success), I was reminded of a previous assignment where two things I had learned long ago were reinforced.  The first was a mantra preached by a senior Business Systems Analyst:  “You can never have too much detail in your requirements”.  The other was “A picture is still worth a thousand words”.  They both fit together into one statement:  Requirements must be communicated effectively, in a way that is easy for everyone to understand.

Enumerations

Per Sun's Java documentation, a Java enum "is a type whose fields consist of a fixed set of constants ... you should use enum types any time you need to represent a fixed set of constants."

• Prior to Java 1.5, there were 2 basic ways to define new types: classes and interfaces
• In some cases neither one of the options was sufficient, especially for a finite set of a specific type of data
• Example of some finite sets include grades, planets, compass directions, countries, genders, and ethnicity types
• These types of construct were possible prior to 1.5 but required a lot of work and were prone to issues.
• Enums remove the need for public static final constants.

Defining an Enum

Defining an enum is as simple as creating any other class in Java.

  public enum Gender {
      MALE, FEMALE, UNKNOWN
  };

While many languages have enumerations built into the syntax, Sun didn't add the construct to Java until Java 5. After tooling around with enums a bit (blog entries forthcoming), I got to thinking... What makes an Enumeration? How constant is a constant? Maybe it's the philosophy major in me, but these are questions worth answering (or at least pondering aimlessly).

No matter how you slice it, enums in Java have the downside of requiring recompilation to add additional values, so my aim here is to answer the question: when should you choose to use an enumeration?

From all the time I’ve spent learning design, there are a handful of things I’d hope to remember or re-read if I were to ever get amnesia and have to start all over again.  For new comers and experts alike, I’d like to share a few ideas about design worth thinking about through musings and links to other material that has helped form my opinions (some more relevant than others).

Back in April, there was an interesting article quoting Ron Jeffries et al on InfoQ looking at code reuse from an agile perspective. The conversation steered toward explaining reuse as a concern that is very expensive, looking at it from a top-down, “enterprise”-wide lens.

But is code reuse a black and white issue? My contention is there are varying degrees of reuse that are often neglected on a microscale within an even moderately-sized project. If the code you produce isn’t going to be reused, is it even going to be looked at? These are similar problems with similar solutions.