My hopes to build entire websites in Flash lasted until 2005 / 2007. But when still nothing substantial had happened regarding SEO, memory management and performance issues in Flash I gave up. Something had not happened in Flash that I had hoped it would. Namely that it would mature into a compatative alternative to plain HTML. That it would become the weapon of choice for richer sites with gorgeous visual story telling (how do you move from “A” to B”?) and rock-solid content rendering.

Adobe and the crisis

I hate to see the results of the communication set out by Adobe in the past week.

People read what they want to read and right now, most people seem to simply read: “The Flash-ship is sinking!”

When filtering out the bottom line from the Adobe posts I read something else. They laid-off 750 people. And laying-off 750 people is not something you do when you are in your peak moment. you lay-off 750 people when your losses are bigger than your profits. Meaning that Adobe might be in a very rough financial weather right now.

And yes: that leads to killing projects as well. Like Flash mobile for browsers.

Between my lines

In the post below, based on a response on Google+ I basically state the following between the lines:

1. HTML5 will open new interest for interactive content and better experiences. This will eventually rub off in a good way in the direction of Flash. Especially when the HTML5 hype takes place for the HTML5 reality
2. If you are good in what you are doing, Flash will very likely become your gold mine in the next years. As HTML5 will not be able to deliver everything a Client might want to communicate and Flash will not disappear as an option. If you are available and skilled, your skills will be even more in demand than before
3. I think Flash might come back with a vengeance. With all the fuzz about HTML5 and the death of Flash, Flash developers who do and did not give up might focus on things that will completely kick HTML5 ass

Building your company on only one technology

Someone on a Google+ stream I hooked into stated yesterday: “I definitely won’t advice anyone to build their business on Flash Platform technologies”

Building a company on just one technology only is smart / only works well when that technology is “new” and “hot” and “wanted” and still in the up-slope movements of the hype. After the peak of that hype, clients in most cases just go for what works best for a specific budget. By then that technology has revealed all its specific shortcomings and has become “nothing exciting” like happened with Flash and Java and any other technology, and most of these companies start expanding their bag of tricks (again).

If you have always relied on only (that) one technology, this might be your wake-up call and your time to learn something new. Which means: always have a plan “B” in your pocket. Times change, whatever you do. Whether it is due to an economical crisis, a specific technology falling out of (temporary) grace or whatever.

Why this current situation is irrelevant

If your client wants something, you simply deliver. If you can not, you try and find a solution.

I started with Visual Basic, moved into HTML and JavaScript and learned to program C#, Java and Flash for those reasons in the past ten years. Because my clients required solutions in these directions, because one market dried up and another emerged. And from each language and environment I learned something new. Right now I earn all my money writing ActionScript and MXML in Flex projects for big companies. Something I could not have predicted six years ago when I started exploring C# to up my market value because I thought by then that Flash had become a personal dead-end.

Instead, my Flash-experience turned out to be very valuable by the companies that started hiring me. As I was able to fix issues their teams were not. Either due to lack of people or due to abandoned projects from mergers.

The hype and the reality of every day

This year, the hype is HTML5. A year from now that hype has been replaced by the everyday reality of projects, budgets, disappointments, quality assurance, bug fixings and the (financial) end result below the line. From there on HTML5 will be just one of the family, old news and one of the many options to go for.

Let’s see

Let’s wait and see how Adobe gets through the next year. Let’s see what Flash player 12 will bring. Let’s see what people will come up with in any and all technologies. Let’s see how these results will cross-pollinate. Let’s see what else will spring up. Let’s see how people like HTML5 a year from now. Let’s see if people will put new love into Flash.

Flash developer? Losing clients? Change your strategy

And yes: if you are a Flash developer, this might be a tough time for you – as budgets that might have gone to Flash development are now going to HTML5 development. This only means that you might have to change your short term strategies and see where the market is to keep up your earnings.

If you are a skilled Flash-developer, you will be probably able to earn even more in the next years than your did until now. It’s not all tablets that counts. HTML5 can not solve all creative requests. And who knows what directions commercial Flash content on tablets will take.

New to Flash? I can imagine you hold back

If you are new to Flash, I can imagine you are holding back to wager your career on something that holds such an uncertain future as Flash does. Will it still be here two years from now? Will Adobe at a certain point drop the ball as a whole?

Will there be any work at all in Flash?

Flash mobile

I kind of do not understand how Adobe AIR for mobile phones will not have the trouble Flash Mobile for the Mobile browser has. In the end, it will have to run on the mobile platform.

Instead of browser-based solutions, Flash Mobile will be AIR-based solutions. (An Adobe Runtime Engine with some extras, that runs as an executable). As I hardly develop for mobile I have no clue what direction Flash mobile will take.

Like everything, this is not the end

Flash is old news. And maybe the whole ruckus about Flash and the possible death and the discontinuation of specific projects (like Flash for mobile browsers) is a huge wake-up call to those who care.

Not a wake-up call to drop the ball. That would be completely stupid. How many plugins are there, capable of what Flash can do? How much time will they need to reach the same coverage? What tells you they will not suffer the same fate?

Maybe this is a wake-up call to put our experience into new action. And the time is not bad.

With Flash 11, Adobe finally solved one of the biggest issues of Flash: that content was rendered over the CPU instead of the GPU. Meaning that whatever you wanted to create in Flash was already crippled by lack of performance and the lack of raw computing power the GPU gives you.

Now those issues are solved, new content will arise in and for Flash that was not possible before and that will not be possible in HTML by far.

I am not that somber about the future of Flash. I think that the entire HTML5 thing will lead to a new and even bigger interest in Flash a year from now than I experienced in the past 5, as HTML5 shows what the potential is of interactive content.

And I would not be surprised to see stuff emerge from the Flash site rendering and using HTML in a way not done before. Challenging the HTML5 movement heads-on from within Flash.

Deep inside the realms of my imagination I see brilliant Flash coders already working on the rise of a new type of Flash content that will blow everything away we knew from the past.

Who knows: Flash might even rise from the alleged ashes as a new bird.

In the past week two messages hit my Twitter stream:

1. Adobe lays off 750 people – See here 
2. Adobe terminates Flash for Mobile – See here

To terminate Flash for mobile browsers in the light of the lay-off seems to me a sane step to cut cost. You drop everything that does not deliver. Even if this something might hold some promise to the future.

As I read the announcements, Adobe will focus (recources for) Mobile Flash development on AIR. Flash for the Desktop will be continued to be supported and developed.

The future (and past) of Flash

The future of Flash is not dependent on the development of HTML5. It depends entirely on Adobe and the vision (or lack of vision) Adobe has with the platform.

To be brief: I believe Flash is taking too much time on fixing structural issues to go into the right direction. When the team finally comes up with GPU powered 3D in the second half of 2010, we have already seen demos of GPU powered 3D in WebKit nightly builds in 2009. Unity3D is already doing an awesome cross-platform job on Windows AND Apple since around 2005 without any of the performance issues Flash seems to have or any trouble to get access to the GPU for native systems: making the excuses Adobe has related to Apple and Flash performance seem rather lame. And Unity is not the first.

All this lagging behind has arrested the development of Flash for, for instance:

1. An abundance of solid online applications – Like Office clones providing basic but good word processing, doing spread sheets and making presentations. Like image editors and creative suites. Like Client Relationship Management tools and whatever you can think of. There are some, like Avary (online image editing) and Buzzword (text processor in Flash) but it could be better. For instance: why is the WYSIWYG text editor I use in environments like WordPress HTML based and not Flash?
2. Full flash websites – I have tried. Several reasons why it did not succueed include performance of text-rendering and scrolling, memory management and – back then – lack of proper solutions for deeplinking and SEO
3. Desktop applications – Everything you do online can also be done offline. Unfortunately, Flash performance also there was a big issue. More than anything else, including the sometimes awkward way to communicate with native stuff like DLLs in Windows

When the Flash Virtual Machine is optimized in 2004 / 2005, it still under-performs related to HTML for content rendering and text rendering, making any site more than animations close to unsellable to the client.

And where are the SEO use cases for Flash? Show me a clear direction from Adobe on how to implement content in a Flash site that is warrented and supported by Google to be included in search results. Other than the half-baked: “Google spiders the content of a Flash movie” which really is no solution at all if you have a lot of content to offer.

All the cases I have met in 2006 and 2007 where companies were contemplating moving to Flash to run their entire corporate sites (including Vodafone and Heineken at that time) are mainly cancelled on these two issues of performance and SEO.

Make Flash 12 something kick-ass. Something that matches HTML rendering in speed and performance. Hell: something that includes HTML rendering and access to the Document Object Model so that I can finally build awesome stuff with a lot of content with existing standards. Something that exceeds the limitations of the Flash implementation. Something that is solid. Something that makes me want to make HTML sites in Flash.

It it not that that HTML rendering technology is so mind-blowingly new. People (including me, with a simplified sub-set) even build their own in Flash since version 5 or 6.

Improve even more the memory management and asset management. Let me brutally kill assets I do not need anymore, instead of making my memory management solely dependent of dependencies and garbage collection. Provide me with a render engine that is capable of dealing with the instantiation of hundred of thousands of objects on stage without even blinking and without taking more memory than absolutely needed. Hard-code specific tricks in C++ or whatever is faster to get the most out of any system for specific actions performed a lot. Make it as good and fast and performing as any game-engine and any 4th generation coding language. Give me brute performance on any level possible in my browsers.

Support development of cool stuff in early stages by inviting people who implement those new things you have not thought of. Like the use of the camera and image processing for AR and QR codes a while ago. Things and that challenge the limitations of Flash and let them help you make Flash better, stronger, faster. Open source your code if that helps. Have people contribute.

Improve Flex. Get rid of the awkwardness that is still in there. Provide me with stuff that matches, equals and overshadow the native components of an OS in performance and reliability.

And please: make a stable version of the Flash IDE. After increasing issues from CS3 on I feel like working in the IDE is like walking in a mine field. Anything can blow at any moment. Even if I tread softly.

The alternative development with all the HTML5 puha is that Flash slowly shifts into obscurity as it becomes less and less relevant due to the massive anti-hype.

You can read the announcement of Microsoft in many ways and if you are biases (as I have noticed in several occasions on my own perception on things in the past) you read what you want to read.

Another storm in a glass of water

The whole discussion is just another storm in a glass of water. Something insignificant blown up to biblical proportions that will – for some peoples hopes – finally be the end of Flash.

Simply put: Flash is not important enough on one side (HTML dominates the web completely) and caters specific solutions for specific needs on the other side where HTML and HTML5 simply (still) can not help you. Unlike HTML, Flash is not hampered by a bunch of old guys defining standards or six different flavors of web browsers who all implement those “standards” in a slightly different way. And so it can choose its own way in what it think is important to introduce and implement as new features. Streaming video, Sockets and the implementation of newer ECMA Script (OOP driven) standards for ActionScript are only three of them.

I deliberately count out the banners done in Flash. Killing Flash will not kill banners and all the ruckus on Flash and HTML 5 will make HTML5- and (the currently relatively processor intensive) Canvas based banners only more likely to happen.

I would do the same

Microsoft has made the choice to focus on HTML 5 alone for Metro. And I think it is a smart choice. Very likely the Metro-framework (if there is one) supports specific basic patterns to do stuff in HTML and JavaScript which support and which are part of the experience of Windows 8 and Metro.

To involve and include other technologies only obfuscates things. It breaks the consistency. It adds extra complications. It is like using Java and C# and Perl all together to create one single solution.

By choosing to go further on their HTML path (allegedly MS started to integrate HTML in their presentation layer with Windows XP) is a simple and clear one.

Too bad if you want to implement Flash stuff in Metro. And very likely you should not want to do that.

Two browsers: Metro and IE 10

Windows 8 will contain two default flavors of web browsers:

1. The “Metro” browser – Based in IE and bsically your main view on Windows 8
2. Internet Explorer 10 – With which you browse the web

Metro does not support Flash

As Microsoft states in “Metro style browsing and plug-in free HTML5 ” here:

In Windows 8, IE 10 is available as a Metro style app and as a desktop app. The desktop app continues to fully support all plug-ins and extensions. The HTML5 and script engines are identical and you can easily switch between the different frame windows if you’d like.

So: Microsoft does NOT drop Flash in Windows 8.

What does happen is that the Metro Browser (see above for a brief on what I understand it is) does not support any plugin, including Silverlight.

[..] the Metro style browser in Windows 8 is as HTML5-only as possible, and plug-in free. The experience that plug-ins provide today is not a good match with Metro style browsing and the modern HTML5 web.

When we check the “plug-in free” link, we find:

Because more and more browsing takes place on an ever wider variety of devices, and browsers on them, more and more consumers are browsing without plug-ins.

And

Lots of Web browsing today happens on devices that simply don’t support plug-ins.

Regarding the choice of plugin free browsing in Metro, two factors are mentioned in the first post

The experience that plug-ins provide today is not a good match with Metro style browsing and the modern HTML5 web. Running Metro style IE plug-in free improves battery life as well as security, reliability, and privacy for consumers.

[...]

Providing compatibility with legacy plug-in technologies would detract from, rather than improve, the consumer experience of browsing in the Metro style UI.

I deliberately removed the self justification stuff about how plugins “were important early on in the web’s history” and “the web has come a long way since then with HTML5″ and “the reality today is that sites are already rapidly engineering for a plug-in free experience”.

IE 10 will support plugins (and Flash) in Windows 8

IE 10 will still support Flash (and other plugins – which are not mentioned, but many) as the Microsoft blog states clearly in “Metro style browsing”:

In Windows 8, IE 10 is available as a Metro style app and as a desktop app. The desktop app continues to fully support all plug-ins and extensions.

Flash

As I have written before in several posts, Flash is a niche-product. You can build entire websites in it (which I have done) but there are several reasons why Flash has not become an HTML killer where it might have been. I mention five:

1. Searchability and SEO – Even though possible (publish the content as XHTML with the Flash main movie and reload the content in Flash) SEO and Flash has never been on the map of Adobe and Macromedia as far as I know.
2. Memory management – Being the real hidden issue of Flash for a long time: Flash used to suck at memory management. A simple Flash site could easily consume 200 MB without you doing anything more than loading some images in some container and effortlessly growing over 1 GB  if you did not do your memory management properly. Imagine having 5 tabs open with each one such a Flash site.
3. Scalability – HTML is scalable to the max. It does not matter if your site is 1 or 1.000.000 pages big. With Flash, again, even though possible, there are only a few people using strategies to make Flash sites “endlessly deep”: able to display thousands of “pages”. Instead, in general Flash sites are developed in the same way as folders and Power Points: each piece of content gets a dedicated “page” which is usually “hard coded” in Flash. In most of these cases, all these “pages” are all plunked into one single SWF file. To follow a different strategy, where assets an congtent are loaded on demand and cleaned up for neatly after use, requires more effort and more experience than the average Flasher has at this point in time.
4. Google Translate – With Google Translate you can translate Russian, Japanese and Chinese sites to something that is almost readable. Flash sites do not allow for this external additional services.
5. Bookmarking and deeplinking – Bookmarking and deeplinking was not supported at all until someone found a solution for Flex and someone else implemented an open source version hacking Hash tags and injecting pseudo-links into the address bar. This meant that you could not store or share content inside a Flash site. Both are still a hack relying on JavaScript to do the job.

Flash itself originally emerged because it was the ultimate Animated Gif killer. Instead of having your animations run in huge pre-baked sequences inside a GIF file, where each next frame would add more weight to the file, Flash allowed you to make animations which were incredibly light weight (in kilobytes), vector based and based on tweening and other neat tricks.

The future of Flash

I think it is a good thing Flash is challenged. I think the HTML 5 hype is a good thing too. There will always be cross-pollination (I think – for instance – that GPU supported 3D in Flash was put on the map once the OpenGL demos in WebKit came to the web).

Flash has become in many ways what HTML could not: a better environment to code and create awesome stuff for the web, running in (almost) the exact way on almost any platform.

Flash lacks a lot at the same time in this department. And I think that is the main reason why it stays in the corner of a niche-product.

Two main reasons – as mentioned above – not to choose Flash as the major technology for sites are still: (good strategies for) scalability and a proper implementation of strategies for SEO.

Adobe fixed some of the major memory management issues in 2010 and it has been a before that fix since I last profiled a Flash site.

As Flash and the future concerns, HTML did not kill Flash, and there will always be a need for specific things that Flash can- and HTML can not do. As is the other way around.

In the end, nothing much will change and if Flash dies, it will be very likely due to stupidity and wrong choices on Flash itself, not because Apple and Windows choose to exclude it from very specific solutions and environments.

Mapping the confusion

And here is what happens when you post something unclear and people read what they want to read.

As stated above, IE 10 under Windows 8 will still support plugins, so read carefully.

From PC World: “Windows 8 Update: The End of Adobe Flash?” here. Bold added by me. The article seem to suggest that if you want to use and see Flash, you need drop the Metro desktop and revert/stick to the traditional desktop.

Nevertheless, the lack of plug-ins and possibly extensions should make IE more responsive and faster when using the Metro UI.

This could also be a huge blow to Adobe, since the Metro-style interface will be the first thing home users see when they fire up Windows 8 on their laptops and desktops. It’s possible that Microsoft could adopt Google’s strategy and build Flash right into IE, but that would technically be using a plug-in and thus not be as plug-in free as Microsoft is promising.

Microsoft’s comments, while they don’t explicitly say this, suggest that Flash will not be included in the Metro-style version of Windows 8. So unless PC users at home reject the Metro-style interface and stick with the traditional desktop in Windows 8 or Windows 7, Microsoft may effectively finish what Apple started and kill Flash on the Web.

You will find echos of this article on many places including here and here.

There is another article in similar fashion, stating at the end that Flash might be really dead now in 3 to 5 years and that Flash developers just as well should abandon the sinking ship that is Flash and go find something else, elsewhere.

Unfortunately I could not find that article anymore.

Lets consider you wrote this code to save files either locally or over a network connection (the values in capitals are Constants used in your code instead of hard coded values):

class MyFile()
{
 // Set our starting position
   var dataState=DATA_STATE_UNCHANGED;
   var fileSaveState=FILE_SAVESTATE_UNSAVED;
 // Store our data
   binaryData:BinaryData=new BinaryData(); 
   public method saveFile()
   {
      if(dataState==DATA_STATE_UNCHANGED)
      {
        MessageCentral.showMessage("File has not changed. No need to save it");
        return;
      }
      if(dataState==DATA_STATE_CHANGED)
      {
        if(fileSaveState==FILE_SAVESTATE_SAVING)
        {
 // We decided to show a message and exit
          MessageCentral.showMessage("Already saving the file now, please try again later");
          return;
        }
        if(locationType==LOCATION_TYPE_REMOTE)
        {
 // Create object and open connection to save it remotely
      fileHander=new FileHandlerRemote();
 // Attempt to save file
          remoteSaveAttemptSuccesful=fileHandler.saveFile(binaryData,location); 
 // Attempt to save
 // Give feedback if save failed
 // Set flag to indicate if we succeeded in our attempt
          saveAttemptSuccesful=remoteSaveAttemptSuccesful;
       }
       if(locationType==LOCATION_TYPE_LOCAL)
       {
 // Open connection to save it locally
         fileHandler=new FileHandlerLocal();
 // Attempt to save
         localSaveAttemptSuccesful=fileHandler.saveFile(binaryData,location);
 // Give feedback if save failed
 // Set flag to indicate if we succeeded in our attempt
         saveAttemptSuccesful=localSaveAttemptSuccesful
      }
 // Done. Now change the state if we failed
      if(saveAttemptSuccesful==false)
      {
 // Make sure we set the right state
        fileSaveState=FILE_SAVESTATE_UNSAVED;
 // Exit
        return;
      }
   }
// We need an event handler when Saving (attempt) is done

   private method onSaveFinished(evt:Event)
   {
   // Here we get feedback from our process  
   // As it is from an asynchronous process, we only know now if it failed or not
      if(evt.success==true)
      {
         fileSaveState=FILE_SAVESTATE_SAVED;
         MessageCentral.showMessage("Your file has been saved");
      }
      if(evt.success==false)
      {
         fileSaveState=FILE_SAVESTATE_UNSAVED;
         MessageCentral.showMessage("Oops! Something went wrong. Your file has not been saved");

      }
 // Done
   }
}

If this was a real world example, we would have handlers for IO errors as well, and be more specific on why stuff went wrong, so the user can correct if possible.

Issues with the If/Then/Else approach

What is “wrong” in this approach is the following:

1. Too much responsibility/things happening in one single place - Many decisions are made and managed in one block of code: saveFile
2. Allows for clutter to happen - The more exceptions you get (captured with If/Then/Elses or Switch vases) the more mess your code will contain.
3. Too rigid/resilient against change - If your pattern changes or new states are added, you will have to add (and change) If/Then/Else statements. This can be a very tough process and can introduce (new) bugs when done improperly or by someone else.

Looking at the parts we have

To continue our review of the code above: we can split the if/then/else in “saveFile” into two main decision making:

1. The save- and data-state of the file – Data is changed/unchanged and the file is saved/unsaved.
2. The way we store the data – Remote or locally. As there is no business logic present for this, for now, we can use a “Simple Factory” to select a handler. There are two advantages to that:
1. Extendability – We can extend the number of possible handlers to any possible number
2. Clean code – We move the (potential) clutter to another class and pass only the known stuff to have it resolved.

The File Handler

The way we store data, can be outsourced to an external class, called – for instance – “FileHandler”.

We will skip this class and assume it is there in the next parts, to keep this example simple.

Using State Pattern - The MyFile State Handlers

Before we start: As we are going to implement multiple Handlers, we need a generic interface. There are several ways to do this, including inheritance of a Interface, extending an Abstract class or extending a Template class.

We use an Interface: As we assume that we do not share any generic code, we use an Interface to allow the application to use all different SavedState Classes as if they are the same thing. An Interface is basically a class with just the definition of the Methods but no code.

Two State Types interacting: We also have two state types interacting with each other and influencing the possible next steps of each other:

1. Changed state – The file  is changed/unchanged/being saved
2. Saved state – The file is saved/unsaved/in the process of being saved

One of the solutions might be to create a state for each combination as we have defined it now. Currently leading to 3 x 3 = 9 different possible states.

State Manager: Instead we do something else: we use a State Manager – introduced later in this example. I explain later the reasoning behind this.

State Handler for unsaved files:

class FileState_UnsavedHandler implements IFileStateHandler
{
    public method saveFile(fileData, location, method, 
                           callBackSuccessful,callBackFailed)
    {
        // The file is unsaved

        // Create a File Handler         
 fileHandler:FileHandler= new FileHandler()
        // Attempt save with passed parameters
        fileHandler.saveFile(binaryData,location, method,
                             callBackSuccessful,callBackFailed)
        // Notify the user
        MessageCentral.showMessage("Attempting to save the file");
        // Return the new state
        return FILE_SAVESTATE_SAVING; 
        // Done
   }
}

State Handler for saved files:

class FileState_SavedHandler implements IFileStateHandler
{
    public method saveFile(fileData, location, method,
                           callBackSuccessful,callBackFailed)
    {
        // Notify the user
        MessageCentral.showMessage("File is already saved, no action taken");
 // Return the state
        return FILE_SAVESTATE_SAVED; 
   }
}

State Handler for files which are in the process of saving:

class FileState_SavingHandler implements IFileStateHandler
{
    public method saveFile(fileData, location, method,
                           callBackSuccessful,callBackFailed)
    {
 // The fileData is already being saved
 // Notify the user
        MessageCentral.showMessage("File is already being saved,   no action taken");
 // Return state
        return FILE_SAVESTATE_SAVING; 
   }
}

What we have so far: We have three basic State Handlers for all three currently defined Saved states. Two are basically doing nothing more than giving feedback to the user. The question that might have arisen in your mind at this point is: what is the use of this?

What we did: We encapsulated different possible scenarios for when the user wants to save stuff into separate classes, which are interchangeable as they all use the same interface.

What this delivers: Clean code and a clear purpose. Later, when your application starts growing and decisions are becoming increasingly complex, encapsulation and separation of State specific actions will help you keep control over the processes that you manage in these classes.

What we do not have yet: We still need to deal with the Changed State.

What we avoided: In many textbook examples you will find:

1. References to the class we handle the State Specific processes for. In our case case that would be the Class: “MyFile”.
2. Direct manipulation of variables on “MyFile” by the State Handlers
3. Interference with other processes. For instance: we could also set the File Changed State to “unchanged” when a file is saved.

This leads to tight coupling and rigid code.

What can go wrong: Each State returns or sets the next state to be executed (including itself, if nothing changed). If we make a mistake in this (for instance stating the new state is “Saved” while we are actually still saving the file), the process will “get lost” or “break” and the application might end up in places we did not intend it to go.

Why you might want to consider the Mediator Pattern: This dependency of “internal decision making per State Handler” and the fragility of the chain is one of the reasons you might want to consider using the Mediator Pattern.

Using a State Manager: Another alternative is using/adding a State Manager to your State Pattern. The State Manager adds the benefits of centralized decision making and centralized sanity checks to the clarity that encapsulation of State Specific responses delivers.

Tight Coupling?: Means that both your: “MyFile” Class and your State Handlers have awareness of each others existence. This might seem OK at the beginning, but can lead to a lot of trouble in later stadia of your code. Your code and your solutions to a problem should be disposable. I will explain in the next blocks why.

Rigid code: Meaning that one specific type of solution is hardcoded into many places, leading to a lot of trouble if we want to discard of it.

Avoiding three issues: Adding The State Manager to the equasion

Purpose of the State Manager: As our decision making process covers two State Types (Changed and Saved) we might want a Manager to deal with the potential complexity that arises from managing the different states in different combinations.

What it solves: We have three issues when dealing with the State Pattern:

1. Are we still doing the right thing? – The State Manager can execute sanity checks on States which are centralized. These sanity checks can help you avoid entering the wrong state when specific Exceptions occur.
2. How do we deal with dependencies between mixed State Types? – Like the possibility of having any combination of: “Saved State” and: “Changed State” in our example, already leading to 9 different possible combined States. State Handlers are relatively single minded. And the purpose of a State Handler is to replace If/Then/Else constructions by encapsulating specific responses to specific states in specific classes.
3. How do we decouple our State Handlers from the “MyFile” Class? – Tight Coupling of a solution to the Class that requires that solution generates a lot of problems when change is required. We rather decouple the State Handlers from the “MyFile” Class, to become more Agile in our solution.

Here we go:

class FileStateManager
{
   // Define the variables to keep our state
   var savedState:String=FILE_SAVESTATE_SAVED;
   var changedState:String=DATA_STATE_UNCHANGED;
 // Mappings
   fileStateHandlers  ictionary<String,IFileStateHandler>=
            new Dictionary<String,IFileStateHandler>()
   changedStateHandlers  ictionary<String,IChangedStateHandler>=
            new Dictionary<String,IDataStateHandler>()
   public method init()
   {
 // Did we already do this?
      if(fileStateHandlers.length>0)
      { 
 // Already done
        return;
      }
 // Map it!
      fileStateHandlers[FILE_SAVESTATE_UNSAVED]=new FileState_UnsavedHandler();
      fileStateHandlers[FILE_SAVESTATE_SAVED]=new FileState_SavedHandler();
      fileStateHandlers[FILE_SAVESTATE_SAVING]=new FileState_SavingHandler();
      changedStateHandlers[DATA_STATE_CHANGED]=new DataState_ChangedHandler();
      changedStateHandlers[DATA_STATE_SAVEATTEMPT]=new DataState_SaveAttempt();
      changedStateHandlers[DATA_STATE_UNCHANGED]=new DataState_UnchangedHandler();

   }
// Handle edit event from Class "MyFile"
   public method changeEventHandler(evt:Event)
   {
 // Get the handler
  var handler:IChangedStateHandler=changedStateHandlers[this.changedState];
 // Perform the actions required and return our new state
  this.changedState=handler.handleEdit(evt.data);
 // Handle busines logic when file is changed and was saved
 if(this.savedState==FILE_SAVEDSTATE_SAVED && this.changedState==DATA_STATE_CHANGED)
     {
 // Data State is changed and no longer "saved"
        this.savedState=FILE_SAVEDSTATE_UNSAVED;
      }
   } 
// Handle call to save file
   public method saveFile(fileData, method,
                          callBackSuccessful,callBackFailed)
   {
  // Get the handler
      var handler:IFileStateHandler=fileStateHandlers[this.savedState];
      // Perform the action
      this.savedState=handler.saveFile(fileData, method, this.changedState
                       saveSuccesfulCallback, saveFailedCallback) 
      // We deal with the changed state when we get the call back
 // Make sure we reflect the save state for data too
      if(this.savedState==FILE_SAVEDSTATE_SAVING)
      {
         this.changedState=DATA_STATE_SAVEATTEMPT;
      }
   }
   private method saveSuccessfulCallback(evt:Event)
   {
      // Save is succesful, we can set our state to saved
      this.savedState=FILE_SAVEDSTATE_SAVED;

 // If the data has not changed in the meantime we can set it to unchanged
      if(this.changedState==DATA_STATE_SAVEATTEMPT)
      {
         this.changedState=DATA_STATE_UNCHANGED; 
      } 
 // In all other cases, the data either is unchanged
 // or new changes were made after our save-attempt
   }
}

What we have: We now have a simple State Manager to manage the dependencies of our two different state types.

All our decision making is externalized in interchangeable classes which we can expand as much as we want, without making our central State Management.

If we want to implement a different process or different rules to manage the responses of our application to the state of a file, we can simply replace this manager for another that implements that process or those (new) rules.

Did we really win something? We started with a simple If/Then/Else solution where we solved this in maybe 20 lines of code and ended up with more than six classes and a hell of a lot more than those six lines of code.

What we won with the State Manager: Three things:

1. Centralized decision making on mixed states – We decoupled all decision making on mixed states from the State Handlers, so that they can focus on their main task: handling one specific state
2. One single point of entry – for our “MyFile” Class to have its States handled and managed.
3. Disposable solution – Which is easy to replace by something completely new and improved.

Revisiting the “MyFile” Class

class MyFile()
{
 // Get a File State Manager for this file
   var stateManager:FileStateManager=new FileStateManager();

 // File data
   var binaryData:BinaryArray=new BinaryArray(); 
   // Constructor
   public MyFile()
   {
 // Add an eventlistener and bind it to the stateManager   // (to keep the example simple)
     binaryData.onChange=stateManager.changeEventHandler;
   }
   public method saveFile(method)
   {
 // We now have a manager to save our file:
 // dealing with any possible reaction to any
 // of our possible strategies and States
      stateManager.saveFile(this.binaryData, method)

 // "Method" is either stating to save it Remote or Local
   }

}

What we have: We now have a simplified Class: “MyFile”. Its purpose has become more clear as  all our decision making and action code has moved elsewhere.

What we won: Our code in the “MyFile” class is incredibly clean.

We can now easily switch from one State Manager to another, allowing us to completely revise our strategy in solving things and saving files, for instance when the requirements change from:

1. Blocking state - Files can not be edited while being saved.

[Removed from other post - requires editing] If you take the code example from “Design Patterns for Dummies”, “Design Patterns” or “C# Design Patterns” and many other resources you will find by default a Switch statement like this:

// The default Switch Statement you find in a lot of code (examples)
Switch ( myValue)
{
   case  SOME_CONSTANT1:
      // Do something if this condition is met
      break;
   case SOME_CONSTANT2:
      // Do something else
      break; 
      // and so on...
   default:
      // capture when no condition is met
}

Or an if/then construction

// Your run of the mill if/then else if you do not switch
if(myValue==SOME_CONSTANT1)
{
   // Do something
}
if(myValue==SOME_CONSTANT2)
{
   // Do something else
}

Instead I (started to consistently) use the following:

// map whatever you want to do on a specific value
public method mapActionToValue(method:Method, myValue:String)
{
   // Map action to value, which is in most cases a constant 
   actionToValueLookopTable[myValue]=method; 
}
// Execute the action we need
public method actOnSpecificConstantValue(myConstantValue:String)
{
   // get the method we mapped to the value
   var myMappedMethod:Method = actionToValueLookupTable[myConstantValue];
   // Exit gracefully if we have no method (or throw an exception)
   if(myMappedMethod==null)
   {
       return "";
   } 
   // Execute the action - internally we know how
   var myReturnValue:String = myMappedMethod() ;
   // Return the result
   return myReturnValue; 
}

The code above is simplified. One thing missing for instance are the sanity checks to assure that the injection and retrieval are not crashing the application due to illegal actions which a specific language does not allow.

Mapping objects, classes and methods

The example above maps Methods to Constants. You are not limited to that, however in most languages. Java, JavaScript, ActionScript and C# allow you to map the following:

1. References to methods - Allowing you to invoke these methods later, provided that you use the proper number and types of parameters. The reason to avoid this is that you obscure the methods themselves. In contradiction to Objects, you can not always explicitly state what “type” of method you get back from your map.
2. References to objects - Allowing you to prepare a set of Handlers which deal with the context-specific requests, as we did with our example above.
3. References to classes - Allowing you to create new objects based on the class, or invoke static methods.

When mapping is a better approach

The Mediator and State Pattern

This post will focus on the Mediator and State Pattern and provides you a brief overview of the similarities and differences in use and approach.

To improve some of the shortcomings of the State Pattern (centralized management of State) I also briefly go into two different additonal “patterns” called the: “State Maanger” and: “State Machine”.

Next posts

Next posts will go into the Strategy and (Simple Factory) and the Builder and Interpreter and Decorator Patterns.

Overview

I separate the patterns “to get things done” in three different groups, based on the use. A fourth group contains supporting patterns that help you refine specific strategies in the first three categories.

Each of the first three groups are patterns to offer you a context specific and dynamic way to deal with specific situations. It allows you to move from “single option processing” to “multiple option processing”:

1. How do you want to manage and handle (user/system based) actions? – Depending on the state of (a part of) your application, the type of response to a specific action changes. A simple example: when you are saving a file, pressing “Save” again should result in no action at all.
1. Mediator Pattern - Use when you need to manage complex processes. Can be used as an logical alternative for a State Pattern.
2. State Pattern – Use when the behavior of (a part of) your application changes based on the state (of a part of) your application.
2. How do you want to process stuff? - Where the Mediator and State Pattern are used to “manage” processes based on (business) logic, Strategy and (Simple) Factory are mostly used to offer dynamic ways to handle stuff and produce context-specific objects.
1.  Strategy Pattern – Use when you have several ways to solve one problem (your strategy) and you want an easy way to choose that strategy dynamically
2. (Simple) Factory – Use when you want to create specific objects of a specific type. The (Simple) Factory is/seems very similar to the Strategy Pattern, with this different: the intention of the Strategy Pattern is to select one out of multiple ways (strategies) to solve a problem.
3. How do you want to construct (composite) objects? - The area where I find most use of the Builder and Interpreter Pattern is in building dynamic/configurable Graphical User Interfaces based on XML input. Each GUI is in the basis a Composite of nested objects (Forms, containing fields, buttons and checkboxes for instance). Using a Builder or Interpreter and (XML) input allows you to “inject” any GUI you want and need.
1. Builder Pattern – The Builder Pattern creates a dynamic (object) model based on rules or fixed patterns. It is most similar to a kid using LEGO.
2. Interpreter Pattern – Uses clear text instructions as a basis to construct composite objects or handle data in specific ways. Parsing HTML code into a working web page can be a simple example of an Interpreter.
4. Supporting patterns
1. Decorator Pattern – Encapsulates objects to extend their possibilities. While on the edge of: “does it really belong in this list?”, the way you can use the Decorator Pattern says “yes”.
2. Composite Pattern – In the context of this series I consider the Composite Pattern as a possible tool for two other Patterns: Interpreter and Builder Pattern.
3. State Machine – The State Machine (see this WikiPedia entry on the software implementation) can help you fix one of the possible weaknesses (depending on your implementation) of the State Pattern: that management and state changes are localized in each State Handler in the State Pattern

Mapping it

Result and Object based

What do you need: Results or Objects? – a separation

Changing the color of your screen – a simple use case for a code example

Lets say you have a button that flips the color of your screen through three different colors in a fixed sequence:

1. From Red
2. To Green
3. To Blue
4. To Red again (and the cycle repeats)

Each color presented can be seen as a “state”.

Let’s assume further that each State has a very specific next step. I can only move from Red to Green to Blue to Red.

Using the State Pattern – localizing decision making in State Handlers

In the State Pattern, each State is represented in a specific object, that holds all logic and data for that specific state.

For instance (pseudo-code):

class ColorState
{     
      // We inject the next state via the Environment
      public var nextState: ColorState;
      private var environment:Environment;
      private var color:uint;
      public method ColorState(environment, color)
      {
            // Set environment. so we can pass next state
            this.environment=environment;
            // set Color
            this.color=color
      }
      public method setColor()
      {
              environment.backgroundColor=this.color;
             // Inject next state so next time the user presses button,
             // the next state will handle the color
              environment.state=this.nextState;
      }
}

Our main Class might look something like this:

class Environment
{
       private var redState, greenState, blueState : ColorState;
       private var currentState :ColorState; 
       public Environment()
       { 
              // Define the states
              blueState=new ColorState (this,#0000ff);
              redState=new ColorState(this,#ff0000); 
              greenState=new ColorState(this,#00ff00);
              // Define the next state - this is to illustrate
              blueState.nextState=redState;
              redState.nextState= greenState;
              greenState.nextState=blueState; 
              // Set current state - this will set the color and inject the next state
              currentState =blueState
              // Activate the state to start the process
              state.setColor();
              // Set the button click handler
              colorChangeButton.onClick=onButtonClick; 
       }
       public method onButtonClick(evt:Event)
       {
               // As our state objects deal with all state specific administration,
               // we just call the method and trust our State Object to deal with the rest
               currentState.setColor();
               // Done
         }
}

In this very simple example we define the different states when we initialize the Environment.

Each time the user clicks the Color Change Button, the State Objects will determine what to do on a specific method call (in our case only one) and if a new state needs to be injected.

In this example we also used only one class for our State Object, as we only needed to do two things:

1. Inject the next state – Into our Environment
2. Change the color – Of our screen

Two things I do not like on this textbook example

1. We have a double reference between Environment and the State Handler – The State Handler references to the Environment and the Environment references to a (the current) State Handler. Which is a form of tight coupling that can be avoided and when avoided leads to cleaner and more agile code.
2. We store (a part of) the State of the Environment in the Environment itself - Which seems OK when it is only one state per Environment. Unfortunately, things are seldom that simple. In practice, this approach leads to an increasing mess when more and more states for specific situations (think of specific states hiding and showing specific buttons) are added. Better is to externalize all state-specific stuff to a separate class that then manages the object you manage the state of. See: “Using State Machines” further down this post.

The Mediator Pattern – centralizing decision making

The Mediator Pattern follows a (completely) different approach to deal with issues. Where the State Pattern allows for decentralized management, the Mediator Pattern centralizes that decision making into one place.

Lets look at our color-example.

class ColorMediator
{
   private var environment:Environment;
   private var colorHandlerList:Dictionary<string,ColorHandler>=new Dictionary<string,ColorHandler>(); 
  // As we want to keep full control we keep the state internal
   public var currentColorHandler;
   public ColorMediator(environment: Environment) 
   {
       // Set environment
       this.environment=environment;
   }
   public injectColorHandler(fromColorHandler, toColorHandler) 
   {
     // We simplify management in this example by using a lookup table
      colorHandlerList.add(fromColorHandler.color, toColorHandler);
   }
   public method init()
   {
      // We activate the current handler
      this.currentColorHandler.go();
   } 
   public method setNextColor()
   {
      // One of the options to manage/mediate is to supply the information
      //  we need to decide which next color/handler to use
      // As we use a lookup table, we can avoid the dreaded Switch statements
      // you normally see in an example like this.
      var nextColorHandler:ColorHandler= colorHandlerList[this.currentColorHandler];
      if(nextColorHandler==null)
      {
         // OOPS! you configured the color sequence wrongly
         // As this is a Mediator, you can choose to solve this by offering an alternative path
          nextColorHandler = colorHandlerList.Values[0]; // get first value
       }
       // Active the next color handler and set the color on the environment
       nextColorHandler.go(this.environment);
   }
}

There is a lot of things to say about this approach. I limit myself to 9 points:

1. This is a very simple Mediator – When your application grows, more and more business rules will pop up in your application. Those situations are out of scope of this post, but will be clarified in a later post.
2. We map the next Color Handler in a Lookup Table – Against the previous Color. This is a neat trick Dictionaries allow you to do. We could also have used the Color Handler itself, but that felt less clean.
3. Do not fixate on this solution – There are many ways to write a (simple) Mediator and this is only one of them.
4. I assume the colorHandlerList has values – Which is very naive. The code should first check if there are any values in the color Handler List.
5. The color manager only knows one direction – Which is forward. It might also be allowed to branch on specific conditions, or move backwards.
6. If you want to be able to navigate colors in more directions, discard this approach – Or the mapping issues it creates will drive you nuts
7. I inject the Environment into the Color Handler – Which reduces depencencies and makes the Color Handler a neutral object, only required to deal with its internal stuff.
8. I no longer keep State in the Environment – Which is smart if your application becomes more and more complex. The Environment can become a dumb object with just one simple task. All (state) management is done in your mediator.
9. We now need 3 classes instead of 2 – As the management part is now externalized and centralized in the Color Mediator Class

class ColorHandler
{
     private var color;
     public ColorHandler(color) 
     {
             // Store the color
             this.color = color;
     }
     public go(environment:Environment)
     {
             // Set the stored color on the given environment
             environment.backgroundColor=this.color;
             // Done
      }
}

class Environment
{
   private var redHandler, greeHandler, blueHandler : ColorHandler;
   // Removed: private var currentState :ColorState;
 // Added  private var mediator: ColorMediator=new ColorMediator()
   public Environment()
   { 
      // Define the handlers
       blueHandler=new ColorHandler (#0000ff);
       redHandler=new ColorHandler(#ff0000); 
       greenHandler=new ColorHandler(#00ff00);
       // Add them to the Mediator, with "from" color and "to" color handler 
      mediator.injectColorHandler(redHandler,greenHandler);
       mediator.injectColorHandler(greenHandler, blueHandler);
       mediator.injectColorHandler(blueHandler, redHandler);

       // Set current state - this will set the color and inject the next state
       mediator.currentColorHandler =blueHandler

       // Activate the state to start the process
       mediator.init();
       // Set the button click handler
       colorChangeButton.onClick=onButtonClick; 
   }
   public method onButtonClick(evt:Event)
   {
        // As our mediator deals with all state specific administration,
       // we just call the method and trust our mediator to deal with the rest
        mediator.setNextColor();
       // Done
    }
}

Both Mediator and State externalize and encapsulate the logic to deal with context-specific (user) actions.

Three main benefits of the Mediator – in this example

This delivers you a series of benefits of which I name 3:

1. Cleaner code – Instead of having a Environment Class with a load of code dealing with each specific state (the colors) we now have State Handlers and/ore Color Handlers and a Mediator to deal with this
2. Agilitiy – As you externalized and encapsulated the decision making logic, your code becomes more agile. Meaning that if you want to try a different approach to your decision making process, you simply create a new or different set of State Handlers and/or Mediators which you can plug in and remove to your own liking
3. More stable code base and less errors due to mess – As each Handler (should have) a clear purpose, changes are either an improvement on existing code, or done in a new class that (possibly) extends your current code. This allows for code changes and changes of mind to be isolated and reversible. – If you do not like solution “Y” in Class “Z”, you simply use solution “A” in Class “B” instead. As your code stays clean, the risk of messing up code that worked well previously is reduced as well.

Where I do things differently – using Maps to cancel out Switch statements

You might have noticed my use of a Dictionary in the Mediator and injection of Handlers using mediator.inectHandler. If you take the code example from “Design Patterns for Dummies”, “Design Patterns” or “C# Design Patterns” and many other resources you will find in examples like the one above (almost by default) a Switch statement like this:

// The default Switch Statement you find in a lot of code (examples)
Switch ( myValue)
{
   case  SOME_CONSTANT1:
      // Do something if this condition is met
      break;
   case SOME_CONSTANT2:
      // Do something else  break; 
   // and so on...
   default:
      // capture when no condition is met
}

This seems quite harmless and – as many people and many authors of books on coding use it and – completely OK.

Think twice. Think clean code. Think of what is happening here: using hardcoded references to map events or objects to return specific values or perform specific actions.

See the specific post on “Using Maps to Cancel out Switch Statements” for more information on mapping objects, classes and methods to values and constants.

Using State Machines

One weakness of the implementation of the State Pattern as shown above is – as mentioned in the brief on the Mediator Pattern – is that the State of (a part of) the application is set in the Environment the State Handler controls. The more State variables you will have to remember for a specific Environment (think of tabs hiding and showing specific content, buttons and (text) fields being shown and hidden in specific states, and so on) the more your Environment becomes cluttered with variables you might want to manage somewhere else. (Think MVC here, where the View is just presenting data and has no awareness of any State it might be in)

Another weakness is that the State Handlers themselves hold references to the Environment.

When you start refactoring your project, this entanglement of objects might be something you want to clean up and/or get rid of. For this purpose you can use a State Machine.

The State Machine lives between the Environment and your State Handlers. It is the proxy between your Controller (in an MVC situation) your State Handlers and your View. Any reference to any object is managed by the State Machine and when any State Handler wants to switch states and show or hide elements (for instance) it invokes a method on the State Machine, which will do the actual work on the actual objects.

This decoupling makes your State Handlers more versitile and more re-usable.

Think for instance of generic Application Wide State Handlers which take care of  showing and hiding data and specific visual elements when a User is logged in or just visiting as a Guest.

I read four books recently, including “Design patterns” by the Gang of Four (referred to as “Design Patterns”, “Design Patterns for Dummies” by Steve Holzner, “C# Design Patterns” by Judith Bisshop and “ActionScript 3.0 Design Patterns” by William Sanders and Chandima Camarantunge.

“Design Patterns” by the Gang of Four is the must have book for reference. If you are in doubt, or confused, go back to that one. “Design Patterns for Dummies” is the must have book to start with. I read them parallel and switched from one to the other to check accuracy on “..dummies” and decipher the meanings of cryptic writings in “Design Patterns”.

I am not an Design Pattern expert

I am a coder, a programmer and a software designer. I have written several frameworks for my own use, allowing me to re-use specific tricks and solutions I implemented before, while avoiding Copy & Paste.

One of the main flaws in most of my frameworks was the lack of clean coding and a proper understanding of standards. Either due to lack of experience or due to lack of time.

Refactoring, Clean Code and Distribution of Responsibility

From over 15 years of programming experience my main tools to get to stable and solid code (as you will find in this post) are (and have become) Refactoring, Clean Code and Distribution of Responsibility.

Why this series on Design Patterns?

As I am working on two new Open Sourced frameworks, which are both completely rewritten revisions of older versions, Design Patterns and a proper understanding of Design Patterns have become increasingly important to me, to avoid stupid solutions and to allow others to get a better grip and a better point of entry on what I have done.

In a series of articles in FlashWorks I will explore the main Design Patterns as described in “Design Patterns” from a practical point of view: “I want this, what pattern is most suited?”

These articles are part of my own learning process to start mastering the Design Patterns which are there and which are most useful for my own use. Either to avoid or use them properly where they fit.

Why I warn so much “against” Design Patterns

As I have encountered several people in the past who claimed that Design Patterns were the start and beginning of all bliss in awesome coding, I give you a lot of warnings in this post, related to that point of view, as I have seen the bad side (and sometimes very bad coding) of that single minded attitude in projects I cleaned up: after the original team had abandoned it for whatever reasons (including lay-offs due to company restructurings).

Why Design Patterns are hard to begin with

I personally found three main reasons:

1. First encounter of patterns? Cryptic writings – Design patterns are (refactored) abstractions of recurring themes. The goal is to open that description as much as possible, so that the use is not limited to one single case. If we would apply that to a glass of water, the glass could become: “a container for fluids, made of several possible materials” – as we do not want to limit to a glass alone – “shaped to be held in a human hand” – as it is for human use – “for which one of the uses” – as we can use a glass also for other purposes – “is to move fluids from the container to the mouth”
2. Contradictions,  white noise and limited views – Any writing on design patterns should be concise, clear and as open minded as possible. There are many ways to implement a design pattern, without breaking it. It is possible the writer of a book on design patterns focuses only on a few of those, lacks deeper experience, was battling the deadline or is a very linear thinker (all leading to limited views).  And there are many ways to misunderstand a design pattern (leading to contradictions). Anything that makes stuff even more complicated and that creates more work to decipher the real intents of the examples (white noise) is not helping but driving you further away from your goal.
3. Hard to map with reality - When you are coding, you write code. You are solving several problems using methods, objects and specific tricks you know from your past. While your code is going somewhere, it is probably not following the rules of any design pattern. When you read design patterns it is hard to twist your minde around and find out which one applies and which one should apply.

Refactoring, code organization and design patterns

When you read “Design Patterns”, one of the things mentioned in the introduction is that: design patterns are an emerging result of your coding. This is very important to understand.

Design Patterns are – and should – never be a starting point.

Why design patterns should never be a starting point

When you build software, at a certain point you will start building (managed) lists of objects.

You might even have one or more managers taking care of this.

For instance:

1. Person – Is a Value Object (VO) containing a person.
2. PeopleManager – Is a manager containing a List of people (List<People> in C#)

So far nothing is wrong as there are two clearly paired Classes.

But what if you create a third object called “Department” with a manager?

1. Department – Contains a list of people (List<People>)
2. DepartmentManager – Contains methods to find out which person is in what department

Here comes the catch

What if you remove/delete a person?

Since you now have two lists with people (in PeopleManager and Department) you will have to remove that person from two places. And this is only a simple example.

What we can learn from data models

When you create a database, the database data model deals in a different way with dependencies than we are used in Object Oriented Programming (OOP).

The main reason is to keep data management simple and prevent data from becoming inconsistent.

If there is a One to Many relationship between Department and Person, the link is created in Person, by adding a departmentID. Department will not have a list of people, but will query Person to see who is referring to its ID. (query=”SELECT * FROM person WHERE departmentID = “+ this.departmentID)

In OO (Object Oriented) environments, it might be tempting to insert the Department Object into a person, but again management of data consistancy might become troublesome. My preference is to refer to a Department via a String or Integer value.

Review

1. We add a department of type Department to the person: person.department
2. We add a (static) method to PeopleManager: List<People> getPeopleInDepartment(Department department)
1. This (static) method will go through the People list and extract all people in the Department.

All management regarding people will be done in PeopleManager.

This might seem counter-intuitive. But once you start refactoring, distributed dependencies to specific data and objects will start to break you up.

The goal: simplifying your project

I have noticed that the most common models for events only work for small projects. The moment you start something big, these models become a problem.

1. Boilerplate code – They force you to create a lot of boiler plate code, just to make it work within that (limited and usually rigid) model
2. Loss of control – When your project grows, it becomes less and less clear what happens where and why specific updates you KNOW happened in some object are not reflected elsewhere.

Events

Another issue with the classic approach are Events.

When I update an object somewhere, and this information is required elsewhere, I usually shoutcast an Event: “My object has been updated!”. Attached to the event is the object or object list I changed.

With persistant Objects I can simplify the Event Model thoroughly.

Take this example:

// Some code on Class "A"
Person myPerson = Person.getPerson(12);
// Add observer that will take action when this specific person 
// is updated. For instance: when presented in a list
myPerson.addUpdateObserver(myUpdateHandler)

// Some code in class "B"
Person myPerson = Person.getPerson(12);
// Change some values
myPerson.firstName="Joe";
myPerson.dispatchUpdateEvent();

All observers on Person with ID 12 will now automatically receive a dispatched event and will be able to take action.

As you also might want to observe global events on Person, it is not too hard to create a global, static Event Dispatcher on Person. So when a global observer is attached to the Person Class, that observer will also be informed of any change.

// Using a global event listener
Person.addGlobalUpdateObserver(myGlobalPersonUpdateHandler)

All events are created behind the scenes and can be default events, dispatched over local Dispatchers. This way, the dispatched events never leave the scope of the Object or Class. Naturally all observers are registered against the local Dispatcher as well.

Moving it one step further: cutting all dependencies

You probably know the concept of multitons and Object Pools.

Multitons and Objects in Object Pools are objects with a specific ID or state, addressed through a static method.

For instance on ID:

string personID=12;
// Get the person
Person person = Person.getPerson(personID)

Or state:

List<Person> people = Person.getDeletedPeople(); 
// Where getDeletedPeople will return the objects in the pool flagged as "deleted".

What we do is get an instance of a specific Person object and put it in a temporary variable.

Regardless where we are in our project, when we call for a person with ID 12, we will always get the same object.

Lookup tables

The main trick is to register objects against a Lookup Table. For a Person that Lookup table might be indexed against the Person ID. For a Deaprtment, that might be a Department ID.

// A C# lookup table
Dictionary<int, Person> peopleList = new Dictionary<int, Person>();
// Getting a person
public Person getPerson(int personID)
{
     // For simplicity sake we left out the check if the person is really there
     return peopleList[personID]
}

If you want to find a list of people in a Department, you can do the following:

// Getting people in a department
public List<People> getPeopleInDepartment(Department department)
{
      List<People> peopleInDepartment = new List<People>();
      // Loop through all people
      foreach (Person person in peopleList)
      {
           if(person.department == department)
           {
                   peopleInDepartment.Add(person);
            }
    }
    return peopleInDepartment;
}

Benefits

1. Dependencies to objects are temporary – You are not maintaining persistent references to multiple objects on multiple places.
2. Garbage collection is more reliable - As your persistant references are only on one place: the Class or Class Manager, releasing references only have to be done at one place.
3. Simplified code – I found that at a certain point I was shipping shitloads of object references through all kind of chains of objects and method calls, to have it end up at the right place. Currently the only thing I ship are String and Int values representing the ID of an object. And in most cases If a store and object in class “A” and need to retrieve it in class “C”, I simply use a specific static method on the Class itself: “someClass.getObjectListBasedOnSomeParameters(parameterA, parameterB)“
4. Increase in application stability – As your maintenance of objects is done centrally and managed in one object, strange stuff and lost objects are less likely to happen
5. Increase in code stability when refactoring – Another reason for me to drop the classic approach was that my code tended to break a lot when refactoring. While the compiler had all flags on green, parts of my application simply did not work anymore due to some broken dependency.

Disadvantages

1. Performance – The main disadvantage of lookup tables is performance. Each time you loop, you pay.

Concluding

From OOP principles it might seem counter-intuitive to manage Objects in the Objects themselves (or in a specific and paired Object Manager) and only use temporary references.

The advantages of lookup tables and centralized/localized object management become clear and increasingly bigger when:

1. You do a lot of refactoring – As you will take apart your code, move parts elsewhere and so on.
2. Your project becomes increasingly complex – Querying objects where you need them becomes more beneficial than sending lists of objects from somewhere and hoping that the right lists arrive at the right place though chains of objects and method calls.
3. You use persistent data and persistent objects – As any and multiple objects can contain “Joe Bloggs, ID =2″, using centralized lookup lists and object management assures that when you update “Joe Bloggs, ID=2″ ALL objects representing “Joe Bbloggs, ID = 2″ are updated.
4. Your event model starts to work against you – Events are usually linked to objects. The more granular your event model becomers, the more event types you will have to maintain to keep things up to date and the more bloated your code becomes. The event: PersonEvent(“A person has been updated”) with the specific object attached is less clear than person.dispatchUpdatedEvent(); where only all specific listeners to that object and that class will receive that event dispatch.

Refactoring or Core Refactoring is a process in which code and the organization of code and classes are restructured, to:

1. Increase clarity – As a project grows, code can become more and more messy, as chosen paths changes and solutions that once were sufficient had to be expanded or changed as a whole.
2. Remove redundancy – Like checks and double checks on specific values, or repetition of code.
3. Remove dead code – During the process of change, dead code will remain. In general dead code is code not removed “because it might become useful someday” or “because we do not know what it does exactly”
4. Reduce complexity – Sometimes a specific solution seems to be the best at that time, but in time grows into a Kafka-eske structure of over-complication.
5. Assure application stability – Unclear processes, redundant code, dead code and unneeded complexity lead to an increase of potential places where the code can fail.

Not only for Agile

Why and when code becomes messy

There are several reasons. I will try to list a complete list of the most common reasons here:

1. More than one person is involved – As soon as two or more codes are working on the same code base, different approaches will be introduced to solve a problem, name variables and using design patterns. Each will lead to increasingly messy code.
2. Requirements change – With each functional change, code has to change. And usually changes on several places. Each change introduces small pieces of messy code, which – if not cleaned up from time to time – leads to messy code.
3. Understanding of requirements change – As your understanding of requirements grow, it might be that your initial approach is not covering it and needs to be revised or even completely redone. The size and impact of the changes also determines the size of the mess left behind.
4. Requirements are misunderstood – See: “understaning of requirements change”. The impact of the code changes when requirements change is usually deep. usually existing code is re-used or bent into the new direction, as that seems a more sane solution at that point than simply throwing the old code away.
5. Code for another purpose is re-used for something else – See: “Requirements are misunderstood”. When starting it seems logical to use “A” for “B” as they follow similar processes and re-use is preferred before starting from scratch. This usually leads to messy code.
6. Bug fixes and patches are stacked onto bug fixes and patches – As fixes continue, they will overlap other fixes and patches. Introducing more mess
7. Programmers have no clue what they are doing – Proper and clean coding takes experience. Understanding OOP takes even more time and experience. In most cases, coders do what they can do to solve a problem to their best knowledge. This can lead to a lot of messy code that HAS to be refactored.
8. Refactoring is postponed indefinitely due to fear or lazyness – The fear can be : “If we refactor now, we might not make the deadline”. Lazyness can be: “I want to finish this and will fix the mess some day later”.

The negative impact of refactoring

Refactoring hase some negative impacts for the short term:

1. It blocks progress – As long as code is refactored, no new things can be done. Everyone who is not refactoring has to wait until refactoring (on their part) is done.
2. It breaks the project – During the process of refactoring, the code and the project is broken as things are moved around and exctracted and replaced into other parts of the code.
3. It takes time – A refactoring can take from 3 hours to 3 days and 3 weeks. During that period, no progress is made, except from the code being cleaned up.
4. It can impact negatively on the deadline – As it takes time to refactor, a deadline might be missed due to it.

The negative impact of not refactoring

1. Code becomes increasingly messy – To the point where it is no longer maintainable.
2. Code becomes increasingly overly complicated – Due to entanglements of dependencies that should not be there. Straight lines become messy and wobbly. Processes that can be handled in three steps in one or two classes are done in five ore more, over three or more objects.
3. More and more strange bugs and strange behavior are introduced – As code becomes more messy, it becomes more and more unclear who does what and what happens where.
4. Bugs that were solved start re-appearing over and over – More mess means it is easier to lose stuff and undo stuff that was fixed for specific situations as it is unclear what it does and what it is meant to do.
5. Changes and change request take more and mote time – Due to the increased complexity and increased entanglement of dependecies in the messy code.

Why you MUST clean up messy code

1. On the long run messy code jeopardises your project – The more mess, the more entanglements of dependencies, the more steps needed to fulfill a process, the bigger the chance your code will work against you by:
1. Breaking down on you – Due to bugs and strange side effects of messy code
2. Halting progess – Due to the increased amount of time it takes to find and implement a solution
3. Blocking any new development – As the old code has become so big and messy that any big change will break the entire project
2. Messy code slows down progress – Imagine a house full of boxes you have to move aside every time you want to move from “A” to “B”. That is what coding in messy code is like. The more mess, the more time you will waste just dealing with that mess.
3. Messy code becomes unmanageable - Any change, any improvement, any new person joining the team will have increased costs, to the point where that cost is larger than the benefits.
4. Messy code creates (unwanted) dependencies on a specific set of people – If “A”, “B” and “C” are the only ones understanding what is going on inside the code, the project becomes dependent of them. Clean code makes people replaceable as clean code is easier to understand by others. This is mostly crucial when people will be bound to a project for only a limited time, or people leave for another job at another company.

When to refactor

Here is the base-list of what I started doing for just such a project in Flex in the past year:

1. Define the main identifiers – Preferably as String values
2. Create a unique key using these identifiers – Preferably by concatenating, to avoid boilerplate code
3. Register each of your objects in a Static Dictionary within that class – To allow for direct access using the key

What do you normally do?

When you want to refer to other objects, the classic approach is to either use:

1. Event Listeners and Event Dispatchers – Advantage is that you capture and process the even where needed, deal with the data there.
2. Object references – Telling any object that needs to know what the objects are it might want to refer to

What is the problem here?

1. Event dispatching – Disadvantages of dispatching events are many. I mention two.
   1. Overhead - You are broadcasting to a lot of objects who will either ignore the event, or capture the event and discard of it, wasting your resources while doing it.
   2. Who? What? Why? – Events can be dispatched from anywhere and the reasons why you received an event are not always clear. Especially when some event dispatch was not cleaned up and is fired when you do not expect that. Also when dispatching it, who will receive it? When you want to see who might respond, you will have to find the places where the event is captured.
2. Object references – Especially when you start to have multiple levels in your code, you will start to have dependencies that are harder and harder to maintain.

What is the goal?

To create a simplified way to refer to objects from other objects and get things done faster and simpler when you want interactions between objects.

As one of the side-effects, double-binding objects becomes a lot easier: allowing you to do stuff from “A” to “B” and from “B” to “A”.

WTF? Static variables and static methods!?

We use static variables, Dictionaries to be more specific, to solve this issue. “Using static variables” and Static Methods is regarded as suspect coding behavior for the following reasons:

1. When a static variable is changed somewhere, it can fuck up the app somewhere else – Potentially fucking up Unit Testing as it is unclear who changed what when, when the value of a static variable is suddenly changed
2. When creating new objects extending the class, static methods are crap – Potentially fucking up one of the glorious option of OOP: Polymorphism

When you look at the code below, you will see that the static variables and methods are used in a different type of way than what is described above. The Design Pattern used is closest to an Object Pool and a Multiton.

Let’s get down: Example

Lets assume:

1. You have a WorldMapChart object you use at least twice in your project.
2. WorldMapChart 1 is called “WorldMap1″, WorldMapChart 2 is called “WorldMap2″. We capture that in mapID
3. In each of these worldmaps you have County Polygons with datasets stored in: CountryDatasetVO
4. Each of these countries is represented with an item in a list. We represent countries with a countryID.
5. Each item in the list gets highlighted when you mouse over a country and vice versa
6. We use mapID and countryID as our main keys to avoid leaking events to other instances of the world map.

Code example

We only take one aspect to avoid overloading this post: the Country Dataset Value Object.

The code given only deals with registering the object in a Dictionary and offering a Static method to retrieve a specific VO.

class CountryDatasetVO
{
   private static var countryDictionary  ictionary=new Dictionary()
   private var _mapID:String;
   private var _countryID:String;
   public function CountryDatasetVO(mapID:String):void
   {
       _mapID=mapID;
   }
   public function set countryID(id:String):void
   {
      // Set country ID
      _countryID=id;

      // Add Country Data Set to mapping
      var key:String=_mapID + "_" + _countryID;
      countryDictionary[key]=this;
   }
   public static function getCountryDatasetVO(countryID,mapID):void
   {
       var key:String=mapID + "_" + countryID
       return countryDictionary[key];
   }
}

By using a direct call on the class and using the proper keys, we can get any object we want.

var countryDatasetVO:CountryDataSetVO;
countryDatasetVO = CountryDataSetVO.getCountryDatasetVO(mapID, countryID)

Simple as that.

When we are consistent in our classes, each class will at least have the basic keys to refer to any other object via these generic identifiers. And naturally we do everything the exact same way anywhere else. Leaving us with an incredibly simple and solid Object Reference Model across our entire application.

We do not have to worry about nesting objects N levels deep or when and where they are instantiated. We do not have to create extra classes and resolvers for object specific events. As long as we pass our keys and do a check on null values we are going for solid gold.

if (countryDatasetVO == null)
{
   // the object does not exist, take action or exit here
}

Moving it a step further

Let’s say that the CountryDataSetVO is updating the view when data is received and lets assume each Country is setup the same way.

// In countryDatasetVO
private function onDataUpdate(e:Event):void
{
   // Getting the country polygon
   var countryPolygon:CountryPolygon;

   // As they share the same key values, you can use that
   countryPolygon=CountryPolygon.getCountry(this._mapID, this._countryID);

   // Check if we have contact
   if(countryPolygon==null)
   {
      // No polygon, exit
      return;
   }

   // Reflect data
   countryPolygon.reflectData(this);

   // Also in the list item
   var countryListItem:CountryListItem
   countryListItem=CountryListItem.getListItem(this._mapID,this,_countryID)

   // as we create the object when not there, we always have result
   countryListItem.reflectData(this);
}

Moving it even further: BlazeDS

When you use BlazeDS, objects you send to the Server are not the same as the ones you receive. By using the String References to identify Data Objects you already use in the application, you can easily retrieve the Client Side object it represents and inject the values you received from the Server.

Result

As we store object references in the classes they are created with, available in a Static Dictionary and available via a Static Method, the need to pass specific Object References is removed.

We also simplify the application for anyone else who comes after us. When extending the application with new parts, knowing that passing- and using Key Referrer values is all you need to access specific objects is enough to make sense of it.

In the example above we can easily add more items in the onDataUpdate even handler. As we only need the key referrers and the objects we want to refer to resolve the actual object, we have no limits except our needs.

Comparison (no code)

When using events, we need to dispatch these over some kind of pipeline. As Flex and Flash uses the Display List for that by default, you might want to choose using a Static Dispatcher in a specific Class. So that your non-DisplayObjects can receive these too.

When you receive the event, you need to crack the contents to see if this event was for you, or if you can ignore it. With about 250 countries in a World Map that is doable.

Benefits

1. Simplification of the project code - No need to inherit classes or class-references, no hard coded dependencies or chains of dependencies
2. No Dependency Chains – When you pass object references to child objects, you create dependency chains. Dependency chains will break your balls at some point when you start refactoring or when
3. More agile – Changes can be made easier due to the reduction of dependencies and dependency chains in the application
4. Clear reference to key identifiers - Each project has a specific structure with primary and secondary objects
5. Easier to do double binding – When you want objects to refer to each other and when they share the same key values, using these key values is all you need to find the object you want to manipulate
6. Less headaches – Complex applications can become like advanced math: very complex and hard to crack down. Knowing that key values reflect the application structure and knowing which key values help you find the right objects is enough.

Things to take care of

The moment real performance becomes your game, you will need to optimize the code. You do not want to constantly have to resolve “object C” when you can do that once and save further overhead once done.

Double-binding is another tricky friend when optimizing. Especially when you do not know who will be there first. Each of the objects doing double binding will have to be able to receive and to create a binding.

This post does not cover that aspect.