The State Design Pattern vs State Machine

Background

Design patterns in software development are an essential tool to excellent software creation. Being able to identify patterns while observing source code, is an essential skill that is acquired over a period of years of object oriented software development practices. Over the years, I’ve seen patterns being implemented that only have the name of the pattern in file names but hardly represent the actual pattern the way they were intended to be used. Also, I have seen state machines being used instead of state design patterns at the costs of horribly complicated software that is hard to maintain. There is no reason to use state machines anymore when you are using an object oriented programming language.

One of the best sources about software design patterns is the “Design Patterns: Elements of Reusable Object-Oriented Software” book by the Gang of Four. Still, it is the bible of design patterns after all these years. There are many other sources and books but the blue book by the Gang of Four is the fundamental one that all seasoned architects and developers should have mastered.

Design patterns are programming language neutral. What they convey and solve are concepts that can be applied in any object oriented programming language such as C#, C++, Delphi, Java, Objective-C, etc. It is these concepts that one should master. Once the concepts are mastered, it is fairly straightforward to identify opportunities to use and apply them. At that point, it is simply a matter of language syntax.

In this article, I will discuss the State Design Pattern. I will discuss the state design pattern on how it can be used in a fairly complex scenario and demonstrating this with sample C# code. I will also discuss using the state design pattern instead of using a state machine. I will not go into the details of how to create state machines, rather I will concentrate on the much more modern State Design Pattern. I picked a complex scenario because I believe that a more complex scenario can teach several things at once. It will demonstrate the combination of different scenarios and answer more questions this way.

The State Design Pattern:

I would summarize the State Design Pattern as follows:

“The state design pattern allows for full encapsulation of an unlimited number of states on a context for easy maintenance and flexibility.”

From a business side of things, this is worth a lot of money. There is no reason anymore NOT to use the state design pattern even in very simple state scenarios. You can get rid of switch statements (C#), for example. It buys you flexibility because you won’t be able to predict the future and requirements changes (I’m pretty sure about that).

The State Design Pattern allows the context (the object that has a certain state) to behave differently based on the currently active ConcreteState instance.

Let’s take a closer look into the parts that make up the state design pattern.

Context Object

Context is an instance of a class that owns (contains) the state. The context is an object that represents a thing that can have more than one state. In fact, it could have many different states. There is really no limit. It is perfectly fine to have many possible state objects even into the hundreds. It is coming to have context objects with only a handful of possible states, though.

The context object has at least one method to process requests and passes these requests along to the state objects for processing. The context has no clue on what the possible states are. The context must not be aware of the meaning of these different states. It is important that the context object does not do any manipulation of the states (no state changes). The only exception is that the context may set an initial state at startup and therefore must be aware of the existence of that initial state. This initial state can be set in code or come from an external configuration.

The only concern that the context has is to pass the request to the underlying state object for processing. The big advantage of not knowing what states the context could be in is that you can add as many new states as required over time. This makes maintaining the context super simple and super flexible. A true time saver and a step closer to being rich beyond your wildest dreams (almost).

State

The state class is an abstract class. It is usually an abstract class and not an interface (IInterface). This class is the base class for all possible states. The reason why this class is usually an abstract class and not an interface is because there are usually common actions required to apply to all states. These global methods can be implemented in this base class. Since you can’t do any implementation in Interfaces, abstract classes are perfect for this. Even if you do not have any initial global base methods, use abstract classes anyways because you never know if you might need base methods later on.

The State class defines all possible method signatures that all states must implement. This is extremely important to keep the maintenance of all possible states as simple as possible. Since all states will implement these methods signatures and if you forget to implement a new method, the compiler will warn you at compile time. An awesome safety net.

ConcreteState

The ConcreteState object implements the actual state behavior for the context object. It inherits from the base State class. The ConcreteState class must implement all methods from the abstract base class State.

The ConcreteState object has all the business knowledge required to make decisions about its state behavior. It makes decisions on when and how it should switch from one state to another. It has knowledge of other possible ConcreteState objects so that it can switch to another state if required.

The ConcreteState object can even check other context objects and their states to make business decisions. Many times, an object may have more than one context object. When this happens, a ConcreteState object may need to access these different states and make a decision based on active states. This allows for complicated scenarios but fairly easy to implement using the state design pattern. You will see an example later in this article that shows multiple context objects and their states and the need to work together.

The ConcreteState object also is capable of handling before and after transitioning to states. Being aware of a transition about to happen is an extremely powerful feature. For example, this can be used for logging, audit recording, security, firing off external services, kicking of workflows, etc. and many other purposes.

The ConcreteState object allows the full use of a programming language when compared to state machines. Nothing is more powerful in abstract logic and conditionals   coupled with object orientation as a computer programming language compared to state machines and their implementations.

As you add new methods to the abstract base class over time, each ConcreteState class will need to implement that method. This forces you to think from the point of view of the current state.

“How should state ConcreteStateA react when this method is called?”

As you implement the behavior for a method, you can be rest assured that this is the only place in the entire system that will handle this request when ConcreteStateA is the active state. You know exactly where to go to maintain that code. Maintainability is king in software development.

Summary

To summarize, you will need a context and a few states that ideally derive from an abstract base class to create a flexible state solution. If you got switch statements or a lot of If statements in your code, you got opportunities to simplify by using the state design pattern. If you are using state machines, you got an awesome opportunity to simplify your code and safe time & money. Just do it!

Example

The example I created demonstrates the use of the State Design Pattern and how it can be used with multiple context objects working together. It is a fictitious hardware device with a door.

The device can be powered on or off. Specifically, the device has an operations mode that can be in the following states:

1. Idle
2. Busy
3. Powering Down
4. Powering Up

The door represents a physical door on the device. The door can be in the following states:

1. Opened
2. Closed
3. Locked
4. Unlocked
5. Broken

To make it a little more complicated, the device can be in different hardware configurations. These configurations can be changed at run-time of the device. The following configurations are available:

1. Production Configuration
2. Test Configuration

The operation of the device depends on the different individual states as well as a combination of the states listed above. The more combinations that are possible, the more complicated it would be to maintain this using traditional Switch or If statements. You could use a state machine as well but it will not buy you the flexibility and ease of use when compared to the state design pattern. Feel free to add brand-new states and try to experiment with it.

Breaking it Up

No matter how complicated software projects are, the way to tackle them successfully is to break them up. This is especially true in object oriented software development. Breaking things up into smaller, manageable pieces allows a focused effort in understanding the problem domain. It is coming to zoom into the smaller parts and then zoom back out again to a 10,000 foot view and vice versa. You do this many times. Look at the big picture, then break up the picture into smaller parts, look at the smaller part and so forth. Object orientation is a natural fit to model real-life scenarios that contain things, people, processes and their behaviors to interact with each other.

Let’s break up the things that we do know in this example. It looks like we have 3 things:

1. Device
2. Door
3. Configurations

Behavior

It is important to recognize that there is most likely a certain behavior between these things. This behavior is probably driven by certain business or operational rules. The power of object orientation is being able to capture this behavior inside classes. Since an object generally consists of roughly 50% data and 50% behavior, we must take care of the behavior part of objects. Over time, this behavior might change because requirements may have changed. Again, this is where object orientation shines when it is done correctly. 

So, we can assume that Device is on its own. It represents a physical device from the real world. The door is part of the device and can’t live on its own. The device has a door. So, it looks like we have this:

1. Device with a Door
2. Configurations

We also have a set of configurations. These configurations change the operation of the device but are not necessarily part of the physical device. So, we could model configurations on a class by itself. However, since we know that a device can be either in a test configuration or a production configuration, these actually represent operational states. We also know that certain operations or states of the door might behave differently based on the current configuration. So, there is no need to create a separate configuration class and instead model the configurations as states themselves. If we decide to add another type of configuration later on, it will be easy to add.

We have two major parts: Devices and their configurations. We will model each part with their own class. The Device class will contain a Door class (Device has a door):

Both the Device and Door classes inherit from the DomainObject class. The DomainObject class is a convention that I’ve accustomed to use over the years. A base domain object class contains behaviors and features that are shared across all domain objects. For example, my DomainObject class usually implement a read/write string Name property. This name can also be optionally passed into the constructor. When you model real world things, it is very common that these things have names. So, I end up having a Name property in my base DomainObject class. You will see later how this is used.

Code

Let’s start writing some code and implement everything. The example we are building is a console application that sets several states to test the Device’s behavior. It will look like this once the output displays on the screen:

First, lets create the DomainClass, the base class for all domain objects.

</pre></pre>
/// <summary>
 /// Base class for domain objects that provides basic
 /// functionality across all objects.
 /// </summary>
 public class DomainObject
 {
 public string Name { get; set; }

public override string ToString()
 {
 return Name;
 }

public DomainObject()
 {
 }

public DomainObject(string name)
 {
 Name = name;
 }
 }
<pre>

The DomainObject class implements a Name property of type string that allows you to conveniently give an object a name since most objects in real life have names. This is the base class for all domain classes.

Next, we implement the Device class. The Device class contains a Door object. In this scenario, the Device class is the context (the owner) to the operations mode and the possible configurations. The operations mode is represented with the ModeState class. The different kind of configuration states are kept track in the ConfigurationState class.

The Initialize() method is used to setup the different kind of states for the current instance of a device. This is the place where the context (the Device) now needs to be aware of what states are actually available. Notice also that within the method we are setting the operations mode to Powering Up and at the end of the method we set it to Idle.

</pre>
/// <summary>

/// The Device class is the owner of the different states

/// that the Device can be in. The Device is alos the

/// owner of actions (methods) that can be applied to the

/// states. In other words, Device is the thing we are

/// trying to manipulate through outside behavior.

/// </summary>

public class Device : DomainObject

{

// Device has a physical door represented by the

// Door class.

private Door _door;

&nbsp;

// Device only knows about generic actions on

// certain states. So, we use the base classes of

// these states in order execute these commands.

// The base classes are abstract classes of the

// states.

private ConfigurationState _configurationState;

// The current mode that the device is in.

private ModeState _modeState;

&nbsp;

public Device(string name) : base(name)

{

Initialize();

}

&nbsp;

public Device()

{

Initialize();

}

&nbsp;

private void Initialize()

{

// We are starting up for the first time.

_modeState = new ModePowerUpState(this);

&nbsp;

_door = new Door(this);

&nbsp;

// The initial configuration setting for the

// device. This initial configuration can come

// from an external configuration file, for

// example.

_configurationState = new ProductionConfigurationState(this);

&nbsp;

// The door is initially closed

_door.DoorState = new DoorClosedState(_door);

&nbsp;

// We are ready

_modeState.SetModeToIdle();

}

&nbsp;

public Door Door

{

get { return _door; }

set { _door = value; }

}

&nbsp;

public ConfigurationState Configuration

{

get { return _configurationState; }

set { _configurationState = value; }

}

&nbsp;

public ModeState Mode

{

get { return _modeState; }

set { _modeState = value; }

}

}
<pre>

The ModePowerUpState class is one of the ConcreteClass implementations of the State Design Pattern. Let’s take a closer look on how it is implemented.

</pre>
public class ModePowerUpState : ModeState

{

public ModePowerUpState(ModeState modeState)

{

Initialize();

this.Device = modeState.Device;

}

&nbsp;

public ModePowerUpState(Device device)

{

Initialize();

this.Device = device;

}

&nbsp;

private void Initialize()

{

Name = "Powering Up";

}

&nbsp;

public override void SetModeToPowerUp()

{

// We're in powerup state already

}

&nbsp;

public override void SetModeToIdle()

{

// Switch to Idle state

this.Device.Mode = new ModeIdleState(this);

}

&nbsp;

public override void SetModeToBusy()

{

// Can't set mode to busy, we're still powering up

}

&nbsp;

public override void SetModeToPowerDown()

{

// We're busy, but we allow to power down.

&nbsp;

// Cleanup any resources and then set the state

this.Device.Mode = new ModePowerDownState(this);

}

}
<pre>

The first thing to notice is that it inherits from the ModeState abstract base class. This would be the abstract base class for all mode states in state design pattern. The following operation modes are possible for this device:

1. Powering Up
2. Powering Down
3. Busy
4. Idle

Each of these possible modes are represented as individual ConcreteState classes.

An important fact is that one of the constructors takes an abstract representation of a mode: public ModePowerUpState(ModeState modeState)

This constructor is very important since it will allow the object to set the context (the owner) by using polymorphism. Setting the owner via:

</pre>
this.Device = modeState.Device;
<pre>

allows the pass in different kind of modes and always have access to the context. Once we have access to the context, this instance can now manipulate the Device’s mode. It can also manipulate any other properties or call methods on the Device.

Since the ModePowerUpState class inherits from the abstract ModeState class, it needs to implement all abstract methods that are declared in the ModeState class. The abstract ModeState class declares the the following abstract methods:

</pre>
public abstract void SetModeToPowerUp();

public abstract void SetModeToIdle();

public abstract void SetModeToBusy();

public abstract void SetModeToPowerDown();
<pre>

The ConcreteClass ModePowerUpState only needs to actually implement the methods that would make sense. Here the Idle and PowerDown state would make sense.

Lets look at the states for the Door of the Device. Remember that the door can be in the following states:

1. Open
2. Closed
3. Locked
4. Unlocked
5. Broken

The abstract State class for the door states looks like this:

</pre>
public abstract class DoorState : DomainObject

{

protected Door _door;

&nbsp;

public Door Door

{

get { return _door; }

set { _door = value; }

}

&nbsp;

public abstract void Close();

public abstract void Open();

public abstract void Break();

public abstract void Lock();

public abstract void Unlock();

&nbsp;

/// <summary>

/// Fix simulates a repair to the Door and resets

/// the initial state of the door to closed.

/// </summary>

public void Fix()

{

_door.DoorState = new DoorClosedState(this);

}

}

The possible states are represented in the abstract methods:

</pre>
public abstract void Close();

public abstract void Open();

public abstract void Break();

public abstract void Lock();

public abstract void Unlock();
<pre>

We can also find a global base method named:

</pre>
public void Fix()
<pre>

This Fix() method is meant to be called by any of the derived ConcreteState classes in order to bring the Door to an initial Closed state (when it has been been fixed after it was broken).

When you download this example source code, you can take a closer look at all files. But, let’s take a look at the more interesting DoorUnlockedState concrete state class:

</pre>
public class DoorUnlockedState : DoorState

{

public DoorUnlockedState(DoorState doorState)

{

Initialize();

this.Door = doorState.Door;

}

&nbsp;

public DoorUnlockedState(Door door)

{

Initialize();

this.Door = door;

}

&nbsp;

private void Initialize()

{

Name = "Unlocked";

}

&nbsp;

public override void Close()

{

// We can't close an already locked door.

}

&nbsp;

public override void Open()

{

// Can't open a locked door.

}

&nbsp;

public override void Break()

{

// To simulate production vs test configuration

// scenarios, we can't break a door in test

// configuration. So, we need to check the

// Device's ConfigurationState. We also want to

// make sure this is only possible while the

// device is Idle.

//

// Important:

// ==========

// As you can see in the If statement, we can

// now use a combination of different states to

// check business rules and conditions by simply

// combining the existence of certain class

// types. This is allows for super easy

// maintenance as it 100% encapsulates these

// rules in one place (in the Break() method in

// this case).

if ((this.Door.Device.Configuration is ProductionConfigurationState) &&

(this.Door.Device.Mode is ModeIdleState))

{

this.Door.DoorState = new DoorBrokenState(this);

}

}

&nbsp;

public override void Lock()

{

this.Door.DoorState = new DoorLockedState(this);

}

&nbsp;

public override void Unlock()

{

// We are already unlocked

}

}

Take a close look at the Break() method. This is where it gets interesting and demonstrates the use of more than one set of states that are not related to each other. In this case, the state needs to check that the device is in a certain configuration as well as in a certain operations mode before it can set the door state. In order to access these conditions, the state needs access to both contexts,

Because this scenario only allows to break the door when the device is in a production configuration and the operations mode is idle, both conditions are verified by using the state class definitions:

</pre>
if ((this.Door.Device.Configuration is ProductionConfigurationState) &&

(this.Door.Device.Mode is ModeIdleState))

{

this.Door.DoorState = new DoorBrokenState(this);

}
<pre>

By simply chaining class definitions in your comparisons, you get clean compile time validations when compared to string or similar comparisons. The code is fairly easy to read and to expand upon.

Remember that one of your goals is encapsulation when you use object orientation. You have one central place to maintain your code for a certain state that you need to modify or when you need to create a brand new state.

Conclusion

Using a State Design Pattern over Switch and If statements and over State Machines is a powerful tool that can make your life easier and save your employer time & money. It’s that simple.

You can download the source code here. (https://s3.amazonaws.com/StateDesignPattern/DeviceWithStateDesign.zip)

About the Author

Thomas Jaeger is a Solutions Architect and an industry expert for over 21 years in 7 different industries when it comes to software development in general, cloud-based computing, and iOS development. He is a passionate, fanatic, software designer and creator. He lives against the status quo because, in his opinion, creative and innovative solutions are not created following a linear approach but come, in part, from broad experiences in ones life and from an innovative mind. 

The HTML5 Hype vs. Native Application Performance (Again)

The latest buzz is all about HTML 5 and how it will improve our lives as architects, developers, companies, consumers of HTML5 applications and whoever else is getting sucked into this.

I’ve been doing professional software development for over 21 years now.  Over those years, I’ve used many different technologies. HTML 5 is just another “technology”. First of all, let me clarify in simple terms: HTML 5 is NOT a new technology. HTML 5 is based on existing technology called JavaScript, CSS 3 and HTML. None of these are new. What is new is the way it is being presented and marketed.

You see, I take the stand of delivering the best user experience to the consumer. What I mean by best user experience is this:
1.    Your users should “love” to use your software
2.    Your users should feel connected to your software
3.    Your software should accomplish what it said it would do for them, all the time
4.    Your software should do all things extremely fast
5.    Your software should look and feel top notch and professional, nothing less

As you can see from the list above, there are emotional connections between great software and their users. When you have human feelings involved with something as technical as software, you have subjective views on what great software means depending on who you ask. In addition, since most software is created for consumers, you will have to deal with emotional connections of your software and the consumers. You cannot afford to ignore your consumers’ feelings and perceptions of your software.

When you look at the industrial industry, physical objects such as a piece of furniture, a toaster oven, a recording device, etc. have aesthetics to them that triggers an emotional connection between the consumer and the physical object. Some consumers like a particular furniture and some others don’t. But, what is common between the different types of consumers is that they have a emotional connection or not. They like or don’t like a certain type of couch, for example. The design efforts that went into creating a successful piece of furniture maybe based on many factors.  Great designs are aesthetically pleasing and functional at the same time.

For example, look at the success of the iPhone or iPad. Here are devices that not necessarily have brand new technology inside them; but, they are packaged and presented in a way that is aesthetically pleasing to a lot of consumers. Moreover, they perform really fast and do it well all the time (disclaimer: nothing is perfect).  They both feel snappy. They both are easy to use and the content layouts (the user interface) are well thought out. They both are a total hit for Apple.

What would the iPhone or iPad be like if it had an Android or a Windows user interface? Would it still be a hit? Would consumers still love them? Would they buy them? Even worse, what if, both, the iPhone and iPad only had a Web Browser interface? How would consumers have reacted with their purchasing power?

What the iPhone and iPad have both in common is “fast” user feedback. This fast user feedback is, for the most part, is accomplished with native applications that take advantage of the device’s hardware. By native applications, I mean applications that are compiled into machine code for ultimate performance. In case of iPhone and iPad applications, this means that these applications have been developed with Objective-C on the Cocoa framework for iOS.

I’m certain that Steve Jobs had his hands in the user interface design decisions. I’m also certain that he would NEVER accept slow performing applications. If this is the case, I agree with Steve Jobs 100%. I agree because I believe that performance of software is even more important today than it was 20 years ago.

Software is created for people, most of the time. Consumers are spoiled with instance gratification. Consumers expect software to be fast. Consumers expect to get results, fast! People have less time and are doing more at the same time. Slow performing software is bad quality software, period. As a software creator, why would I want to settle for bad quality software? If you create the best software and want to make a living at the same time, you must create software that allows consumers to feel that emotional connection.

With that being said, when I hear things like HTML 5, I see Deja vu. I have seen this with Java, Visual Basic, .Net, ActiveX, Silverlight, etc.
These “new” technologies were created for many reasons and not one of them was created with the consumers in mind. These technologies such as HTML 5 were created with the intention to make things easier for the developers and the companies these developers work for.

The more abstract these technologies are, the more layers there are between the device and the output or user interfaces. The more layers there are, the slower the performance of the software. This principle has not changed in decades no matter how fast the hardware becomes.

At the end, the consumer can clearly see a difference in natively compiled software that was created for that native operating system and software that has these layers of translations that made it so simple for the developer.

This convenience for the developers costs dearly for the company who is selling the software in the long run. If a company truly cares for its target audience, then they better make sure that the emotional connection between the software and the consumer exists. The best way to do this is not to go the easy and lazy route but go the extra mile and develop the software in a computer programming language that has a native compiler. I can think of C++ or Delphi, for example.

Update 2012-04-09: Betting $1 Billion On Instagram, Facebook Backs Away From HTML5

http://www.sfgate.com/cgi-bin/article.cgi?f=/g/a/2012/04/09/businessinsiderbetting-1-billion-on.DTL

What is Cloud Computing?

Over the last few months I’ve been asked more and more this question: “What is Cloud Computing?” It seems the interest in cloud computing is a lot higher in 2011 when compared to last year. So, I decided to put some of my thoughts down in a series of posts and explain what I think cloud computing is all about and how you can take advantage of it. I’m very heavily involved in cloud computing and see cloud computing as the way to go despite a few hick-ups you might hear in the news.

First, let me explain my background in cloud computing. I started to explore cloud computing capabilities back in 2006 when Amazon first announced their set of Amazon Web Services (AWS). Later on, companies such as Google and Microsoft followed. The first time I heard about Amazon’s Simple Storage Service (S3), I was so excited about the possibilities. I was also excited about the cost. It is extremely inexpensive to start developing powerful cloud services and solutions.

As time went by, I explored most of Amazon’s AWS services with amazement as they were updated and new ones were released. I also briefly dabbled with Microsoft’s Azure and Google’s services; but, to this day, it is my strong believe that Amazon is the clear leader in providing the best cloud services and infrastructure in the market today. In fact, I go as far as to say that Amazon is much further ahead of Microsoft and Google combined. Amazon is the clear leader if you develop on a Microsoft stack or LAMP stack. Either way, I will try to explain a little more by what I mean in the following posts.

So, what is Cloud Computing then? From an architecture point of view, I would sum up cloud computing this way:

1. A cloud computing solution is partitioned logically end-to-end
2. A cloud computing solution offers an infinite storage capacity
3. A cloud computing solution offers an infinite computing capacity
4. A cloud computing solution can handle an infinite number of users at the same time
5. A cloud computing solution is always available 24/7
6. A cloud computing solution is available anywhere in the world with low latency
7. And yes, a cloud computing solution offers certain tasks to be completed when connections are down
8. A cloud computing solution offers multiple ways to access the information such as different devices and user interfaces (platform independent on the consuming side)
9. A cloud computing solution expands and contracts with resources as demand increases or decreases
10. A cloud computing solution offers very fast and native execution times on the user interfaces to provide the best user experience
11. A cloud computing solution offers automatic backup and recovery options for consumers

These points above should be available in a modern cloud computing solution. Consider the points above the goals of a great cloud computing solution. The planning and designing of a cloud computing architecture makes the above assumptions. For example, a cloud computing solution acts like it has an infinite storage capacity available.

I’m coining the term “Cloud Computing Partitioning Pattern (CCPP)” and will explain next time what I mean by being able to partition a cloud computing solution in order to provide fast and successful operations from the time a request is received through a domain model all the way to persistence and back.

Until next time.

Designing Software

I have been using computers for over 24 years now. In those years, I have seen and used many operating systems and applications that run on these operating systems. I have seen software from a users point of view and software from a designers point of view when I created software solutions. In those years and up to including today, good software design seems to suffer a severe lack of attention. This results in poor quality software that is hard to use and just plain frustrating for the user. Poor software design can have serious financial impact on anyone who uses it. Poor software design makes people loose time and efficiency. Poor software design makes people wanting to cut corners or worse avoid using it all together if the opportunity allows it.

I strongly believe that when designing software, the human aspect, or the end-user, the one who is actually using the software, is the center of an application. By that I mean, every software design should be centered around the user, the woman or man who will be spending a lot of time with it. Good software design is designed around a person who is using it for a particular purpose.

I wanted to express my thoughts about software design and started thinking how I can express my thoughts and ideas in a way that others can understand. I have an intense passion of creating high-quality software. Almost to a point where you can say I have an obsessive passion of creating the best software it could possibly be. But, what is high-quality software? I have come to learn that high-quality software must be coupled with greatly designed software.

Over the decades, the art of creating software has been influenced by several industries including but not limited by the construction industry, the electronics, industry, and the industrial industry. Design principles and ideas leaked from these industries into the software industry.

Designing successful software, in my opinion, can be guided by the 10 Design Principles from the Industrial design principles by Dieter Rams, an amazing industrial designer and an industry icon who has an extensive and important influence over modern industrial design. I have applied his industrial design principles to the software industry the way I see these principles can be applied. Lets first take a look at what these principles are:

1. Good design should be innovative.
2. Good design should make a product useful.
3. Good design is aesthetic design.
4. Good design will make a product understandable.
5. Good design is honest.
6. Good design is unobtrusive.
7. Good design is long-lived.
8. Good design is consistent in every detail.
9. Good design is environmentally friendly.
10. Good design is as little design as possible.

All 10 design principles can be applied when architecting and designing great software. Each one of these principles above are very true and tested over the decades because they center around a person using a product. The industrial industry has been around for many decades now and we better learn from it.

dVP 2009 Award

I’ve been notified that I have been selected again as a db4o Most Valued Professional (dVP) awardee for the year 2009. I’m honored and proud to receive this recognition for the second time in a row. I want to thank db4o and the db4o community. There are only 12 dVP 2009 awardee’s in the USA. Thank you.

Benefits of Object Persistence

When Object Persistence is done right, there can be some great rewards in the areas of Productivity, Maintainability, and Cost Reduction. Some areas directly affect other areas. For example, if one can maintain an application fairly easily, this would result in a higher productivity. There are fine balances between these areas.

 
Productivity

Productivity in software development can be measured in how fast a developer can complete a given work item with the assumption that the quality of the software is not compromised. How much time does it take to get things done without any compromises? Because most projects have a limited amount of time to complete, being productive impacts Cost Reduction to create and maintain the application as well as a better chance for future funding. Being productive should mean that one can get the work done and still deliver high quality software, with a high degree of reliability, and a fair amount of maintainability. Compromises in any one of these areas will result in loss of productivity either in the short-term or long-term of the product life-cycle.

The Object Persistence can be designed in such a way that the system is not locked into a particular database, for example. Because there is no database vendor lock-in, you can gain productivity by simply abstracting storage specific features. For example, if you decide to use an Object Relational Mapping Tool (ORM), you should let the ORM tool worry about creating and maintaining the database schemas for any database it supports based on your Object Model. This can buy you a tremendous amount of productivity because you are delegating this huge maintenance burden to the ORM tool.

• Productivity in software development can be gained through abstraction and automation.

Maintainability

Depending how Object Persistence is done, it usually allows for easier maintainability when requirements change. The fewer changes that need to be made to a system, the easier it is to maintain. Because of abstracting the object persistence, there is a high possibility that a system can be created that is easy to maintain. Because you no longer have to make changes to a database schema or data access layer, you can concentrate on making the changes usually only in one place: the object model and sometimes to the output such as the user interface or a new report

How many times have you read somebody else’s code and trying to figure out what the heck it is trying to do? Hard to read code, or Spaghetti code, is hard to maintain. In general, the fewer lines of code to maintain, the better. Because of the abstraction of the Object Persistence, much fewer lines of code are necessary. A simple method call such as the Save() method is all it’s needed. This makes the code much easier to read and to maintain.

By eliminating the database schema, eliminating a data access layer, and any data or value objects, we are eliminating several points of failures. By reducing point of failures, the system becomes immediately easier to maintain and more reliable.

The easier it is to maintain an application, the less time is required to train somebody else to learn it. Easy to understand code is easy to support no matter who will need to take over the code.

Maintainability is probably the biggest impact of an application throughout its lifetime much more so than the advantages of reusability in Object Orientation.

Cost Reduction

Studies have shown that in the lifetime of an application, 10% of the time is used to create the application, and 90% is used to maintain it until it is retired. If we can reduce the amount of time needed to maintain the application, we can reduce the amount of money spent to keep it alive. We are trying to work smarter using the right tools instead of harder using no tools or unnecessary procedures.

Being more productive has an immediate impact on cost. When a developer can implement a change quicker, the cost of maintaining an application is reduced. The time saved can be used for other duties or other projects. Many times, being more productive can allow for future projects to be approved vs. projects that won’t make the approval because the timelines would not permit to do so otherwise.

Today, labor cost is one of the most expensive liabilities a company can have. On the other hand, the workforce is also the most important asset a company has. There was a time where hardware was the most expensive part in an IT department. Hardware and tools are now extremely inexpensive today. It is mass produced and no longer a major factor in software development.

Purchasing third party component libraries can reduce the time and effort to complete an application. Some of these tools such as ORM tools can seem expensive initially, but; in the long term, you cannot afford not buying them. It is far more costly to write these components or tools on your own than to purchase them.

I’m a Mac User – I’ve done it

I’ve done it. After almost 18 years, I’ve switched from a PC to my new iMac OS X. I still can’t believe it. Over the years, I’ve always monitored Apple and how they went from a proprietary hardware system to the Intel platform with the new OS X.

As a professional, I’m running my .Net development on the iMac using VMWare under a Windows XP window. Works great. The main reason to actually go out and invest into an iMac was iPhone development for the new iPhone 3G using the COCOA Touch framework and XCode.

This is really exciting and I strongly believe that the iPhone from a development point of view has a huge potential. I’ve some personal projects I’m working on for the iPhone at the moment. When the first app is released in the AppStore, I will announce it here. I’ve not felt this excited since the late 80′s when I started writing my first shareware program ACZAR.

What is Object Persistence

In the last few decades, there have been different ways of creating software solutions from procedural top-down development to object oriented and service oriented solutions. They all have their place and were created based on different requirements, budgets, and skill sets. There are always different ways on how a software solution can be created and implemented. One way of implementing a software solution is to use Object Oriented Software Development (OOSD) and its many advantages. If you are on a project that does not necessarily take advantage of OOSD, that’s fine, too. Not all projects may require a full OOSD solution. In addition, you can always refactor parts of a solution to take advantage of OOSD techniques if time and budget permit or if new business requirements are so that it calls for a OOSD solution.

Object Oriented Software Development is a powerful and proven technique to create software solutions that mimic a network of real life processes, tasks, and business rules of a domain. Most importantly, as you design and develop your solution, you start thinking in a domain specific language. You acquire a deeper understanding of the business. Domain Driven Design (DDD) is a technique within OOSD that allows you to get very intimate with the business and requirements at hand. Eric Evans, author of Domain Driven Design, explains in great detail on how this can be accomplished. I highly recommend his book if you are interested in this exciting technique.

The premise of domain-driven design is two-fold:

* For most software projects, the primary focus should be on the domain and domain logic; and

* Complex domain designs should be based on a model.

Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.

To accomplish that goal, teams need an extensive set of design practices, techniques and principles.

The Challenge of Complexity

Of course, many things can put a project off course, bureaucracy, unclear objectives, lack of resources, to name a few, but it is the approach to design that largely determines how complex software can become. When complexity gets out of hand, the software can no longer be understood well enough to be easily changed or extended. By contrast, a good design can make opportunities out of those complex features.

Some of these design factors are technological, and a great deal of effort has gone into the design of networks, databases, and other technical dimension of software. Books have been written about how to solve these problems. Developers have cultivated their skills.

Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain complexity is not dealt with in the design, it won’t matter that the infrastructural technology is well-conceived. A successful design must systematically deal with this central aspect of the software.

Source: http://domaindrivendesign.org

Many books have been written about OOSD and I encourage you to dig deeper if you are interested in learning specifics. Besides Eric Evans’ book about Domain Driven Design and Domain Driven Design Quickly, I have also been recommending The Object Primer, by Scott Ambler. I highly recommend his Object Primer and urge you to find some time for it.

What is Object Persistence?

If you are on a project that takes advantage of OOSD techniques, chances are that you also had to worry about storing your domain objects at some point.

When you are dealing with a domain model, business objects working in harmony with other business objects, you will need to deal with Object Persistence sooner rather than later. Object Persistence can be described as a running domain model to survive power failures or power spikes so that no data is lost. Some describe Object Persistence as serializing objects out to the disk and retrieving them later. Serializing an object usually means to store the values of public properties of an object. De-serializing would be just the opposite and retrieve the values and reconstruct the original object back to its original state. Others describe Object Persistence as storing objects into a RDBMS where you will encounter the difficulties of the impedance mismatch between the three dimensional object worlds and flat, two dimensional relational databases equivalent of trying to fit a square into a round hole.

In short, Object Persistence is storing the data, the behavior, and the relationships with other objects for later reuse to output valuable information.

A typical Object Persistence can easily consume 50% – 60% of a project’s resources and time if not handled correctly. This time is not just the initial time when a system is being developed. More importantly, the future maintenance of a system is the most expensive part of a system during its lifetime until retirement. If Object Persistence takes up such a big part, shouldn’t Object Persistence deserve a lot more attention?

There are several ways on how Object Persistence can be done. I will go into some details in future posts. Until then, think about the time and productivity that can be gained through effective Object Persistence and not just during prototyping but full blown production systems. How much time do you usually spend dealing with creating a database schema, creating some layer to store “stuff” into tables, and how much time you spend updating all these parts until the system goes into production. Once in production, how much time do you spend making changes as requirements change? How much plumbing work do you do vs. actually solving the domain problems?

In future blogs, I will post about Object Persistence and why this is so important in software development projects that do utilize OOSD today. I will take ideas from my upcoming book The Abundance of Object Persistence to highlight the importance of this crucial part in system architecture not only from a technical perspective but also from a business point of view. Please feel free to provide any comments or suggestions. I’m looking forward to your feedback.

New Demo

I have found that quite a few people are using my presentation demo as a guide to start new projects. This was not my intention but rather a very simple example on how you could separate the layers and use db4o.

I realize that it is easier to learn by example especially on topics such as design patterns, persistence, layering a system, etc. So, I decided to start working on a new demo. This new demo will show you how you can effectively layer your system, how you can separate your persistence, how you unit test, implement several design patterns etc.

It will definitely help you to get a major head start when starting a new project. Please let me know if you have any ideas or special cases you would like to consider for the demo.

Object Persistence Presentation in Columbia, SC

I will present at the Columbia Enterprise Developers Guild in Columbia, SC on Wednesday, September, 12th, 2007 at 6pm at the Midlands Tech NE Campus Auditorium. I will be presenting db4o as a means to easily persist your objects in .Net. I hope to see you there and enjoy the sugar bus.