Now blogging at diego's weblog. See you over there!

from components to modules


Right now I'm refactoring/rebuilding the user interface of a new release coming out soon (oh right... Note to self: talk about that) and I'm facing the fight against "sticky" APIs. Or, in more technical terms, their coupling.

Ideally, a certain component set that is self-contained (say, and HTML component) will be isolated from other components at the same level. This makes it both simpler, easier to maintain and, contrary to what one might think, often faster. While I was at Drexel, at the Software Engineering Research Group, I did work on source code analysis, studying things like automatic clustering (paper) of software systems, that is, creating software that was able to infer the modules present on a source code base using API cross-references as a basis. Since then I've always been aware (more than I was before that, that is) of the subtle pull created by API references.

The holy grail in this sense is, for me, to create applications that are built of fully interchangeable pieces, that connect dynamically at runtime, thus avoiding compile-time dependencies. In theory, we have many ways of achieving this decoupling between components or component sets; in practice there are some barriers that make it hard to get it right the first time. Or the second. Or...

First, the most common ways of achieving component decoupling are:

  1. Through data: usually this means a configuration file, but it could be a database or whatever else is editable post-compilation. This is one of the reasons why XML is so important, btw.
  2. Through dynamic binding: that is, references "by name" of classes or methods. This is useful mostly with OO languages, as you'll generally end up dynamically allocating a superclass and then using an interface (or superclass) to access the underlying object without losing generality (and thus without increasing coupling).

Achieving decoupling in non-UI components is not too difficult (the data model has to flexible enough though, see below). But UIs are almost by definition something that pulls together all the components of a program so they can be used or managed. The UI references (almost) everything else by necessity, directly or indirectly, and visual components affect each other (say, a list on the left that changes what you see on the right).

In my experience, MVC is an absolute necessity to achieve at least a minimal level of decoupling. Going further is possible by using a combination of data (ie., config files) to connect dynamically loaded visual components removes the coupling created at the UI level, but that is difficult to achieve, because it complicates the initial development process (with dynamically loaded components bugs become more difficult to track, the build process is more complex, etc.) and development tools in general deal with code-units (e.g., classes, or source files) rather than with modules. They go from fine-grained view of a system (say, a class or even a method) to a project, with little in between. We are left with separating files in directories to make a project manageable, which is kind of crazy when you think how far we've come in other areas, particularly in recent years.

The process then becomes iterative, one of achieving higher degrees of decoupling on each release. One thing I've found: that the underlying data model of the application has to be flexible enough, be completely isolated (as a module) and relatively abstract, not just to evolve itself but also to allow the developer to change everything that's "on top" of it and improve the structure of the application without affecting users, etc.

Yes, this is relatively "common knowledge", but I'm a bit frustrated at the moment because I know how things "should be" structured in the code I'm working on but I also know that time is limited, so I make some improvements and move on, leaving the rest for the next release.

Final thought: Until major development tools fully incorporate the concept of modules into their operation (and I mean going beyond the lame use of, for example, things like Java packages in today's Java tools), until they treat a piece of user interface as more than a source file (so far, all of the UI designers I've seen maintain a pretty strict correspondence between a UI design "form" and a single file/class/whatever that references everything else), it will be difficult to get things right on the first try.

Categories: soft.dev
Posted by diego on January 11 2004 at 10:17 AM

Copyright © Diego Doval 2002-2011.
Powered by
Movable Type 4.37