[MUD-Dev] Re: TECH: reliablity (was: Distributed Muds)

Kwon Ekstrom justice at softhome.net
Mon Apr 30 11:00:42 CEST 2001


----- Original Message -----
From: "Ola Fosheim Grøstad" <olag at ifi.uio.no>

> I view "components" as something invented for business applications
> which tend to deal with rather stable domains or no hard realtime
> requirements or serious interdependency performance issues AND which
> have to deal with a bunch of existing legacy systems and lots of
> bloat and incompetent programmers...

I disagree.  Components are a time saving device which centralizes
code.  You are probably coming from a different set of circumstances
than I am, and I can imagine that in a non-OOP language my points
might not be appropriate.

I use OOP with components to distribute some of the design
requirements, but centralize as much as possible.

> But for state-of-the-art MUDs... Why put up a concrete wall between
> your modules?  This is not good for a system that is supposed to
> evolve.

I don't see how components force strict limitations on the code
anymore than centralizing practices which are common to muds.  Since
I'm using java, I use interfaces to define specific methods that are

called by my various components.  Certain tasks which are repeated
often, but have minor differences can be handled this way without
having to check against each possible difference which allows me to
centralize the code without limiting my expansion.

> By advocating components one just says that one has given up finding
> a good flexible design AND that you know exactly where flexibility
> will be needed.  In a virtual world however, dependencies

My system is very flexible, more so than any other mud codebase that I
have ever worked on before.  Most of the flexibility can be attributed
to my OOP design, but I use components to centralize specific tasks.
Note, my components are used to handle VERY specific tasks, which
allows me to only use components as necessary.

> IMHO layers, modularity, invariants, separation of responsibilities,
> refactoring and all that is good, but components-as-advocated
> (specification based, stable, 3rd party replaceable, no need to
> recompile etc) are not!

Hrmm, perhaps you see components as a static unchanging never to be
modified again part of the code.

And I suppose 3rd party components that don't let you access the
source would cause this problem.  I'm writing my own components to
handle a specific problem.

-- Kwon Ekstrom

_______________________________________________
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