Process is like any philosophy: You have one even if you say you don’t care about it or think it causes more weight to consider it.

This is as much a recommendation as a rant, so pardon me while I do both

Situation
Open-source project or foundational classes for use within your organization that contains methods for parsing data.

Background
Often, I’ve run into issues where I am using an open-source library (public or private) and I need to add extra logic to a creational algorithm(s) and cannot or cannot easily do so. This is what has sparked me to write this post, because I am increasingly seeing these types of issues.

Recommendation
When creating algorithms that create objects from other objects (eg models and serialization) , please use offload the logic to accessible and easily modifiable methods. In Design Pattern terms, I’m requesting and ranting that the Factory Method Pattern, Strategy Pattern, or something similar be used. This only compounds in importance when there are several objects created in a single method!  <– That right there is arguably bad practice in general for large projects.

Example
NOTE: Showing a simple example seems to not show the problem, but I’ll try. For a better example, please refer to “Real-Life Example” below.

Mapping XML properties to models within a project.

protected updateList():void
{
var header:Header = new Header;
header.title = _xml.header.@title;
header.lang = _xml.header.@lang;
header.colors = _xml.header.colors.toArray();

var body:Body = _body;
var child:XML;
for (var i:Number = 0; i < _xml.body.item.length(); ++i)
{
child = _xml.body.item[i];
body.getItemAt(i).text = child.@text;
}
}

Real-Life Example
NOTE: I do not mean to pick on or criticize the fine work done by the peeps working on the OpenVideoPlayer Project and MUST EMPHASIZE that the project is very useful and saves time. This merely serves as an easy example to show. Moreover, I’ve written my fair share of problematic code along these lines too.

• https://sourceforge.net/tracker/?func=detail&aid=2977117&group_id=243060&atid=1121331

This post is simply a quote from my brother-in-law Forrest Kyle, which he kindly spent time writing out what he said to me on the phone while we discussed architectural practices. I wanted to share this, because I believe it is so well put.

In programming, genius rarely manifests itself in some radical new idea, or some blazing new algorithm that redefines the parameters of what is possible.  Often, genius is the visible result of a forceful and determined intensity of focus placed upon mundane details, and making sure software is fundamentally correct.  A good sign of a genius programmer is one who is willing to work closely with details that are “beneath him” if it serves the greater good of program efficiency and correctness.

Don’t allow yourself to make a design decision for which you can’t articulate a verbal defense.  Imagine yourself explaining why you made your design choices to a panel of super geniuses.  If you find yourself at a loss for words, it is likely that future users and developers of your program will find themselves at a loss for patience.

A source file is more than just a set of instructions for your computer; it is a formal engineering schematic and must be crafted in such a way that communication with other developers is as deeply ingrained in the presentation as the function of the program itself.  You are not writing source files for yourself, you are writing them for current and future coworkers.

Programmers who don’t feel the need to write clear, helpful documentation are like cats that don’t feel the need to use the litter box.

-Forrest Kyle

In closing, this really is not just a great explanation of solid programming, but of communication and thought out action.