Friday, April 29, 2005

Non-obstrusive configuration

When writing an application the author has to think about wiring and configuration issues which often contradicts with fine-grained approach used during building it. These issues depends heavily both upon the design of the code itself (how much state does it have, how it is strutured) and the nature of the library (application) in question.

To clarify: an application consists of a number of functions/classes/modules each of them having (usually) a defined and well-understood scope and set of responsibilities. So far so simple - this is just good engineering practice. To get a coherent whole you need to wire it all together, configuring the parts along the way (network ports, passwords and other runtime options). And this is where it get messier.

How to achieve ease of wiring/configuration while not compromising on system's design on the same time?

I have run into these problems myself a number of times and almost every time has to come with some novel approach. Partly this is to be expected as different requirements calls for different solutions. Still, my own naiveness (experience level) has to play some role as well, as I may have missed some patterns obvious to a more experience programmer.

One of the biggest problems I had is that most of these solutions are obtrusive: once installed they tend to spread thru the code like viruses which hurts maintainability (if you ever change your mind and try a different approach) and code reuse.

The rule of thumb I've learnt so far is to try to split the application into two parts: core (a "library" in a traditional sense) and, um, application itself. While this does not solve the problem, at least it puts it within well-defined boundaries. OTOH, when this "application" gets incorporated into something still bigger you have to overhaul it again which is no good. Even without incorporating, the "library" part sometimes became smaller than the "application" part, which spoils the whole idea.

To put at least some meat into this post, I'd like to mention PyContainer library of Rafal Sniezynski, which is a Python implementation of "Inversion of Control" (IoC for short) idea. IoC in general and various implementations (called "containers") is a hot topic in Java community.

On the surface, this is exactly what I'm looking for: container manages wiring and configuration of its object according to given set of rules. But I can't tell for sure until I try. What I like most is the perceived level of obtrusiveness (lack of): components that go within container have no idea they are within "something" and thus can be developed, unit-tested and reused freely. Only part of the application that uses the container has to deal with it - and my only concern is to make it as small as possible.

P.S.: Re-reading my post I realized that problems I'm talking about may not be so obvious and/or so painful to the readers as they were to me. What was your experience? Do you share my frustration?