OpenClosedDesigns

This page was put here by PeterVandenberk to exemplify his main concern about the XP approach (namely that the DoingTheSimplestThing aspect of XP may result in non-reusable components and ultimately in closed designs/systems)

The following excerpt is copied out of a software book that has nothing to do with development methodologies per se, but it quite nicely formulates my thoughts on the matter. Except for the phrases in [...], it's a verbatim copy.

reusable components, open designs/systems

A reusable component is one that can be used and/or extended in many different contexts. Every component in a system is directly employed by one or more other components and ultimately by system users. Components are reusable if they can be employed by many others, EVEN THOSE THE ORIGINAL AUTHOR DID NOT HAVE IN MIND. (Isn't this by definition luck? -- OliBye)

One reaction to [the challenges of component development] is to restrict designs to *closed* systems. A closed design is one in which you have full knowledge and control of the entire execution context of all objects and classes. Often, the very first solution to a software problem that you think of is a closed design that works only in a very narrow range of contexts. When these designs represent entire self-contained systems, then you do not have to worry much: you may be able to know enough about the context in which each object is used not to bother thinking through the consequences of other potential interactions. This works only until you try to reuse or compose the code in some other program.

There are design problems that are so tricky to solve, or in which [the mix of technical and other] pressures are so great that the best you can do is come up with a fully closed, one-shot design. But you can usually do much better by establishing [design] policies that hold across all components in a given framework or package.

The attractions of design for open systems are just too great to ignore. Closed systems by nature are sooner of later just thrown away; often sooner. Without opportunities for extension or evolution, they cannot adapt to the ever-changing situations they find themselves in.

comments, thoughts & rebukes

PeterVandenberk, 19990909:

There is much to say about this subject, I think, but to kickstart the discussion, I'll just pose the following question to XpApprentices and XpSkeptics alike: can DoingTheSimplestThing result in reusable components and open designs (in the sense described in the above excerpt)? should it?

OliBye, 19990910: What do you mean by a component? [Wiki.ComponentDefinition] people don't seem to agree, which makes discussions about pro's and cons of components difficult ([Wiki.ComponentBasedProgramming]).

In XP functionality which is refactored so much that it doesn't need refactoring is stable, and unlikely to change could make a good Component candidate.

Components are needed when one project can't talk/share/be allowed to change/has to pay for ... other people/code, the important part of the component contract is that it doesn't change.

If you had tests for all the code in both projects, you could factor out something better than a component, and improve both codebases.

Components end up as a compromise, as they need to be used in the general case, by definition this is sub-optimal. In [Wiki.BlackBoxComponentry], RonJeffries? makes a good point about [Wiki.OverEngineering] .

I agree that in a market where people don't share and aren't prepared to change, components emerge as way people can work together, however if you introduce rigidity (because component contracts don't change often) then you pay the price when you want to change the direction of your deliverable (it becomes brittle).

w.r.t. "There are design problems that are so tricky to solve, or in which [the mix of technical and other] pressures are so great that the best you can do is come up with a fully closed, one-shot design.".

Design problems that are tricky to solve can always be broken down into smaller parts, otherwise they can't be coded on a computer (where you break problems down into a set of small instructions, the results of which give you the solution :-).

By technical pressures do you mean lack of skills/resources, or use of new immature third part software? These can be solved with training or the bin. Managerial pressures often arise through lack of productivity, Xp is aimed at increasing productivity.

Designs are often closed if they are "two hard to understand", it's probably more likely they are too hard to change, if you had a full test suite you could assert each change you made didn't didn't break the existing system, making changes simple and opening up closed designs.

PaulSimmons agrees that this discussion should take place on a different site, but also is not sure that he knows what re-use is anymore. Re-useable components would have to be driven by a goal, such as to simplify database connectivity, and I don't know how I can justify that goal in a development project which has a purpose for that software. Re-use seems to happen in refactoring.

Before moving this discussion to C2, PeterVandenberk, 20010426 would like to (mis?)use the following snippet (taken from GlynMoody?'s "Rebel Code, Linux and the Open Source Revolution", page 61) to underline his concern about the DoingTheSimplestThing aspect of XP...

It's a verbatim copy of RichSladkey?'s recollection of LinusTorvalds?' approach of integrating the NFS code into the Linux kernel:

"So in my case, Linus improved the kernel in a way that made more work for himself and for me in the short term, but made the kernel clearer, cleaner, and more maintainable in the long run. This lesson by example of taking the high road and DoingThingsRight?, instead of taking the path of least resistance, made a very big impression on me at the time, and became an essential part of my programming philosophy"