dotnetmud: inheritance and awareness and IoC

I’m running around in circles, so I thought I should try to draw it out.  Click to zoom in if not legible; text below explaining.


All the words are driving me nuts.      So I added A,B,C,D to the diagram above.

  • A = the layer that talks network transport stuff, like Signal/R. 
  • B = the layer of the game that cares about booting up, shutting down, who is logged into the game, loading and unloading of realms.
    • This stuff should NOT be directly available to in-game objects to mess with!
  • C = subset of B.  This is the stuff that should be available to in-game objects.  It’s the O/S of the game, as it were.
  • D = game code.  In the case of wizard-coded realms, probably gets scanned to make sure it has no assembly references, and in days of old might have run under CAS. 
    • I’m not actually going to secure it, just want to make sure its probably securable.


  • A should not know about all the stuff in B;  just bare minimums to talk network occurences to.
  • B should definitely not know about the specifics of A.  In fact, I’d say B is an assembly that HAS NO REFERENCE to Signal/R.
  • D should not know about B.  I’d go with: D can ONLY have an assembly reference to C, and NOTHING else; if something is to be made available to code in D, it must be added to C as a pass-through.
  • B & C can know all about each other.

Singletons vs Static vs ..

Lets call “C” the driver layer.   Ie,  IDriver.FindObjectByName() would be an example. 

For all the code in the Mudlib, right now, it does stuff like Driver.Instance.FindObjectByName().

It might be better to use IoC and take an IDriver in the constructor, and then call _driver.FindObjectByName().  HOWEVER, then I get into things like “Can I have IoC limit which objects can be created”, and “I want to make sure as the objects are created that I can keep track of realms and stuff like that”, and all of a sudden IoC is too nice a tool to use.  I’m sure it could be used with guards on it, but ..    leave that to somebody else, I have no joy in solving that.

So then I could go with how many libraries get a hold of things – (static class DotNetMud.XXX).Driver.      Always gets you the same one every time.

But if I’m doing that, why not just have a static class, Driver.FIndObjectByName()?     No, I don’t want to do this, because I MIGHT want people to be able to unit test their mudlib objects, and I want the driver to at least be an IDriver so it can be mocked somehow.

So, I think where its going is, I’ll have a poor man’s IoC.  DotNetMud.Global.Driver   gets you the driver.  

Who References Whom? How to deal with the Inverse?  

D references C for sure.

A references and feeds B, including telling it how to talk back to A (via Lambda’s)

B is configured to know how to get to D.

C, when asked, can create objects from D.  but it only knows D through configuration.

C needs access to stuff in B

B doesn’t need much from C/D, other than the interactives list, I think.

So there’s another guy, @, who:

  • reads configuration to determine
    • Who is D
    • Who is D.GameSpecifics
  • Creates or Gets Singleton of B
  • Creates or Gets Singleton of C
  • Informs B of C or C or B or whatever.   Not sure about this part yet.   Probably they each know each other’s interface.
  • Tells C enough stuff about D so that it can create objects from D on demand.
  • Tells A about B
    • I would say creates A, but … SignalR does its own creation. So really more like when A is created, self-registers the context somewhere and triggers something so that A can talk to B.


Right now its all in one assembly.

This stuff is TOUGH.

And it gets tougher with code loaded on the fly.  I don’t think I’m going to deal with that yet.

No wonder when I open up the project, this stuff isn’t flowing well.  Smile 

How to get it there

I think I should probably get everything living in the same assembly at first, except under a web server rather than a console app.

Then, get the singleton-reference stuff in place.  Change all references to do that.

Then, peel out the MudLib to its own thing.  It still references all of B/C combined.

Then, peel out C to its own thing. 

Then, peel out B to its own thing, separate from A.

This is a several-hour project, I fear.

Tagged with:
Posted in Code

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

.net 3d 3d-printing 4k abc15 algorithms ames android anonymous types audio editing aws backup basecamp beatunes biorhythm bittorrent blender blog boston marathon bpm c# caffeine campfire candycrush car carmax certification charity chiropractor cities-skylines clog clone codelouisville codepalousa coding coffee collaboration color run ComputerElbow ComputerVision configuration consulting cooking crash course crashplan crestwood cryptocurrency cycling dabda dan dapper DataSet ddl diabetes dictation dotnetcore dotnetmud downtown e-cycling elite excel exercise expiration facebook fashion feature-branching firefall flipflops Flow FL Studio focus food forecastle fortresscraft franklinplanner gadgets game-design games git github google docs google maps gopro gps grandpa greenshot hack half marathon headless health heart rate hiren ignew integration testing interop inventory ios ipad itunes javascript jobs karma kdf keyboards keys kittens lamont laptop lavalamp leaf lego life lifehack linq linqtotwitter linux los angeles louisville mandelbulber massage therapy mastery-teaching maths merge metformin Minecraft miniature modeling monitor mud muhammad ali institute music mvc mycartracks netfabb nexus10 node nomanssky nostalgia nutrition nwipe oldham county grand slam opal openjscad openscad owin pacedj paper mockup pepakura performance photoscan politics pomodoro postgresql powershell premiere priorities prius process product-management project-management qa ReFS resharper review rmi roman road 5k RSI rubiks running samsung 700t sandals schedule scooter scribblelive selenium service shapeways sleep slic3r sneakersync snot software software-engineering solidoodle soylent spacegame speaking sql sqlite SSDT SSIS standing state-machine stayfocusd stonehearth studying sunset tablet teaching team teamcity teamtreehouse terraform tesla testing tfs time timelapse torque touch tracks trs80 Tuple tutor twitter ubuntu unit testing utilities video video editing visual studio vscode vsvim warp stabilizer windows 8 windows home server wordpress wpf xml zozo
%d bloggers like this: