"But, master, since the universe is illusion, to base a system on a feature is surely a mistake! The features the customer thought most important, by your own admission, are what thecustomerthought , not the Truth itself. Is it not better to base my architecture on the thing that the application is about? Observe the joy of those programs that fullfill their OneTruePurpose!" --
"Ah, but is it Truth who must be satisfied, or those who pay you? Do not lose sight of what is being attempted. We are merely trying to make something that will work, not creating art."
If you believe this is important, then it seems that you'd be tempted to think ahead when designing, rather than follow YouArentGonnaNeedIt. The XP community challenges this orthodoxy, and (it seems to me) says that actually modifications need not be much more dangerous than additions. --DaveCleal
Also, if XP says that traditional OO ideas about flexibility aren't so important, then IsXpIndependentOfObjects or the traditional OO ideas about flexibility are simply wrong.
I remain unsure. The most critical piece of XP for making modifications safe is the comprehensive unit tests. For some kinds of changes that's fine, but I worry about reversing more abstract design decisions. I don't have a good example to hand, but I will think about it... -- DaveCleal
I think of flexibility as the quality which minimizes the amount of work you have to do to get from point A to an arbitrary point B; you need get rid of or avoid everything that you don't need, and then add what you do need. When you keep your system in a state where you only have to add things, it is very flexible. There is a cost to keeping around things that might, kind of, maybe will be needed someday; it is harder to see where you can put new things. The area around the code has more potential than any code you can put in its place. -- MichaelFeathers
Some colleagues and I were discussing topics like this the other day, and we came up with the following list of software characteristics that we think are typical of highly flexible systems. This is just brainstorming. But it feels at least partially right to me. The characteristics are:
I would add ...
runtime flexibility (or configurability) The ability to change the functionality of the software without making code changes. Achieved through configuration data, plug-in architectures and embedded languages. No code changes need be made to the core system.
internal flexibility The code is easily adapted and extended to supply new functionality without major redesign. For instance, a flexible system would be able to have a security model added without major redesign. Is XP able to help us accomplish this?
external flexibility The software be used as a library or framework and reused (without source code changes).
We should create flexible software through extensible architectures rather than implementing many possible solutions (of imagined requirements). I guess this is just another way of saying: YouArentGonnaNeedIt.
However, isn't extensible architecture in opposition to XP until a need for a particular extensibility is required. For example, using XP, would you create a level of abstraction to your persistence layer (for extensibility - in case you need to support multiple database vendors or both RDMBS and ODBMS), or would you leave this until there is a requirement to use more than one database vendor, and then refactor like mad?
My apologies for my abuse of the English language --SteveShaw.
I'm defining flexibility as follows (is this XP'ish ?):
A system is flexible, if modifications that are known to be necessary can be locally confined.
I distinguish three cases:
1. an aspect changes for the first time: Add the change and ReFactor the system as to eliminate any code duplication the change might have caused (OnceAndOnlyOnce). This will likely create a new VariationPoint?.
2. an aspect changes for the second (third ...) time: If an appropriate VariationPoint? does already exist, just add the new variant. Otherwise, ReFactor to create one (similar to 1.)
3. an aspect might change: Then you YouArentGonnaNeedIt right now.
There are lots of different possibilities for defining a VariationPoint?, from case-statements to abstract base classes to reflective systems. The most appropriate solution depends on the particular change and context. Thus, flexibility is in no way specific to OO nor is OO required.
Can flexibility be considered independent of the flexor? Perhaps one programmer's flexibility is another programmer's straight jacket. Can you think of an example?
Sure. What about the frameworks in this book [1]. The authors claimed a good deal of flexibility for their various results. But I imagine there are those who would, from personal experience, claim the opposite.
I always find it's best to CodeDefensively? and CodeForTheMaintainer. This can add some cruft like the VirtualStaticIdiom, but it makes extending the system very fast, easy and less errorprone.
YouArentGonnaNeedIt suggests otherwise. I don't know. A little bit now can go a long way later. -- SunirShah?
By the way, I've realized that the code first then refactor method isn't for me. It's far too bottom up, which means I have to throw out all my other problem solving heuristics. It seems like I'm jumping into a box instead of excaping from one. Bend like a willow.. keep flexible.
I am now experimenting with solving software systems one problem at a time, however. I believe deeply in microiterations. --ss
Tools and language make a difference. If our language or the way our files interdepend are deeply resistant to refactoring, then more investment up front is perhaps more valuable. In general, money spent on tomorrow instead of on building what we need today is inherently wasted. It's putting money in the savings account instead of buying food. There is a chance of earning it back tomorrow, if the product survives, and if we need what we foresaw we might, and if it really costs less, and other ifs. If there were no other way, we'd have to make investments in the future. But there is another way: clean code, refactored as needed. --RonJeffries
Being back into the theoretical stream of things, I've reconsidered slightly. My new answer is indirection. We know that from programming (PolymorphismVsSelectionIdiom, for instance), so let's apply that lesson to a metalevel. The system and the definition of the system are disjoint, giving us another level of indirection. So software systems are flexible to change because we can get at it at a higher layer. And naturally indirection makes for flexiblity because it allows you to defer decisions to much later, or even change decisions. Conversely, if we put all systems onto IC chips, then the system and logic are identical and inflexible. It's that Turing guy again. -- SunirShah?
This page mirrored in WikiPagesAboutRefactoring as of July 17, 2004