[Edu-sig] Design patterns

[Scott David Daniels]

Arthur wrote:
> If I am understanding "properties" mostly correctly, and in fact their
> reason for being is to allow for a fundamental midstream redesign of a
> program without alteration of that program's API, I am thinking something to
> the effect that it is only possible to do the impossible in half-measures,
> and half-measures are only half-measures and who wants to work in an
> environment of half-measures.  
> 
> I don't think mathematical notation, for example, includes the concept of
> the half-measure.

OK, how about this explanation.  If I am providing software support to a
group of scientists running experiments, I can give them an API and the
fastest-to-write code that passes tests.  Once I've done that, they can
get to work using the software while I go about the work of making the
software more reasonably designed and responding to efficiency problems
that they actually encounter.  We use the API as a "treaty point" --
they stick to using it, and I stick to providing it.  This structure
can also be used to provide the "for free work-alike" and the "pricey
efficient" versions.

Properties allows me to determine later (perhaps after watching how
they actually use the API) whether I should precalculate the triangle
angles, recalculate them each time, or find an even fancier version
where I compute them each the first time on demand and re-use those
results, invalidating the angles whenever a side is changed.  If I
have to make those design decisions up front, I have to assume a
pattern of use.  If I wait until I have actual users, I can get
real statistics on how the use the API.  We decouple our work this way.

--Scott David Daniels
Scott.Daniels at Acm.Org