This morning just as I had left the house and turned left into one of the roads that make up the maze of narrow roads between the haphazardly built, tightly packed houses of Kami-meguro, from the far end of the road came flying, at full blast, a small budgerigar. I could feel the flapping of its wings as it swooshed above my left shoulder, just barely missing my head.
I don’t know what the little fellow was up to, but imagine the destruction, had it hit me in the face (I walk pretty fast too). I suppose it had escaped from one of the houses. It probably won’t survive very long, considering it won’t get warm for a while yet and the abundance of cats in the neighborhood. Not to mention its suicidal tendency of flying towards people on the street.
By the way, did you know there’s a population of wild parrots in Tokyo? Escaped parrots have taken up residence in the trees lining the south side of the French Formal Garden of Shinjuku Gyoen. Yes, they are very particular about where they live. They’re larger than budgerigars though, and manage to survive.
Anyway, I was going to write about software architecture, not parrots. The last couple of days I’ve been thinking about what software architecture is. The word gets thrown around a lot, and people even carry the title “software architect”.
In my work there’s talk about architecture as well. We’re doing architecture.
Now, I’ve figured out that what gets called software architecture can, in down to the monkey’s balls practice, be classified as one out of five tangible things. I might at some point come up with more, and if you have any suggestion then please leave a comment. Anyway, here they are:
- Build-time composition
Can be in the form of invasive composition done by a proper composition system, as outlined in the book Invasive Software Composition, written by my favorite professor Uwe Aßmann. But more often in the form of simple #ifdefs, or link-time selection of different libraries.
- Design patterns
This is probably my favorite one. Design patterns are powerful not primarily because the pattern in itself is clever, but because they communicate the intention of the programmer to others quickly. If someone knowledgable reads a piece of codes that says it’s doing a visitor pattern, say, then you immediately know what to expect. - Naming conventions
This might be the most common excuse for an architecture. And I’d count object oriented languages’ attempts to hide things behind (often long) namespace and (often nested) class names as just another naming convention (often termed “object oriented design”). Architecture often seems to take the meaning that things that belong to one part of the system starts with a certain prefix (such as a class name). It’s useful for finding things in the source tree, though. - Function pointers
… in one form or another. All programmers use function pointers, often termed callbacks, handlers, functors, virtual methods, delegates, etc. Function pointers allows control of flow during runtime, but more often they seem to be used as a bad substitute for build-time composition. At some point there seems to be a line where this common code monkey tool turns into architecture. - Layers of indirection
It has been said, perhaps by Mark Twain, that any programming problem can be solved by adding another layer of indirection. It is often implemented in the form of function calls, or by using function pointers, often in combination with naming conventions. Of course any code monkey can do function calls. But by doing small transformations of values and data types, and perhaps branching depending on the data, and letting the next layer do this in succession, one can seemingly achieve architecture.
Barring further bird attacks, I will consider these five items to be the fundamental building blocks of software architecture. Next, I intend to write about how these can be used to create good architecture. Because one man’s architecture is another man’s code bloat.
