A while back I read an article by Miško Hevery that was part of a Guide for Writing Testable Code. Granted the stuff that Miško writes about is for the software engineers at Google, and my best guess is that it is primarily for Java programmers. (The examples are in Java and unfortunately [for us ActionScript 3.0 programmers] many of the solutions are through Java libraries.) Nevertheless, we can learn from the larger concepts and apply them to our projects.
Agile, Design Patterns and Unit Testing
If the senior programmers at Google (and I would imagine Adobe, Apple, Microsoft and elsewhere) have a mantra in programming, it’s probably something like this:
Keep it agile!
As most of you know (or suspect), Design Patterns are a type of Agile programming, and the development of both (DPs and Agile) in the 1990’s overlap in content and developers. They were all reading each other’s articles and contributing to one another through venues like OOPSLA and ACM (Association of Computing Machines). The agility movement was in part a reaction to heavy-handed, micro-managed systems of software development processes that were par for the course up to that time. This was not a rebellious overthrow so much as a realization that in order to get things done the processes had to change. In other words, Agile programming and Design Patterns were children of necessity as much as innovation.
The Agile Manifesto
In 2001, a number of developers put forth what they called the Agile Manifesto. It is a concise list of what they have come to value—here it is:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The forgers of the Manefesto go on to state that while there is value in the items on the right (normal), we value the items on the left (bold) more.
For those of you expecting something dramatic or revolutionary, you might be disappointed by this tepid manifesto. (These guys aren’t Marx & Engels even though they have PhotoShopped a picture to look like an impressionist painting of anarchists gathered in an ill-lighted London basement as they plan to overthrow the hoary capitalists). Nevertheless, you can see how such a value system is tied into a movement to get out from under the sludge dictated by a focus on protocols rather than results.
Continue reading ‘Class Constructor Function Should Do No Real Work: Getting Agile Part I’
At this last OOPSLA conference I was talking with one of the European participants about remembering the different principles, and he showed me this series of images based of SOLID principles. The SOLID principles are from the acronym:
S: Single responsibility principle
O: Open closed principle
L: Liskov substitution principle
I: Interface segregation principle
D: Dependency inversion principle
My favorite is the giant Swiss Army Knife in the Single responsibility principle:
Now, whenever I start loading up a class with more functions than the giant Swiss Army Knife, I’m reminded to throttle back! You’ll have a lot of fun at LosTechies.com with other articles on design patterns and OOP. They’re not ActionScript, but they’re informative.
Tomorrow morning bright and early I’m off to Orlando, Florida for the 2009 Object Oriented Programming and System Languages Association (OOPSLA) annual meetings. I’ll be making an ActionScript 3.0 presentation in a workshop on Sunday. Our workshop is named “Good Examples for Exposing Bad Practice” and meets in Pastoral 3 from 8:30-5:00 (Oct 25) Mine is based on the ‘Wrong Way Warrior”; so it should be familiar. On Monday, I’ll be at the Educators Symposium all day, and I would really like to meet other ActionScripters who might be at the conference
Here are some other speakers you might want to hear/meet:
1. Miško Hevery
Automatic Dependency Injection In The Land Of Dynamic Languages
2. Barbara Liskov (Liskov Principle)
Keynote Speaker
3. Ralph Johnson (GoF)
Regrowing a Language: Refactoring Tools Allow Programming Languages to Evolve
Anyway, just in case any of you will be there, drop by one of the sessions. Everyone’s been very accepting of ActionScript 3.0, and it’d be fun to chat with some fellow ActionScripters!
I recently commented on a provocative post by Jovan Sranojlovic called “Do Not Use Design Patterns Upfront” He made some thoughtful observations on why design patterns are important to software engineering and how they can a abused in that context as well. However, I disagreed with his basic thesis that design pattern should only be applied in a code refactoring context and not before. Based on his argument, thinking in design patterns upfront, based on the intent and purpose of code in not good, and even harmful. I tweeted my disagreement with a link to JUnit A Cook’s Tour, an example of, what I thought was, thinking in design patterns at the application design stage. The resulting tweet stream follows:
“Do Not Use Design Patterns Upfront” http://tr.im/uI3a – I don’t agree. Beck & Gamma did just that with JUnit http://tr.im/uI3z #asdp
1:09 AM Jul 30th by @chandimac
@chandimac no we didn’t. we explained junit with patterns, but we started with one tiny test and grew the whole thing from there.
6:33 AM Jul 30th by @kentbeck in reply to @chandimac
@kentbeck TX for the clarification. Do you recommend “thinking in patterns” early or should they be added at a later refactoring stage?
6:30 AM Jul 31st by @chandimac in reply to @kentbeck
@chandimac i prefer to put patterns in place just before they become useful. if i can’t see how to do that, then soon after.
6:51 AM Jul 31st by @kentbeck in reply to @chandimac
JUnit A Cook’s Tour explains the design of a system by starting with nothing and applying patterns, one after another, until you have the architecture of the system. As Kent pointed out, the article was written that way, and I had incorrectly assumed that JUnit was developed that way as well.
Design Pattern wisdom in 140 characters
I put patterns in place just before they become useful. If I can’t see how to do that, then soon after.
– Kent Beck
I was quite intrigued by Kent’s reply to my follow up question. It got me thinking about a bunch of issues. What does it mean for a design pattern to be “useful?” How much before is “just before?” What does it mean to “put patterns in place?”
I was so intrigued that I re-read a bunch of stuff on refactoring and design patterns by Beck, Gamma, Kerievsky and Alexander. I try my best to answer some of the questions raised in the remainder of this post – or more appropriately, reconcile some of my cognitive dissonance. Continue reading ‘Integrating design patterns “just before they become useful”’
Tight Code and Tighter Programmers
The other day I was thinking about programs with tight code and loose coupling. Having been raised on tight coding I started looking around for a decent definition of tight code and came across one of my programming heroes, Charles H. Moore, inventor of FORTH programming language. For Moore, as well as others discussing tight code, the term refers to
… a program that is written very efficiently.
That doesn’t say a whole lot, but it says everything. In FORTH, not a single electron is wasted in the code, but not a lot of people use it because you have to think like a processing stack—last in first off. In other words, you have to think exactly backwards from normal sequencing. Ergo, most programmers have migrated to a high level languages with a C++ type of format such as ECMAScript and ActionScript 3.0. To some extent, efficient code is code without superfluous elements that gets a job done. (That’s why I don’t like to use conditional statements where I can help it—there’s generally a more direct option.)
In the context of OOP, I think that tight code can be equated with tightly woven objects. Such objects are good at what they do and nothing else. We can apply the single responsibility rule:
A class should only have a single responsibility.
However, they can work with other objects.
Continue reading ‘Tight Coding and Loose Coupling’
Bill Sanders
Recent Comments