You are currently browsing the archives for the Code Review category

Cairngorm Abstractions: Commands and Responders

It is quite common to find a significant amount of code redundancy in Flex applications built on Cairngorm. This is by no means a fault of the framework itself, actually quite the contrary as Cairngorm is designed with simplicity in mind; opting to appropriately take a less-is-more approach in favor of providing a more prescriptive framework which only defines the implementation classes necessary to facilitate the “plumbing” behind the framework. Everything else is really just an interface.

With this amount of flexibility comes additional responsibility in that developers must decide what the most appropriate design is based on their applications specific context. Moreover, as with any design there is never a truly one size fits all approach which can be applied to any problem domain; there are really only common patterns and conventions which can be applied across domains and applications. This IMHO is what had allowed the framework to be a success and it is important to understand that this simplicity also requires developers to give their designs the same attention one would to any Object Oriented design.

However over the years I have found a significant amount of redundancy found in Flex applications built on Cairngorm. This appears to be (more often than not) the result of developers implementing Cairngorm examples verbatim in real world applications, and in doing so failing to define proper abstractions for commonly associated concerns and related responsibilities. The most common example of this is the typical implementation of Commands, Responders BusinessDelegates and PresentationModel implementations.

For some of you this may all seem quite obvious, and for others hopefully this series will provide some insight as to how one can reduce code redundancy across your Cairngorm applications by implementing abstractions for common implementations.

This topic will be a multi-part series in which I will provide some suggestions surrounding the common patterns of abstractions which can be implemented in an application built on Cairngorm, with this first installment based on common abstractions of Cairngorm Commands and Responders. Other areas in future posts will cover Business Delegate and Presentation Model abstractions. So let’s get started…

Command Abstractions
First let’s begin by looking at what is arguably the simplest abstraction one could define in a Cairngorm application to simplify code and eliminate areas of redundancy – Command abstractions. This example assumes the concern of mx.rpc.IResponder implementations is abstracted to a separate object. For more on this subject see my post regarding IResponder and Cairngorm.

A traditional Cairngorm Command is typically implemented as something to the extent of the following:

import com.adobe.cairngorm.commands.ICommand;
import com.adobe.cairngorm.control.CairngormEvent;

public class Command implements ICommand
{
  public function execute(event:CairngormEvent):void
  {
    var evt:SomeEvent = event as SomeEvent;
           
    // ModelLocator look-up and common references
    ModelLocator.getInstance()…
}
}

The problem with the above Command implementation is that it results in numerous look-ups on the ModelLocator Singleton instance in every execute implementation which needs to reference the ModelLocator.

A simpler design would be to define an abstraction for all commands which contains this reference. as in the following:

import com.adobe.cairngorm.commands.ICommand;
import com.adobe.cairngorm.control.CairngormEvent;
   
/**
 *
 * Defines an abstraction of common references from
 * which concrete ICommand implementations can
 * inherit
 *
 */
internal class AbstractCommand implements ICommand
{
  // define common reference to ModelLocator
  // implementation
  protected static var modelLocator:ModelLocator
                       = ModelLocator.getInstance();

  // Force concrete command implementations to
  // override execute
  public function execute(event:CairngormEvent) : void
  {
    throw new Error( "Abstract operation…" );
  }
}

As in any OO system there are many benefits to defining abstractions and a good design certainly reflects this. For example, just by defining a very basic abstraction for all Commands we have now eliminated the number of look-ups on the ModelLocator for every Command in the application as well as redundant imports. By defining an abstraction for common references your code will become easier to read and maintain as the number of lines of code will certainly become reduced.

Commands are by far the easiest to create an abstraction for as most commands will typically reference the ModelLocator, and if so they could do so simply by extending an AbstractCommand, if not they would implement ICommand as they traditionally would.

So the first example could now be refactored to the following:

import com.adobe.cairngorm.control.CairngormEvent;

public final class Command extends AbstractCommand
{
  override public function execute(event:CairngormEvent):void
  {
    var evt:SomeEvent = event as SomeEvent;
    // modelLocator…
  }
}

You could take these abstractions a step further and define additional abstractions for related behavior and contexts, all of which would also extend the AbstractCommand if a reference to the applications ModelLocator is needed.

Responder Abstractions
Now let’s take a look at an abstraction which is much more interesting – Responder abstractions. In this example we will focus on the most common Responder implementation; mx.rpc.IResponder, however the same could easily apply for an LCDS Responder implementation of a DataService.

A separate RPC responder could be defined as an abstraction for HTTPServices, WebServices and RemoteObjects as each request against any of these services results in a response of either result or fault, hence the IResponder interface’s contract.

For example, consider a typical Responder implementation which could be defined as follows:

import mx.rpc.IResponder;
import mx.rpc.events.FaultEvent;
import mx.rpc.events.ResultEvent;
   
public class SomeResponder implements IResponder
{      
  public function result(data:Object) : void
  {
    // redundant cast operation
    var result:ResultEvent = data as ResultEvent;
           
    // Redundant ModelLocator lookup and references…
    // ModelLocator.getInstance()…
  }

  public function fault(info:Object) : void
  {
    // Redundant cast operation
    // Doesn’t provide a centralized place for
    // global service exception handling
    var fault:FaultEvent = info as FaultEvent;
           
    // Redundant ModelLocator lookup and references…
    // ModelLocator.getInstance()…
  }
}

By defining a Responder abstraction each concrete Responder implementation would result in significantly less code as the redundant cast operations could be abstracted, and, as with Command Abstractions, a convenience reference to the application specific ModelLocator could also be defined. Moreover, a default service fault implementation could be defined from which each service fault could be handled uniformly across the application.

Thus we could define an abstracttion for RPC Responders as follows:

import mx.rpc.IResponder;
import mx.rpc.events.FaultEvent;
import mx.rpc.events.ResultEvent;
   
/**
 *
 * Defines an abstraction of common references and
 * functionality from which concrete IResponder
 * implementations can inherit
 *
 */
internal class AbstractRPCResponder implements IResponder
{   
  protected static var modelLocator:ModelLocator
                       = ModelLocator.getInstance();
           
  // Provides a default implementation of
  // mx.rpc.IResponder.result(); which
  // handles casting to a ResultEvent
  public function result(data:Object):void
  {
    var result:ResultEvent = ResultEvent( data );
    resultResponse( result );
  }
       
  // provide default implementation of
  // mx.rpc.IResponder.fault(); which
  // handles casting to a FaultEvent
  public function fault(info:Object) : void
  {
    var fault:FaultEvent = FaultEvent( info );
    faultResponse( fault );
  }
       
  // Force concrete implementation to override
  // resultResponse
  public function resultResponse(result:ResultEvent):void
  {
    throw new Error( "Abstract operation" );
  }
       
  // Provides default service exception handling
  // universally across all Responder implementations.
  // Concrete implementations can also override this
  // method if specific fault handling needs to be
  // implemented
  public function faultResponse(fault:FaultEvent):void
  {
    // implement default service exception handling
  }
}

We could now refactor the original Responder implementation to the following simplified implementation:

import mx.rpc.events.ResultEvent;
   
public final class SomeResponder extends AbstractRPCResponder
{      
  override public function resultResponse(result:ResultEvent):void
  {
    // modelLocator…
  }
}

As you can see just be pulling up common references and functionality to just two abstractions we can significantly remove redundancy from all Commands and Responders. As such this allows designs to improve dramatically as it allows for the isolation of tests and limits the amount of concrete implementation code developers need to sift through when working with your code.

It is important to understand that a design which is built in part on Cairngorm must still adhere to the same underlying Object Oriented Design principles as any other API would, and in doing so you will end up with a much simpler design which can easily scale over time.

April 21, 2009 Agile / Code Review / Design Patterns / Object Oriented Design / Refactoring
3 comments

Refactoring Ant Builds with Macrodefs

Within the past few years the proliferation of Agile Best Practices has pushed the importance of refactoring front and center in the world of Object Oriented Software Design, yet for some odd reason build scripts seem to have been overlooked in this regard by many. Perhaps this is due to the risk and complexity involved in such an effort as well as the lack of a tools by which refactoring build scripts can safely be accomplished.

For instance, whereas refactoring in typical OO languages relies heavily on Unit Tests for ensuring refactorings do not break existing code along the way, build scripts do not have such safety nets as Unit Tests. Ant is statically typed however it doesn’t provide compile time type checking, additionally build scripts are defined declaratively via XML mark-up however they can not be validated as there are not fixed DTD attributes to validate them against. Perhaps most importantly is that there are not many resources to turn to for guidance when it comes to refactoring Build Scripts. For example, most of what I have learned about the subject comes from Julian Simpson’s work in the ThoughtWorks Anthology, which I highly suggest reading for a much more exhaustive, yet comprehensive and succinct essay on the subject. In any case, based on the above factors I am quite certain that all of these points plays a role in Ant Scripts somehow being overlooked with regard to refactoring.

So where do you begin?
That’s a really good question, one which I was forced to ask myself awhile back while being tasked with the daunting challenge of streamlining a very complex Build / CI process. At the time, I was responsible for modifying a Build for a large enterprise class Flex application which required build time transformations of localized content with varying modules being built for n-locales depending on context specific business rules, all of which needed to be built and deployed to multiple environments via a pre-existing CI Process. Further complicating things was that the builds were wrapped by nested DOS batch files. In addition, the existing builds had dependencies on far more complex underlying build Scripts. To make matters worse, up until that point in time no one, including myself, truly knew the build structure and all of it’s dependencies, it was very much a black box. So considering the fact that I needed to modify the build and would be responsible for maintaining the builds moving forward, as well as streamlining the existing build scripts so as to allow them to scale in order to support additional applications to seamlessly become part of the build, to say the least, I was eager to learn the Build Scripts inside out if I was to refactor and maintain them.

The moral to the story I just bored you with above is that if you have ever had to maintain a build before then this story probably sounds pretty familiar: you have a Build Script which is a black box that no one wants to deal with; it works and that’s all that matters – until it needs to change of course. So again, where does one begin when refactoring a Build Script? Well lets think in terms of typical OO refactoring.

Remove duplication
Perhaps one of the most obvious and easiest places to begin consideration for refactoring candidates in an Object Oriented Design is to remove duplication; that is to isolate and thin out common functionality so as to remove redundancy and duplication. Most Ant Scripts are littered with such duplication, and as such should be viewed in the same manner as one would when refactoring Object Oriented applications. In fact, the goal of refactoring is very much the same regardless of the paradigm – beit a declaratively language such as Ant or an Object Oriented language such as ActionScript – provide more efficient, maintainable and easier to work with code.

I tend to think of Build Script design – yes, it is design – much the same as any other OO design. So just as one would strive to eliminate code duplication in an Object Oriented Design, the same should apply to the design of a Build Script. For example, consider the following build target which packages a series of distributions:

   
<target name="package" depends="package.src,
                                package.tests,
                                package.bin,
                                package.docs,
                                package.dist"
                                />
   
<target name="package.src" >
    <zip basedir="${src.dir}"
         destfile="${dist.dir}/${dist.src.name}.zip"  
         />
</target>

<target name="package.tests" >
    <zip basedir="${src.tests.dir}"
         destfile="${dist.dir}/${dist.src.name}.zip"  
         />
</target>

<target name="package.bin" >
    <zip basedir="${bin.dir}"
         destfile="${dist.dir}/${dist.bin.name}.zip"  
         />
</target>

<target name="package.docs" >
    <zip basedir="${docs.dir}"
         destfile="${dist.dir}/${docs.name}.zip"
         />
</target>
   
<target name="package.dist" >
    <zip basedir="${dist.dir}"
         destfile="${dist.dir}/${package.name}.zip"
         />
</target>
 

This kind of Build Script is common, however if you were to think of this in terms of OO Design, whereas each target is analogous to a method, you would quickly realize the code is very redundant. Moreover, the functionality provided by these targets: the packaging of distributions, is a very common task, so just as in an OO design this functionality should be extracted into a reusable library. In Ant 1.6+ we can achieve the same kind of code reuse by extracting these common, redundant targets using Macrodefs.

Use Macrodefs
In short, a Macrodef, which is short for “macro definition”, is basically an extracted piece of reusable functionality in an Ant that can be used across Build Scripts for performing common, or specific tasks. Macrodefs can be thought of as a reusable API for Ant. You include macrodefs in your build scripts by importing the macrodef source file. This is analogous to how one would import a class.

So consider the redundant targets outlined above. Using macrodefs we can extract these common tasks, refactoring them into a single macrodef, import the file which contains the macrodef into our build script and then call the macrodef by wrapping it in a task.

To extract the target to a Macrodef we would first begin by creating a new XML document named after the functionality of the target, in this case we could call it “dist.xml”. This document would contain a project root node just as any other Ant Script would. We would then define a macrodef node and specify an identifier via the name attribute; this is how we can reference the macrodef once imported to our build script.

<?xml version="1.0"?>
<project name="package">
    <macrodef name="package.dist" >
    </macrodef>
</project>

Once we have defined the macrodef we can add dynamic properties to its definition. This could be thought of as begin analogous to arguments of a method signiture. By specifying these arguments we can then assign their values whenever we invoke the macrodef. Default values can also be added if needed.

<?xml version="1.0"?>
<project name="package">
    <macrodef name="package.dist" >
        <attribute name="base.dir"  />
        <attribute name="dist.dir"  />
        <attribute name="dist.file" />
    </macrodef>
</project>

Finally, we specify the behavior of the macrodef via the sequential node, This is where the functional markup is defined. Note that we reference the properties internally using the @{property} notation, just as you would normally however the token is prefixed with an @ sign rather than a $ sign.

<?xml version="1.0"?>
<project name="package">
    <macrodef name="package.dist" >
        <attribute name="base.dir"  />
        <attribute name="dist.dir"  />
        <attribute name="dist.file" />
        <sequential>
            <zip basedir="@{base.dir}"
                  destfile="@{dist.dir}/@{dist.file}.zip"
                  />
        </sequential>
    </macrodef>
</project>

We now have a parametrized, reusable piece of functionality which we can use across Ant Builds, and as such, simplifying the build while promoting code reuse.

To use the macrodef in another Ant Build we need only import it and create a target which wraps the macrodef. So we could refactor the distribution targets from the original Build file example to the following:

<import file = "package.xml"  />

<target name="package" >
    <package.dist base.dir="${src.dir}"  
                  dist.dir="${dist.dir}"
                  dist.file="${dist.src.name}"
                  />
    <package.dist base.dir="${tests.dir}"
                  dist.dir="${dist.dir}"
                  dist.file="${dist.tests.name}"
                  />
    <package.dist base.dir="${bin.dir}"  
                  dist.dir="${dist.dir}"
                  dist.file="${dist.bin.name}"
                  />
    <package.dist base.dir="${docs.dir}"  
                  dist.dir="${dist.dir}"
                  dist.file="${dist.doc.name}"    
                  />
    <package.dist base.dir="${dist.dir}"  
                  dist.dir="${dist.dir}"
                  dist.file="${dist.package.name}"
                  />
</target>

And that’s the basics of using macrodefs to refactor an Ant Build. There is a lot more which can be accomplished with macrodefs in regards to designing and refactoring Ant Builds, specifically antlib, and I encourage you to give it a try as I am sure you will be happy with the results.

February 7, 2009 Agile / Code Review / Continuous Integration / Refactoring / Test Driven Development
1 comment

Pattern Recognition

Its been said that the true sign of intelligence lies in ones ability to recognize patterns – and there is a lot to be said of that statement as patterns can be found everywhere, in everything, in everyday life.

One of the greatest strengths of human intelligence is in our ability to recognize patterns and abstract symbolic representations even when they occur in contexts different from that in which we originally learned them. It’s why hard to grasp concepts which are foreign or new to us become very clear when explained through metaphor.

This ability to recognize patterns is essential to our survival, always has been. For example, practically all ancient civilizations had a very, very good understanding of the recurring patterns in their environment; something we like to call seasons. This understanding of patterns in time and climate was crucial to the survival of these early civilizations. Our ability to recognize patterns is essential to our learning and understanding of the world around us. Pattern recognition is a cognitive process much like intuition. Arguably they are inter-related or possibly one and the same.

Suppose you you want to lose a few pounds, or save a little extra money, or learn a new programming language etc. but you are not seeing the results you would like. By recognizing patterns in your behavior you will begin to notice areas which need to be adjusted and from that determine an appropriate solution and the necessary adjustments to be made in order to achieve your goal. For example, maybe you’ve been trying to save some extra money and after a few months realize you are getting nowhere. You then analyze your behavior for recurring patterns and realize your spending half your pay every weekend on beer, just kidding, but you get my point.

Pattern Recognition in Software Development
In the world of software development patterns apply in pretty much just the same way – our ability to recognize them is essential to ensuring the success of a software application. When we discover patterns of recurring problems in software we are then able to consider various potential patterns from a catalog of named solutions, i.e. Design Patterns. Once an appropriate solution is found we can apply it to resolve the problem regardless of the domain.

When designing software, patterns are something that should reveal themselves, never forced into a design. This is how patterns should always be applied; you have a problem, and based on that problem you begin to recognize common patterns, or maybe new ones, which can be applied as a solution to resolve the problem. It should never be the other way around, that is, a solution (Pattern) looking for a problem. However this happens quite often and is pretty evident in many software applications. Many refer to this as “pattern fever“, personally I like to call it “patterns for patterns sake“, or simply “for patterns sake“. Because that’s really what it is.

For example, have you ever found a Singleton implementation where an all static class would have sufficed (e.g. utilities). Or a code behind implementation class which masquerades as an abstract class. Or an Interface where there is clearly only a need for a single concrete implementation (e.g. data centric implementations), or a marker Interface which serves no purpose at all. The list goes on and on.

In some cases it very well may just be an innocent flaw in the design, however the majority of the time it’s a tell tale sign of someone learning a new pattern and knowingly, albeit, mistakenly, attempting to implement the pattern into production code. This is clearly the wrong way of learning a new pattern. Learning new design patterns is great and a lot of fun but remember, there is a time and place for everything, and production code isn’t it.

Learning Patterns
One of the best ways to learn a new pattern (or anything new for that matter) is to explore it. Begin by reading enough about it to get some of the basic concepts to sink in a bit. Put it into context, think of it in terms of metaphor – in ways that make sense to you, remember you are learning this. Question it. Then experiment with it. See how it works, see how it doesn’t work, break it, figure out how to put it back together, and so on, but whatever works best for you. Most importantly always do it as a separate effort such as a POC, but never in production code.

Once you get this down and understand the various patterns you’ll find you never need to look for them, for if they are needed they will reveal themselves sure enough.

January 17, 2009 Agile / Code Review / Design Patterns / Object Oriented Design
2 comments

What makes a good design?

One of my core job responsibilities for the past several years has been to conduct technical design and implementation (code) reviews during various phases of the software development life cycle. This is typically a highly collaborative process whereas myself and an individual engineer, or the team as a whole will begin by performing a detailed analysis of business requirements in order to gain an initial understanding of the specific component(s) being developed. Once an understanding of the requirements has been reached a brainstorming session ensues which ultimately leads to various creative, technical solutions. After discussing the pros and cons of each the best solutions quickly begin to reveal themselves, at which point it is simply a process of elimination until the most appropriate solution has surfaced.

The next step is to translate the requirements into the proposed technical solution in the form of a design document. The design is specified on a high level and is only intended to provide an overview of the appropriate technical road map which is to be implemented. This typically consists of higher level UML Sequence and Class diagrams, either in the form of actual diagrams produced in a UML editor, or could simply be a picture captured from UML drawn out during a whiteboarding session. The formality of the documented design is less important, what is important is that the design is captured in some form before it is implemented. Implementation specific details such as exact class and method signatures and so forth are intentionally left out as they are to be considered outside the scope of the design. See Let Design Guide, not Dictate for more on this subject. Once the design is documented it is reviewed and changes are made if needed. This process is repeated until all business and technical requirements have been satisfied, at which point the “all clear” is given to move forward with implementing the design.

But what exactly constitutes a good design? How does one determine a good design from a bad one? In reality it could vary significantly based on a number of factors, however in my experience I have found a design can almost always be judged according to three fundamental criterion: Correctness, Cohesion / Coupling and Scalability. For the most part everything falls into one of these three categories. Below is a brief description of the specific design questions each category sets out to determine.

  • Correctness
    Does the design solve the problems described in the requirements and discussed by the team? This is Correctness in the form of satisfying business requirements. Are the patterns implemented in the design appropriate, or are additional patterns being used just for the sake of using the pattern? This is Correctness in the form of technical requirements. A good design is well focused and only strives to provide a solution which meets the requirements specified by the business owners, client etc; it does not attempt to be overly clever.
  • Cohesion / Coupling
    Has a highly cohesive, loosely coupled design been achieved? Have the classes, interfaces and APIs been logically organized? Does each provide a specific, well-defined set of functionality? Is composition used over inheritance where applicable? Has related functionality been properly abstracted? Does changing this break that, does adding that break this, etc.
  • Scalability
    Does the solution scale well? Is it flexible? A good design strives to facilitate change with confidence, and with as little risk as possible. A good design also achieves transparency at some level in the areas where it is most applicable.

    • The concepts outlined above are crucial to achieving a good design, however they are often overlooked or misunderstood to some degree. Throughout the years I have began to recognize some commonality in the design mistakes I find in Object Oriented Designs in general, and within Flex projects in particular. Many of which typically can be attributed to violations of basic MVC principles, but most commonly the design mistakes appear to be a negation of Separation of Concerns (SoC).

    There are close relationships between Correctness, Cohesion / Coupling and Scalability, each of which plays a very significant role in the resulting design as a whole.

    So lets start with Correctness, which is by far the single most important facet of design, for if the design does not provide a solution which satisfies the requirements specified then it has failed – all other aspects of the design are for the most part, details.

    It is important to understand that Correctness has a dependency on Flexibility. For example, as architects and developers our understanding of the problem domain is constantly evolving as we gain experience in the domain. Additionally, as requirements may change significantly as a product is being developed, our designs must be able to adapt to these changes as well. Although this poses some challenges it is wrong to suggest that requirements need to be locked down completely before the design phase begins, but rather requirements need only be clearly defined to the extent that the designer is aware of what is required at that point in time and how it fits into the “big picture”. A competent designer understand this well and makes careful considerations before committing to any design decisions. This is where the importance of Flexibility comes into play. In order for a design to be conceptually and technically correct it needs to be flexible enough to support change. This is why good design is so important – to easily facilitate change. As such the flexibility to allow change should be evident throughout the design. A good example might be where the middle-tier has not decided which service layer implementation will be used (e.g. XML:80, WSDL, REST etc.), or the Information Architects have not decided what the constraints of each user role will be. A good design should be flexible enough to allow for changes such as these as well as others with confidence and more importantly, little risk to other parts of the application; after all, you shouldn’t have to tear down the house just to renovate the bathroom – in addition to Correctness and Scalability, this is where Cohesion and Coupling come into play.

    High Cohesion is vital to achieving a good design as it ensures related functionality and responsibilities are logically grouped together, encapsulated and abstracted. We have all seen the dreaded, all encompassing class which assumes multiple responsibilities. Classes such as these have low cohesion and are a sign of future challenges if not addressed immediately. On a higher level, if high cohesion had not been achieved it is easy to notice as there will typically only be one class which comprises an entire API, however quite often low cohesion in classes may be a bit more subtle than one might expect and a code review will reveal areas where low cohesion has been implemented.

    For example, consider the following Logging facility which is intended to provide a very simple logging implementation:

    The above example is such a classic case of low cohesion. I see this kind of thing all the time. The problem here is that the Logger class has low cohesion because it is assuming the responsibility of creating and formatting a time stamp, this functionality is outside of the responsibilities of the Logging API. The creating and formatting of a time stamp is not a concern of the Logger, but rather would be the responsibility of a separate DateFormatting utility whose sole purpose is to provide an API for formatting Date objects. Removing the Date formatting functionality from the Logging API to a class which is responsible for formatting Date objects would facilitate code reuse across many APIs, reduce redundancy and testing as well as allow the Logger class to only define operations which are directly related to Logging. A good design must achieve high cohesion if it is to be successful.

    Coupling is essential in determining a good design. A good way to think of coupling is like this: Think back to when you were a kid playing with blocks, you could easily take any number of different blocks and rearrange them to build whatever you like – that’s loose coupling. Now compare that to a crossword puzzle or a jigsaw puzzle, the pieces only fit together in a very specific way – that’s tight coupling. A good design strives to achieve loosely coupled APIs in order to facilitate change as well as reuse. A classic, yet less commonly mentioned example tight coupling is in the packaging of APIs. Often, many times designers will achieve loosely coupled APIs however the APIs themselves are tightly coupled to the application namespace.

    Consider the of Logging API example from above, note that the API is defined under the package com.somedomain.someproject.logging. Even if the example were to be refactored to achieve high cohesion it would still be tightly coupled to the project specific namespace. This is a bad design as in the event another product should need to use the Logging API it would first need to be refactored to a common namespace. A better design would be to define the Logging API under the less specific namespace of com.somedomain.logging. This is important as the Logging facility itself should be generic in that it could be used across multiple projects. Something as simple as proper packaging of generic and specific components plays a key role in a good design. A better design for the above example would be as follows, this design achieves both high cohesion and loose coupling:

    As with all design, technical design is subjective. Architects and Engineers can spend an infinite amount of time debating the various points of design. In my experience it really comes down to organization and efficiency, that is, organization of responsibilities and concerns, and the efficiency of their implementation both individually and as a whole.

    It may sound cliche’ however before you begin a new design, or review an existing one, consider the following quote before doing so – it pretty much sums up what good design is:

    “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
    - Antoine de Saint-Exupery

    November 7, 2008 Agile / Code Review / Design Patterns / Object Oriented Design / Software Engineering / Test Driven Development
    5 comments

    Let design guide, not dictate

    A good design should be intended to guide implementation, not dictate it; and for good reason as in the real world of software development requirements and systems are far to complex and dynamic in nature to view a technical design as anything more than a basic prescription intended to form the basis of an efficient implementation. Yet far too often many people seem to believe that once a detailed design has been completed and approved implementation should be a breeze; however, this is just not a very realistic expectation.

    For instance, one of my core job responsibilities is to review technical design documents and provide feedback and direction. This is an iterative process which typically has between 1-3 iterations depending on the complexity of the system. Initially myself and an engineer are given requirements for review. He or she then begins an initial draft of the design and once completed passes it on to me for review. I then review the document and provide feedback where applicable, either via annotations to the document itself or by reviewing with the developer (which is by far my preferred process). Should modifications be required the developer will then make revisions as needed. This process is repeated (within practicality) until final design has been approved.

    At first it may appear as if only a single design iteration and review would be needed, however more often than not, requirements may not be completely understood during the beginning stages of design, nor are they typically ever set in stone so it is very common that a design will need to change during the early stages of a project or even throughout the entire development stage. Once final design has been completed an engineer then begins implementing the design. Theoretically this may appear to be a quite simple process: create a great design which contains as much detail as possible, review it, make revisions and approve it, then just pass it off to any developer for implementation and that’s it, done, right? – wrong!

    There are a number of problems to this approach. Below I have outlined the three I feel are most significant and the solutions I have found to address each.

  • Creativity
    The first problem is that a design which goes into too much detail completely limits or even worse, kills creativity – which in my opinion is the single most important trait a developer can possess, especially when designing. The developer is now merely a typist and will undoubtedly become very bored when implementing the design, especially if it is not even his/her design to begin with! Because of this lack of creativity the final code will ultimately suffer and bugs can be expected. Keeping design on a higher level allows developers to have the creative freedom needed to provide quality implementations and work they can feel is their own.
  • Flexibility
    The second problem is that the more detailed and precise the design the less flexibility there is when requirements change and modifications need to be made to the design and thus implementation. For example, if a design contains very low level details, such as method signatures and other implementation specific details the ability to change the design now becomes increasingly complex and will result in much of the design needing to be reworked significantly. In addition the more detail there is the harder it is to write unit tests against the design as the actual implementation has already been defined. Designs need to be very high level and should not go beyond identifying class names, their responsibilities, relationships and dependencies.
  • Tools
    The third problem is that far too often developers get caught up in all the details of UML notation and related tools. Again, this negates creativity and results in the developer concentrating more on making the design look technically correct rather than concentrating on designing towards a great solution which addresses the problem at hand. In addition, this also results in unnecessary time being spent to complete the design – time which otherwise could have been much better spent on something that produces a better pay off for the project. Now this is not to say that UML shouldn’t be used, actually quite the contrary as I feel a final design should be in UML (or some other format) as a shared language is very helpful in allowing readers to easily understand the design. I always suggest a technique where developers draw out their design in any way that makes sense to them without having to give much thought to anything other than the solution itself. This could be anything from drawing / scribbling thoughts on a pad, to building out a vision from legos – seriously! Only once the design has been envisioned would I recommend bringing it to realization through the use of a formal design tool, such as Visio or other UML tools to be used.

    • The above illustrates the three most common design issues I have encountered, most of which pertain to over-detailed designs, as well as the approach I take to address each. If you have not encountered any of these issues in your own work than that is generally a good sign, however try to keep them in mind when designing as it will pay off in the end. The important thing to remember when designing is to design for flexibility and simplicity. Less is usually more and the KISS principle, especially when applied to software design, will always pay off in the end.

    May 27, 2008 Agile / Code Review / Design Patterns / Object Oriented Design / Software Engineering
    4 comments

    Principle of Least Knowledge

    One very important (yet often overlooked) design guideline which I advocate is the Principle of least knowledge.

    The Principle of Least knowledge, also known as The law of Demeter, or more precisely, the Law of Demeter for Functions/Methods (LoD-F) is a design principle which provides guidelines for designing a system with minimal dependencies. It is typically summarized as “Only talk to your immediate friends.”

    What this means is a client should only have knowledge of an objects members, and not have access to properties and methods of other objects via the members. To put it in simple terms you should only have access to the members of the object, and nothing beyond that. Think if it like this: if you use more than 1 dot you are violating the principle.

    Consider the following: We have three classes: ClassA, ClassB and ClassC. ClassA has an instance member of type ClassB. ClassB has an instance member of type ClassC. This can be designed in such a way which allows direct access all the way down the dependency chain to ClassC or beyond, as in the following example:

    // ClassA defines a member of type ClassB and provides
    // access to the instance
    public class ClassA
    {
        private var b:ClassB;
       
        public function getB() : ClassB
        {
             return b;
        }
    }

    // ClassB defines a member of type ClassC and provides
    // access to the instance
    public class ClassB
    {
        private var c:ClassC = new ClassC();
       
        public function getC() : ClassC
        {
             return c;
        }
    }

    // ClassC could expose additional members and on and
    // on creating more and more direct dependencies
    public class ClassC
    {
        public someType:SomeType;
        …
    }

    // client implementation
    var a:ClassA = new ClassA();
    var sometype:SomeType = a.getB().getC().someType;
     

    The above example is quite common, however it violates The Principle of Least Knowledge as it creates multiple dependencies, thus reducing maintainability as should the internal structure of ClassA need to change so would all instances of ClassA.

    Now keep in mind that in all software development there are trade-offs to some degree. Sometimes performance trumps maintainability or vice-versa, other times readability trumps both. A perfect example of where you would not want to use The Principle of Least Knowledge is in a Cairngorm ModelLocator implementation. The Cairngorm ModelLocator violates the Principle of least knowledge for good reason – it simply would not be practical to write wrapper methods for every object on the ModelLocator. This is the main drawback of the Principle of least Knowledge; the need to create wrapper methods for each object, which are more formally known as Demeter Transmogrifiers.

    The goal of good software design is to minimize dependencies, and by carefully following the guidelines provided by The Principle of Least Knowledge this becomes much easier to accomplish.

    February 2, 2008 Agile / Code Review / Design Patterns / News / Object Oriented Design / Software Engineering
    1 comment

    API Design: Method parameter objects

    When defining a constructor or method with more than three parameters it is considered a best practice to create a parameters object for holding the values which are required. This especially holds true when some of the parameters are optional (as they will contain default values) and also when two or more consecutive parameters are of the same type (as developers may accidentally transpose these parameters – which will not result in compile time or runtime errors, making debugging a nightmare!)

    The most appropriate solution for such cases is to break up the method into separate methods, however when this is not feasible creating a parameters object will improve both code readability and provide a cleaner design which leaves less room for unexpected errors.

    Consider the following method:

    public function someMethod(a:String,
                               b:Object,
                               c:int = 1,
                               x:int = 2,
                               y:int = 3,
                               z:Boolean = true):SomeType
    {

    The parameters defined in this method are typical of what you will often see, however it is much cleaner and reliable to create a parameters object for holding these parameters. In addition, a parameters object allows for a much easier client implementation as default values need not be reassigned for all parameters which proceed a parameter which you need to specify a value other than the default value. For instance, if a method accepts 5 parameters and the first two parameters are required but the last three are optional, if you you need to specify a value for the last parameter you will need to re-assign the default values for the proceeding parameters, when in fact you really only need to specify three parameters.

    The following example demonstrates creating a parameter object which can be passed to “someMethod”:

    package
    {
        public final class SomeMethodParams
        {
          public var a:String;
          public var b:Object;
          public var c:int = 1;
          public var x:int = 2;
          public var y:int = 3;
          public var z:Boolean = true;
           
          //only specify required parameters in constructor
          //optional parameters are simply public properties
          //which have default values assigned
          public function SomeMethodParams(a:String, b:Object)
          {
              this.a = a;
              this.b = b;
          }  
       }
    }

    When invoking “someMethod” clients can now simply instantiate an instance of the parameter object, set values only for what is needed and pass it in as follows:

    var params:SomeMethodParams= new SomeMethodParams("a",{}) ;
    params.z = false;

    instance.someMethod( params );

    So if you would like to improved code readability and provide proactive exception precautions, consider utilizing parameter objects for methods which require more than three parameters.

    January 12, 2008 Agile / Code Review / Design Patterns / Object Oriented Design / Software Engineering
    2 comments

    Quick Tip: Cairngorm Best Practice

    When developing Flex applications in Adobe Cairngorm it is quite common to define all event constants as follows:

    public static const LOGIN_EVENT:String = "LoginEvent";

    The problem with this design is that there is no way of guaranteeing the event type will not collide with an Event type in another package.

    Now, I think it is only fair to say that in a good design there typically would not be two Events with the exact same name. However, when developing large scale Flex applications in which additional modules are added with each major release, not to mention the fact that there can be literally hundreds and hundreds of classes, the chances of creating an Event with the same name begins to increase.

    As a best practice you should assign the Event type a value which is identical to the Event’s fully qualified class path. This will ensure there can never be a collision of Event types. An example can be seen in the following:

    package com.domain.events
    {
    import com.adobe.cairngorm.events.CairngormEvent;

    public class LoginEvent extends CairngormEvent
    {    
       public static const LOGIN_EVENT:String="com.domain.events.LoginEvent";

       public function LoginEvent()
       {
           super ( LOGIN_EVENT );
        }
      }
    }

    It’s always better to be safe than sorry.

    January 10, 2008 Code Review
    8 comments

    Enforcing an all static API in ActionScript 3

    It is quite common when designing an API or system in Adobe Flex that you will identify certain areas which call for specific classes to contain an all static API.

    Typically, all-static classes are utilized as helper, utility and factory classes which provide static methods for performing common utility methods.

    A commonly overlooked aspect of such designs is the assumption that an all-static class will not be misused by clients, specifically via instance instantiation, as it is assumed by the designer that an all static class would never be instantiated as there are no instance members available, only static class members. This is a fair assumption. However it is not possible to guarantee this will never occur as ActionScript 3 does not support private constructors (yes, I am back on this subject yet again). Although this is an unfortunate limitation of the language it should not deter you from enforcing such restrictions.

    To help facilitate these restrictions in my own designs I have created a very simple, yet effective Abstract class called AbstractStaticBase, which helper and utility classes can extend in order to ensure they are never instantiated.

    Classes which contain an all static API can extend AbstractStaticBase in order to ensure they can never be instantiated. This is the only requirement.

    AbstractStaticBase is lightweight as it only contains a constructor. The constructor does nothing more than create an Error object and parse the call stack to determine the fully qualified name of the concrete class which has been instantiated, the message property is then set on the Error object and thrown.

    Implementation on the clients part is very straightforward as all that is required is to extend AbstractStaticBase.

    Consider the following example. CalcUtil is an all static class, to ensure an instance of CalcUtil is never instantiated simply extend AbstractStaticBase as follows:

    package com.domain.utils
    {
        import com.ericfeminella.AbstractStaticBase;

        public class CalcUtil extends AbstractStaticBase
        {
             public static function calculate() : Number
                 {
                 // implementation not pertinent to subject
             }
        }
    }

    // an attempt to instantiate CalcUtil …
    var util:CalcUtil = new CalcUtil ();
     
    // results in the following exception:
    // Illegal instantiation attempted
    // on class of static type: com.domain.utils::CalcUtil
     

    So if you want to enforce that static classes are never instantiated, simply extend AbstractStaticBase.

    September 28, 2007 Code Review / Design Patterns / Object Oriented Design / Software Engineering
    No comments

    Quality API Design: A how to from Google

    As a lead Software Engineer for a large organization I spend a great deal of my time designing APIs. I spend practically the same amount of time mentoring team members and evangelizing the benefits of a good design.

    If you are a programmer than you are a designer; that is, you design class hierarchies and compositional relationships, determine whether an interface or abstract is needed and so forth. This is all part of designing an API, and the more thought you give to your design the better the results will be.

    Conceptually, designing a quality API is pretty straight forward: all requirements must be satisfied by the design in a clean and efficient manner. However there are many details involved which you should keep in mind when designing.

    Joshua Bloch, Principle Software Engineer at Google has published a very useful article which covers the various facets of good API design. If you are a programmer this is definitely worth reading. Check it out.

    May 20, 2007 Code Review / Design Patterns / Object Oriented Design / Software Engineering
    1 comment
    ← Older Entries
    Newer Entries →