Living in the Tech Avalanche Generation

During my journey in learning Ruby / IronRuby, I have caught myself often naming things in C# with a Ruby convention or BDD test naming regime. To be extreme here’s an example:

var customer_to_make_preferred = Get_Customer_By_Id<ICustomerMakePrefered>();

//OR METHODS LIKE THIS

public void Group_By_Orders_And_Print_To_Console_Window()
{
    //…..etc
}

I really find a benefit in greater understanding when reading code when I take this approach. Now it’s true I have been programming in C# for some 10 years and I don’t know if this kind of behaviour will see me excommunicated from the circle of brethren or not but I would like to know what others think.

Opinions please! And yes I know this is gonna be like waving a red flag in front of a raging bull :). And for the Ruby people, I am only proposing the extended underscored naming convention and nothing else – it’s all about naming and that’s it – ya basta!

One of the clear value added possibilities with IronRuby and IronPython (or any DLR language) has to offer is making applications scriptable. This opens the possibility for enabling scripting of your application, it’s types and potentially objects running in memory in your application at runtime. I recently went looking for an IronRuby console / shell window control written natively in WPF and turned up nothing. I did however come across some examples implemented for Windows Forms and the one that got my attention was Orion Edwards Embedded IronRuby Interactive Console.

Whilst Orion’s project provided the basis of what I was after, I was under no illusion that I would find exactly what I was after and would therefore have to build out the rest of the functionality I required.

The Basic Requirements List

• Reusable WPF User Control
• The Console should allow users to write script against in memory objects of the host application.
• Should persist (to a log) the state of variables in the IronRuby runtime scopes.
• Extensible Application Design and easily maintained and Testable.

So rather than re-invent the wheel I started out with Orion’s code and worked it into a WPF User Control that followed the MVP pattern. This version supports printing of all scope variable state to the console window, clearing of the console window text and all the out of the box access to the IronRuby runtime from the console itself. The IronRuby Console User control also allows the consumer application to pass through in memory variables from your managed CLR hosting application.

Finally I need to also make mention that some of the classes used to stream the STD/IO came directly from Ben Halls wonderful IronEditor. And before I forget, the code can found here on my blogs subversion repository.

Firstly let me mention that whilst this series started out as demonstrating the Gang of Fours patterns in C# I have since decided to change direction a little bit and have the rest of the series presented in IronRuby. Why? My Reasons are twofold, firstly there are probably more than enough examples of the patterns in C# that another one will certainly not be missed and second completing the series in IronRuby will serve as great learning tool on the way to better knowing the language. I have previously posted on the Builder Pattern implemented in IronRuby and for that example I used Sapphire in Steel to develop the code and I am really hoping that we get a great code editor for IronRuby when it makes it’s official debut.

What purpose does this pattern serve?

Implementing the prototype pattern facilitates creating a prototypical object and subsequently being able to produce copies of that prototype.

Example Code:

First lets start with our Vehicle manager which will hold the prototyped vehicles that we wish to take copies of.

class VehicleManager
    def initialize
        @cars = {}
    end
    def add key, prototype
        @cars[key] = prototype
    end
    def remove key
        @cars.delete key
    end
    def get_vehicle_by_key key
        @cars[key].deep_copy
    end
end

Next we create a module that we will use as a mixin to extend a ‘vehicles’ behaviour to include cloning.

module Cloneable
    attr_accessor :id
    attr_accessor :horse_power
    def deep_copy
        Marshal.load(Marshal.dump(self))
    end
end

class Car
    include Cloneable
    def initialize horse_power, id
        @id = id
        @horse_power = horse_power
    end
end

class MotorCycle
    include Cloneable
    def initialize horse_power, id
        @id = id
        @horse_power = horse_power
    end
end

All that’s left is to look at how to create some prototype’s using these classes.

$counter = 1

#new up a VehicleManager to store vehicles
#that we are interested in cloning
vmanager = VehicleManager.new

#add a car and motor cycle to the manager
vmanager.add :eighty, Car.new(80, $counter)
$counter += 1
vmanager.add :ninety , MotorCycle.new(90, $counter)

#retrieve clones of the car and motor cycle
vehicle_car = vmanager.get_vehicle_by_key :eighty
vehicle_bike = vmanager.get_vehicle_by_key :ninety

#print the results
puts “The horse power for the car is “ +
     “#{vehicle_car.horse_power} and the ID is :#{vehicle_car.id}”
puts “The horse power for the motor cycle is “ +
     “#{vehicle_bike.horse_power} and the ID is :#{vehicle_bike.id}”