SOLID design principles

My apologies for the lack of posts.
I've been playing in the Steampunk World lately.
Found this article at TechRepublic and it occurs to me that it applies to MOO code pretty well.
Enjoy
KJ

SOLID design principles improve object-oriented development 
By Justin James October 19, 2012, 1:45 PM PDT

 SRP is the idea that objects should do one thing and one thing only. It is tempting to think this means that a class should represent an entire piece of business logic or data, but that is not quite correct. The idea is not to group all of the functionality that is related together, but all of the functionality that achieves the same goal together.
For example, if you have a class representing printer, putting all of the printer operations (getting toner levels, printing a page, getting an error message) in the printer class may make sense, but it is not really the right approach. Instead, you would put all of the functions related to printing in the same class, and all of the functions for reporting status in a class, and so on. You break the work down into small, digestible chunks. The payoff here is that you can make changes to a select piece of functionality without possibly affecting a ton of other items.

O - Open/closed principle (OCP)

This very simple idea is that classes can allow themselves to be extended but not modified. The source code for the original class should only be modified if a bug is found. The reason behind this is that changing the code will mean that everything depending upon it will need to be retested as well.

L - Liskov substitution principle (LSP)

LSP states that the subclass of an object can be used in place of the superclass without changing things like what the program does, whether it compiles, etc. For example, if class “elephant” is a subtype of class “animal,” then you should be able to use “elephant” where you use “animal,” and the “walk” method will still “walk” (even though the implementation may be different), the “numberOfLegs” property will still return the number of legs (though again, it may be a different number from the base class), the “eat” method will not throw any exceptions that it would not throw in the “animal” class, and so on. It is much easier to make changes and test when you follow LSP.

I - Interface segregation principle (ISP)

ISP dictates that interfaces need to have as little functionality in them as possible. This allows the consumer to only deal with the functionality they are concerned with, which reduces testing needs and the impact of changes to the system.

D - Dependency inversion principle (DIP)

With DIP, high-level objects are abstracted away from low-level objects. It is normal to think of the low-level objects as just being smaller pieces of a bigger one. For example, let’s say that you want to query a database and fill a data set. The temptation is to pass in the database connection information to the data set and let it make the connection. Instead, you pass in a connection that is already configured, and in this way, the database can change without needing to retest the entire data set object.
J.Ja

Inventing on Principle

Thanks to Paul Rayner at Muddle for pointing me to this fantastic presentation.
Enjoy
KJ



Bret Victor - Inventing on Principle from CUSEC on Vimeo.

The Machine

Found this comment in a thread on the PiLuD: free talks on Programming Language Design Google group.

https://groups.google.com/group/pilud/about?hl=en

"OOP is best used to model the program like a big machine - gears, stacks, queues, sensors and actuators, signals and data. If you do this, then a lot of problems are cleanly avoided."

David Barbour   Very apropos to MOO code programming.

I'm in print!

I just received my copy of  Teaching Literature in Virtual Worlds 
This very interesting collection of articles, edited by Dr. Allen Webb of Western Michigan University, includes a chapter by me "On the Building of Worlds". 
Very cool, if I do say so myself.
The articles discuss many of the Worlds created at Literary Worlds, which is hosted at Western Michigan here: http://brn227.brown.wmich.edu:7000/
Ciao
KJ

New AJAX updating Room files available at the Barn

I have put the files for the new room up at the Barn.
You can get the zip file here:
http://www.encore-consortium.org/Barn/files/objects/EnCore/rooms_with_ajax.zip
The zip has two files one, ahah2.js, is the javascript that handles the AJAX communications.  This file should be put in a directory called edit_area in the root of your encore directory.  The other file is an @dump of a room with the  auto updating capabilities for the objects list.
This room has a property called js_base_url which is used if you cannot store the ahah2.js file in the encore directory. As long as the directory you have access to is on the same server as the moo it will work.
It is currently set to my directory at Literary Worlds so make sure you change it to your directory or set it to 0.
Let me know if you have questions or problems and also how it works for you if you try it out.
If you just want to see this room in action you can check out the test room at Literary Worlds by logging in as a guest at: http://brn227.brown.wmich.edu:7000/
Once logged in @go to #5446
There is a box there you can pick up and drop to see the update in action.
Enjoy
Ciao
KJ

New Experiment: Room contents display enCore V4

Continuing along on my experimentation with the user interface in enCore v4, it occurred to me that one of the issues I've had is how the room display is static, relative to the text side.  Where this can be an issue is with a busy class all logged in at once.  The text side is flying with all the comings, goings and chatting amonst the class members, while at the same time the room display, with the list of contents and exits, is frozen. Only a look command or click on the look icon will refresh it.

Several times I have entered a room with people chatting and they did not notice me entering because the text message scrolled past, lost in the chatter, and at the same time the list of the rooms contents didn't change either. They were quite surprised when I started talking!

How to get around that?

Here is my latest experiment... AJAX, Asynchronous Javascript and XML. This is the underpinnings of the infamous WEB 2.0 jazz we've been hearing about for years now.  I found a small javascript file called AHAH, Asynchronous HTML and HTTP, which is a simple implementation of AJAX that only deals with html rather than XML.  You can read about it here: http://microformats.org/wiki/rest/ahah

What this javascript file does is allow us to update PARTS of a webpage on demand or automatically without reloading the whole page. For my experiment I had it update the contents display of the room every second.  The javascript calls a verb on the room that sends back the current list of objects in the room.  The code then checks to see if the contents have changed since the last time and if so it updates the list in the display.

Very cool.

I had to change the SPANs with classes to DIVs with ids, which needed a bit of CSS gigerypokery to line up, but that was it.

The javascript file is very small so does not add any delay to the page when first loaded.

A pleasant surprise was the way the code was able to access the verb on the room, it did not need any path info at all, it knew the host it was being called from and simply returned the verb output without complaint. (Not sure why that works frankly)

This tool should have great use for interactive objects, since pieces of the display can change without having to refresh the whole lot.  Think of communication devices, games, viewports, graphics displays etc. According to the notes with the javascript there can be multiple instances of the updaters on the same page.

I will try to put the code into a package for the Barn in a bit.

New Xpress Program Editor coming along nicely

Good Day All

I have continued to mess around with my revised Program Editor for V4 enCore.
My latest experiment has worked pretty well, surprisingly.

This version has added the ability to insert Breakpoints into a verb so that execution of the verb will stop and the values of selected variables will be spooled out to the programmer. The programmer then has the option to continue the execution of the verb or to kill it.  This is most useful when troubleshooting looping code as the Breakpoint can be used to allow a kind of step through, examining the loop as it executes.

I have a version of my Ewebbed enCore package that includes the new editor.  I will be putting this up at the Barn shortly.

While the new editor works OK, it is pretty rough and I'm sure there are some gotchas so the usual cautions about using beta class software apply :-) I would be interested in any comments or suggestion you might have so please send them along.

I would also really appreciate anybody who has a good handle on verb and html security to take a look at the way I've set this up, to make sure I haven't left any massive security holes anywhere. The Checkpoint and Breakpoint verbs must be Wiz owned which always makes me a bit nervous.
Ciao
KJ