The workplace is a funny thing. Design patterns were created originally for the workplace, but we find that in some workplaces that no one has time for DP. I think that your institution is exactly right in helping you develop practices that focus on reusable code, whether they call them design patterns or not. Likewise, creating a library of solutions means that you’re going to work with a set of practical tools for getting things done that can be reused.

In working through the different principles in the Lunch Bucket Rules series, I’ve come more and more to see them as design pattern templates. My hope is that by thinking about programming through the lens of programming principles, ActionScript 3.0 programmers will eventually use them as a way to get something done quickly. The next time the same issue comes up, the reusable code is sitting there awaiting them.

Even throwing together a hack for a quick solution, one can find eventually that hacks keep getting better and better until one day they are no longer hacks!

Cheers,
Bill

Great blog btw! Keep up the good work :)

While I don’t think there were too many political considerations behind OOP and design patterns, I do believe that there were economic ones. A lot of people were trying to figure out what practices worked best for good OOP, and they developed many of those we’ve discussed on this blog in the “Lunch Bucket Rules” series.

Erich Gamma was working on his doctorate in Switzerland and took as his topic a set of patterns that would adhere to good OOP and solve a lot of common problems that programmers encountered. If you look at the OOPSLA meetings up to and after the publication of Design Patterns by the Gang of Four, you will see a good deal of discussions about re-usable and easy-to-update and change programming code. The idea was that if certain practices were followed that changing and updating code would be made easier. This would save money wasted either in re-writing hacks or starting from scratch with each new project. At the same time, the solutions they came up with were quite elegant in the reasoning behind them.

As far as relaxing “while machines do the work,” you’ve got to remember that we’re the ones who tell the machines what to do! Programming will also be a mix of invention and creation mixed in with drudgery; just like most other jobs. However, as an “art form” it can be quite rewarding–as you seem to be saying.

Take care,
Bill

What is the point of life without art and beauty? What is the point of life if all you produce is one ugly design after another just to keep waking up in the morning, feeding your belly, and dumping it out the next day? There is no point in that.

Coming from Java, ActionScript 3.0 imposes certain restrictions (or workarounds, or whatever). This is especially true if you know Java quite well but you’re just getting used to ActionScript. The more you become familiar with ActionScript, I would imagine you’ll find both more restrictions and some nice Easter eggs as well.

Your blog on moving into ActionScript from Java is great, and I plan to read more of it carefully.

Kindest regards,
Bill

I really like your idea..

… if they’re good enough, coding with design patterns is subconscious, they don’t have to think about using singletons, delegates, mvcs, or any other design pattern….

While you may not be able to spend time in the middle of a busy deadline to sharpen your OOP and design pattern skills, at some point they become a natural part of doing coding. Poor coding is the same; if you do it long enough, it becomes part of you. I’d rather try and improve all the time!

Kindest regards,
Bill

What I’m interested in is a related question: When does the user experience require that you deviate from your design principles? Ultimately, the user experience is what we really care about. The underlying design would ideally facilitate a better user experience, but I don’t think that’s always possible.

I don’t necessarily think that we’ve sacrificed our core design along the way but we certainly had to spend a lot of time fixing things that were a lot easier in Java. Examples are our original use of the adapter pattern which was based on the Proxy class in ActionScript (now changed to inner classes using namespaces), implementing pseudo-threading for hierarchical tasks, scoping of anonymous functions, and several problems that arose because of the lack of abstract classes and other language differences.

Psuedo-threading is an example of where I would have liked to avoid injecting dependencies for a pseudo-threading manager throughout a lot of our core code. Here, I had to break some of our encapsulation in order to achieve a desired result. In that respect, it’s really a combination of the need for a fluid user experience combined with a language that doesn’t support certain operations that required changing our design. I’m curious if anyone else has come across an issue such as this where the user experience drove a result that wasn’t desirable from a design perspective.

Planning always helps, but if the project is a low budget, short deadline, never going to get changed, with a short 6 months to a year lifespan, then the client probably has a “get it done” over “oop & design perfection” state of mind. I always give the client options of what workflow they want to take, so (s)he is aware of the consequences, and can rethink the budget, scope and deadline. Sometimes the “get it done quick” is a better option, it depends on the variables.

Like a doctor, you can always advise your patients of the better choice and the risks of taking the bad choice, but at the end of the day it’s up to them, as long as they are aware of what they’re getting in to. If it’s something that you know is going to fail then it’s best not to take the project. For me, producing something of great quality is better and more rewarding than making money off a failed concept.

I am very glad you brought up the point that a lot of web development for media companies is long-term. The fact of the matter is that those who should be aware of it have neither the background to understand it nor the motivation to plan for long range development. It’s almost random when a good structure is introduced into company programming model that helps the company to achieve a competitive edge.

Good to hear from a fellow UCSB alum,
Bill