Day 11

I started the day off by finishing the refactoring of the Painter classes, and their respective tests. I then began thinking of the ways I could isolate regions to be individually marked as dirty and repainted with the appropriate painters. The biggest issue is that anytime a region needs to be repainted, I need to discover what text lies in that region, if there was a selection in that region, and where the cursor was.

Repainting all these different components independently and situationally might actually end up being slower than skipping all the extra logic, and just repainting the full region each time it is marked dirty. To be certain that I am actually optimizing rather than slowing, I will need to find out what part of the painting process is slow. Once I have some metrics to determine which of the following takes longer - painting pixels, determining which pixels to paint, or defining regions - I can then move to minimize the time consuming actions to optimize the paint algorithm.

The last part of my day was spent working with Micah on a new Rails app. We were trying to find ways to make accessing a bunch of the client's data intuitive for the users of the app. Since we really weren't sure how these users wanted to view the data, we were basically shooting in the dark with some general solutions.

To really know what the client wants, especially when you aren't sure how they want to use the app, is nearly impossible. This is why we will present to them a basic and minimum functionality demo in order to get some feedback and hone in on a better solution to meet their needs. We must stay flexible and not set our hearts on a certain solution.

Now I must begin making some general concepts of what the website will look like and how it will function using PhotoShop. We will use the photoshop generated images to show the overall feel and flow of the website in powerpoint slides. I suppose we wont begin really coding until we know we are heading in the right direction.

Design Patterns:

* Abstract Factory Pattern: The Abstract Factory Pattern can be used when there is a need for multiple groups of related objects without having to specify any concrete classes. In other words, the AFP is useful if you have several themes, with multiple components, that you want to be interchangeable to one idea or niche.

This works by first creating an Abstract Factory class that is to be the interface the client uses to make its desired theme. The Abstract Factory will have some concrete subclasses, one for each theme, which will implement the interface's abstract methods, and that will be used to generate the different components of the underlining idea for the respective theme.

There is also an interface for each of the different components of the underlining idea, and each theme will have its own implementation of these component interfaces.

Each of the Abstract Factory subclasses, call them Themed Factories, will depend on the corresponding concrete component classes.

When then client asks its Abstract Factory reference to generate an instance of the underlining idea or a component, the operation is delegated to whatever Themed Factory is populating the reference. In this way, the client never has to know about any of the concrete classes, but can receive instances of them none the less.

Say there is some simple clothing store. This store sells just one top and one bottom, which differ depending on if its summer or winter. This store wants some program to manage what items they are selling at any given point, and they hire you to make this system. You decide that you can implement this using the Abstract Factory Pattern, and so you start designing away. You make a ClothingFactory interface (the Abstract Factory) and then implement it with a concrete SummerClothingFactory and a WinterClothingFactory (Themed Factories). You also create a TopClothing and a BottomClothing interface (Components), and then implement these with concrete summer and winter - top and bottom classes (Themed Components). Finally you link the Themed Factories with their respective Themed Components so that the factories can generate instances of the components.

The client to your ClothingFactory, likely a cash register or online register, holds a reference to the factory. The reference is populated, with either of the Themed Factories, by the application's main class, based off whether its summer or winter. The client may then ask the factory for a top, or a bottom, and will get the appropriate clothing object without ever knowing about the different types.

An excellent advantage to this is that if the store owners wanted to add footwear to their vast variety of clothing, you could easily add sneakers to the summer theme and snow shoes to the winter theme. The Themed Factories could then be made to implement constructors for the footwear, and you would never have to worry about selling a t-shirt and shorts along with a pair of snow shoes.