Perfecting OO's Small Classes and Short Methods
This is here as sort of a TODO for myself this year. I want to try this experiment. I really like the concept of breaking down OO projects into this extra fine granularity.
He suggests writing a 1000-line program with the constraints listed below. These constraints are intended to be excessively restrictive, so as to force developers out of the procedural groove. I guarantee if you apply this technique, their code will move markedly towards object orientation. The restrictions (which should be mercilessly enforced in this exercise) are:
1. Use only one level of indentation per method. If you need more than one level, you need to create a second method and call it from the first. This is one of the most important constraints in the exercise.
2. Don’t use the ‘else’ keyword. Test for a condition with an if-statement and exit the routine if it’s not met. This prevents if-else chaining; and every routine does just one thing. You’re getting the idea.
3. Wrap all primitives and strings. This directly addresses “primitive obsession.” If you want to use an integer, you first have to create a class (even an inner class) to identify it’s true role. So zip codes are an object not an integer, for example. This makes for far clearer and more testable code.
4. Use only one dot per line. This step prevents you from reaching deeply into other objects to get at fields or methods, and thereby conceptually breaking encapsulation.
5. Don’t abbreviate names. This constraint avoids the procedural verbosity that is created by certain forms of redundancy—if you have to type the full name of a method or variable, you’re likely to spend more time thinking about its name. And you’ll avoid having objects called Order with methods entitled shipOrder(). Instead, your code will have more calls such as Order.ship().
6. Keep entities small. This means no more than 50 lines per class and no more than 10 classes per package. The 50 lines per class constraint is crucial. Not only does it force concision and keep classes focused, but it means most classes can fit on a single screen in any editor/IDE.
7. Don’t use any classes with more than two instance variables. This is perhaps the hardest constraint. Bay’s point is that with more than two instance variables, there is almost certainly a reason to subgroup some variables into a separate class.
8. Use first-class collections. In other words, any class that contains a collection should contain no other member variables. The idea is an extension of primitive obsession. If you need a class that’s a subsumes the collection, then write it that way.
9. Don’t use setters, getters, or properties. This is a radical approach to enforcing encapsulation. It also requires implementation of dependency injection approaches and adherence to the maxim “tell, don’t ask.”
I went ahead and ordered the ThoughtWorks book too. I've used their Mingle product, which I find very compelling, so I am looking forward to their essays.
Continuous scrolling image thumbnail component for Flex.
Here is the beginnings of a full featured open-source continuous scroll thumbnail component for Flex. It is rough right now, but I plan to polish it and make it something useful. This format is really appealing, as it gives the user a seamless view of a gallery, without any jumps or aggravating scroll bars. Up until now I have been using H and V Lists in flex for my thumbnailing, but they are ugly and don't provide as rich of an experience.
The Scroll Panel from AFComponents was my first choice. It is a very nice component, well priced, and would be just what I need, if not for the fact that my project is open-source and using a commercial component sorta kills the whole thing. After scouring the internet I finally stumbled upon the work Peter Wright has put in on a perpetual scrolling list.
I've modified it to accept an XML list of image objects, as well as perform horizontally. It is also functioning as a slideshow, and I want to allow it to go either H or V depending on the need. It should shape up to be a nice reusable component. Much thanks to Peter for supplying the code to get me started.
I had an epiphany as to what polymorphism is last night.
Yes, I know I am late to the party. I can't even estimate how many times I've read a definition of an Interface over the last year. It has been a concept that totally baffled me for a long time, then I sorta understood, and last night I actually implemented an Interface intentionally and correctly. The same is true for the term polymorphism. I can read definitions until my eyes hurt, but until I actually use it, the words are just abstractions. These two concepts are synonymous, as Interfaces in Actionscript 3 are a convenience for type-checking polymorphism in APIs.
'Ah-ha!'
In this case, I had a Flex container that I wanted to pass to a method. I didn't know what the container would be, but I knew that it would be a container. IContainer? Yup. Now the method couldn't care less what class is being passed its way, as long as it has the appropriate methods that match the IContainer signature.
Now it makes sense. This is the reason I keep reading that I need to use implicit getters and setters with private class properties instead of public properties. Public properties are not allowed in an interface, so you aren't able to abstract these properties with an interface. Getters and setters ARE allowed in an interface, so now you can expose these properties and ensure that methods expecting the interface get what they are looking for. As it turns out, people weren't recommending this simply to get me to write extra lines of code 
The pieces are starting to come together. Abstract classes, design patterns, polymorphism, interfaces... PureMVC has been a help. The framework pushes me towards proper OOP and the use of design patterns. Stacking knowledge, one block at a time.
