Software Framework Design Redux

Partly because I've been reading Domain Driven Design, but also for other reasons, I've been thinking a bit about framework design lately. Specifically, what is it that I do naturally that I should/could codify, and what are the design traits of code frameworks I have been involved with that have been successfull?

This is going to be a little bit of a stream of consciousness, but I will probably build on it later.

First, two preconditions

1. understand the business needs. kinda obvious, but you need to plan for it to be iterative, especially if the business needs are not fully known yet. (even if you think they are they probably aren't)
   
   
2. understand the mindset and capability of your developers—what are their strengths/weaknesses, what conceptual models do they click with or struggle with

The interesting thing I realise about these points is that they define your two main points of interest, which are also your two "clients": the business; and the developers. Even if you are in exactly the same team as the developers who will be using your frameworks they are really your clients in the sense that your job is to enable them to be productive.

Goals when designing & implementing a code framework

1. end result should allow the natural expression of the real world model such that it's easier to accidentally do the right thing than to make a mistake. this goal is symbiotic with the general goal of hiding complexity where possible.
   
   
2. build in enough flexibility for accidental reuse without increasing the complexity of the mental model required to put the objects to use. (more on accidental reuse to come in a later blog entry).
   
   
3. design for free improvement of end functionality via upgrades to the framework.
   
   
4. extend goal (A) such that simply using the framework should result in expressive self documenting code. an aid to achieving this is to think of objects/methods in terms of their use rather than their implementation.
   
   
5. internally design the classes/methods to allow for a change in the implementation of their own properties. eg. an identifier changing from an integer to an alphanum or a property being replaced by a method. these changes should be possible without resorting to an automated refactoring tool (although sed, awk and perl are perfectly respectable refactoring tools ;)

Observation: (D) & (E) are much easier to achieve with an OO agile language such as Ruby or even OO Perl than with traditional compiled languages. Objective-C and the core NS/Cocoa classes do a good job at bridging this gap.

Update: There's a useful article on API design just been posted on perlmonks On Interfaces and APIs. While not as concise as it could be, the referenced material is very good. Two that I would heartily recommend you read are:

• Edward Tufte - The Visual Display of Quantitative Information
• Donald A. Norman - The Design of Everyday Things