[MUD-Dev] Object Models

John Buehler johnbue at msn.com
Mon Nov 27 21:46:49 CET 2000


> KevinL writes:

[comment on extreme programming]

As far as I'm concerned, components should be used to facilitate techniques
like extreme programming.

> The more I think about this, the more I'm convinced that
> components have their
> place, but probably with loose contracts - which'll make John cringe ;).
> Tight contracts are _one_ approach to getting good code - but
> they are, to me,
> an approach that follows the previous attitudes of "make it more
> explicit,
> make it harder rules, and it'll be more likely to be right",
> which I don't
> believe.  Loose contracts and loosely-typed scripting, a la
> python, combined
> with heavy/fast testing cycles a la extreme programming, may be a more
> suitable approach for muddish coding, maybe ;)

Scripting works well so long as you never want to write code on top of the
script code that you've written.  Script is 'soft' and is tough to use as
the basis of additional functionality.  It is my contention that all of
today's software will eventually become the toolkit of future software.  As
a result, I remain in the camp of wanting rock-solid components that
implement very specific functionality.

FYI, one team in the group was designing a system using components and they
had no conceptual trouble with making changes to contracts.  It's more an
issue of (as has been said) locating and revisiting all the impacted
locations.  But the great thing about it was that they WANTED to revisit
those locations.  If the system was going to work the way they wanted it to,
they had to inspect and probably modify each location.

There is no question that applications can be built using a variety of
techniques.  I'd be very interested to see how folks felt before and after
working with components in the form that I was working with them.

JB


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list