Building on this excellent answer, I’d say that the last part - transforming
the data into a form that is better suited for a specific task - is also one
major aspect when trying to reuse code. I tend to ask: what kind of questions
do I try to solve? And then transforming my data in the first place into a form
that gives me enough flexibility for this kind of questions while being
specific enough to allow for straightforward implementation of the tasks.
Thanks to nodesets, this is all “fun and games”.
It gets more complicated, when you consider schema evolution - the change in
the supplied data structure - as another “moving part” in this challenge.
A good read on the aspect of writing software with respect to change and
reusability is “Refactoring - improving the design of existing code” from
Martin Fowler. It’s focused on Java applications, but imho the reasoning behind
it is applicable to writing software in general.
Am 03.08.2019 um 10:50 schrieb Michael Kay mike(_at_)saxonica(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>:
My initial task was to display the gas stations at rest stops on the routes
from Boston to NYC. I wrote some XPath queries and XSLT code. It worked -
yea!
Then I was tasked to display, for each route, the gas stations at rest
stops. For example, display the gas stations at the rest stops on route
I-84, display the gas stations at the rest stops on route I-95, and so on.
I think your mistake was that you failed to generalise the first task. You
should have recognised that if you were asked to display the gas stations on
the route from Boston to NYC then it would be best to write a general
function to display gas stations on the route from A to B and then invoke
this function with A=Boston, B=NYC. If you had the general function available
then the next step (doing it for all routes) would be much easier.
Generalization of requirements is often the key to achieving potential for
change, and it's a fairly instinctive process. Getting it right is tricky,
because over-generalizing the requirements can lead to a significant increase
in development cost. But in this case generalising the first task would have
cost almost nothing.
The other thing that occurs to me looking at these problems is that the data
representation is rather strange. Why are the start point and end point of a
route concatenated into a single element value? Surely routes should be made
up of segments, so that a segment can be shared between several routes?
Surely someone is going to want to know the distances between points on a
route, e.g. how many miles to the next gas station? Sometimes the key to
achieving potential for change is to first design a data representation that
is going to be suitable for a wider variety of tasks; and then the first
stage in your processing pipeline is to transform the data you have been
given into this better representation.
Michael Kay
Saxonica
XSL-List info and archive
EasyUnsubscribe (by email)
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--