Monthly Archive for January, 2010

Page 2 of 2

Class Constructor Function Should Do No Real Work: Getting Agile Part I

Published on January 6, 2010 in Principles. by William B. Sanders 11 Comments

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’

ActionScript 3.0 Design Patterns New Years Resolution

Published on January 2, 2010 in Design Patterns. by William B. Sanders 7 Comments

First off, Happy New Year and Happy New Decade to one and all. By the end of 2010, I hope I’m a better programmer than in 2009.

In order to be a better programmer I need to have a good resolution. I’d like to do something better this year while not abandoning good habits I’ve picked up over the time I’ve been trying to be a better programmer. (That actually makes sense even though a bit convoluted.)

So, now I’ve got to come up with a resolution. The one I want will do the following:

  • It has to be one I can keep. If I aim too high, I may miss the mark and feel I’ve failed to keep a resolution. Aiming too low is just a waste of time.
  • It has to be forgiving. That means that if I don’t keep it 100% of the time, it’s ok. Improvement, not perfection, is the goal. Improving habits eventually become part of my programming DNA, and it’s a step in the ongoing trek to be a better programmer than I was at this time last year.

So my New Year’s resolution is:

Improve nailing down relationships between classes in design patterns.

For example, when I look at a design pattern with an aggregate relationship, I want to be able to immediately imagine what the code looks like for that kind of relationship and how it differs from an acquaintance or some other relationship. Eventually, this will enable me to look at a design pattern in a UML and see the code-class relationships and how it might or might not solve a programming problem.

I’ve probably got a dozen other resolutions for becoming a better programmer, but they’re sort of always there nagging and whittling, nudging me in the right direction. (My wife has thousands of resolutions for me; none having a thing to do with programming!)

Ok, that’s it for me. How about you? What’s your New Year’s programming resolution? Put ‘em in our Comments, and at the end of the year we’ll see how we’ve done.