Think of them as muscle and bone tissue. The constraints are hardpoints that give you leverage, while the muscles move those hardpoints into different configurations.
Using Flex During Development
Early in a system's development, you have all the speed you want, with very little existing code to pull around. This is a great time to intentionally overflex. Specifically, design interfaces and data structures to be excessively simple and flexible, with the understanding that you'll have to tie them down more later.
For example, lots of my early designs are little more than elaborate combinations of Hashtables and simple structures like this:
public class Entry {
String name;
Hashtable<java.lang.Class, Object> attributes;
Hashtable<String,Entry> children;
}
I don't know what stuff I'm shoving into Entry yet, so I just key it by its type, which will be some interface the object implements.
Later on, I'll look at what interface classes I've implemented that end up in attributes and start adding specific members for them as needed. When I'm pretty sure it's going well, I'll try commenting out attributes and seeing what still complains.
Reflection and even plain C++ RTTI can come in really useful for this sort of stuff.
The Entry nicely builds a hierarchy. How about we try and serialize this into XML? Put out an <entry> tag with a name attribute, and then normalize the Class names and use them as attribute names, with the Object.toString() method as the value. Shove the children inside and you've got something you can manipulate.
Or, replace Entry with a normal DOM node and play with XPath, XQuery, and XSLT to do your work for you. Compiling an XSLT into a class and then running it against your data structure's not a bad way to go. Frankly I'd stick with the DOM approach until I was sure I couldn't get away with it. A few minutes playing with ways to hack the design around this decision can make a go/no-go decision for me.
The big point behind this is not to commit to any design before I know what's going on. Software development's an exploratory process, so there's no point in getting overcommitted early when I'm sure I'll have to change it later.
