Day 12

I spent today creating a mockup of a website we will be building for a client. First I was using Photoshop to, rather tediously, make layer after layer to build up a flexible mockup. I was making it in a similar manner to how I write a program. I followed the Single Responsibility Principle in that I gave each layer a single purpose so that I could more easily reuse each layer, and mix and match them when the time came to make a Keynote presentation.

Then Micah found a cool mockup tool called Balsamiq mockup, which not only is design to make mockups, but also makes the mockup look... like a mockup. All the components, like text panels and button, have a hand drawn - kindergarden sort of look. This is especially cool because it emphasizes to the client that what you are presenting is in no way a hint towards the actual website design. It emphasizes that the mockup's only purpose is to demonstrate how the website might function and flow, largely in order to get some feedback.

Design Patterns:

* Factory Method Pattern: The Factory Method Pattern is a way to design an application that can create objects and act upon them, without actually knowing what class defines the object. It pushes the responsibility of defining which objects to instantiate to the subclasses.

The actual pattern is summed up in a single method, the Factory Method, and the rest is to make that method work. This is either an abstract method, or a method with a simple default constructor that is to be overridden. The Factory Method lies in the Creator class, and it returns an object called the Product. The Product is actually an interface that defines the objects which the Factory Method is meant to create. The Concrete Product is the implementation of the Product, and is actually created in the Concrete Creator, which implements the Creator.

So there is an application with a Factory Method. This application is meant to be versatile, and can't know the classes of the objects it is creating, but must act on them none the less. Some user of this application defines a Concrete Product and defines a Concrete Creator. Another part of the application tells the Creator that it needs a Product. The Creator then uses its Factory Method, which has now been overridden by the Concrete Creator, to make a Product, and returns a Concrete Product from the Concrete Creator. Then another part of the application can tell the Creator to perform some operation on the Concrete Product. The Creator can perform operations on the object without knowing its actual origin or class since the object implements the Product interface.

A simple example of this comes in the form of ice cream, and everyone likes ice cream. Say there is some ice cream cone maker that can put together a hot fudge ice cream cone. This dream maker doesn't know what flavor of ice cream is in the cone, nor does it care. All the dream maker knows is that it can put some fudge on some ice cream. The dream maker or Creator will make a cone only when something tells it to. The Creator will say ' I'm going to make a cone now' or run the Factory Method, at which point some other machine, the Concrete Creator, will supply the dream maker with a bucket of, say, vanilla ice cream or Concrete Product. The dream maker will then scoop up the Product, put it in a cone, and perform its fudging operation on the Product.

* Singleton Pattern: The Singleton Pattern is a simple pattern designed to help make sure there is one, and only one instance of a class. This is useful in situations where you have a system with several classes looking to use a Singleton, but if there are multiple instances of the Singleton, then the system breaks down. Some examples of this would be if you had some application with a Context class that holds all the essential data for the app, or if you had an operating system with a file system storing all the information of the running processes. Multiple unexpected contexts or file systems could complete destroy the program, thus you want to make sure there is always just one.

This works by designing a Singleton class that catches all attempts to construct it and with an easy and well known way to get the existing instance. You would create a class which has some static reference to itself. This reference could be initialized to null, or could be given a static instance. The Singleton's constructor should be set to do nothing, to defeat attempts at re-instantiation. You would also create a static getInstance() method, which would return the single instance. This would be the method all classes would use to get the Singleton instance.

If you used lazy instantiation by starting the Singleton ref out as null, then you get the benefit of only creating an instance when it is needed, but then you also might get a nasty race condition. Assuming in your getInstance() method you check to see if the ref is null before you instantiate it, then if you have two threads running which call getInstance() at the same time, it is possible that one thread will pass the conditional statement and then loose the processor before it creates an instance. Then the other thread could create an instance, return the processor to the first thread, which would then create a second instance since it already checked for null. So if you are using a Singleton in a multithreaded environment, you might be better off taking the safe route and sacrifice your lazy initialization to make sure you never end up with a race condition.