[MUD-Dev] Re: [IDEAS] Starting from scratch

Adam Wiggins adam at mail.angel.com
Thu Aug 6 11:15:01 CEST 1998


On Thu, 6 Aug 1998, Leach, Brad BA wrote:
> Just on the topic of maintainability, has anyone implemented the
> platform-independant server code using a design pattern of the "Bridge"?
> (Design Patterns, Gof) I prefer to work on a Unix platform, but my
> co-imp likes Win32. The "Bridge" seemes like a nice pattern to solve
> this problem, but at what cost of performance?

I use it *heavily*, even when all the coders are using the same platform,
or it's a project I'm doing by myself.  The small extra bit of effort has
paid for itself over and over in ease of maintinence, porting, and pinning
down system-specific problems.  It also makes it possible to stick all
those nasty system calls away into a file you never have to look at,
instead calling your nice clean wrapper functions.  This can be done
for your main(), your window events, you widget banks, input devices,
sound devices, socket handlers, rendering APIs, and whatever else you
like.

My current work project is cross-platform without too much difficulty.
Once we abstracted all the system dependancies via the bridge pattern,
the only hangup was just small compiler disagreements - be warned that
MSVC has a few of its own ideas about what should be standard C++,
which conflict in a rather serious way with ANSI C++.  Over time our
team has developed a few coding standards in order to try to
satisfy all of the compilers used on the project.

And performance?  Hah.  A few years ago this might have been an issue;
I can't see how it would be now, unless you were doing some sort of
realtime app that required direct and specific access to the hardware.
Naturally, a mud does not qualify for this.  In fact, a text-based mud
is already quite platform-independant by its nature; the only bridges
you need to write are to handle main() and WinMain(), and the connection
manager.  Those should be quite easy; get them out of the way early and
you'll rarely have to examine that code again.

Adam






More information about the mud-dev-archive mailing list