Turning Off Regions in ReSharper

Filed Under (.Net) by John Miller on 10-11-2009

Tagged Under : ,

I’m not a fan of seeing regions in my code and, by default, ReSharper is configured to group members (methods, interface implementations, etc) with regions when running the Code Cleanup utility. I’ve turned this off a couple of times but it usually takes some poking around until I remember what to do again.

From within Visual Studio, open ReSharper –> Options.

Then, under Languages –> C#, select “Type Members Layout”

TypeMembersLayout

Uncheck the “Use Default Patterns” checkbox

UseDefault

Throughout the XML configuration document, you’ll notice various “Group” nodes which are used to create regions for specific element types. Deleting all these nodes will keep ReSharper from adding regions when running Code Cleanup.

Groups

If you really dislike regions, you can also configure ReSharper to remove all existing regions as well. Find the default pattern node…

DefaultBefore

…and add a flag to remove all regions.

DefaultAfter

Much better!

Share/Save/Bookmark

Review: Brownfield Application Development in .Net

Filed Under (.Net) by John Miller on 29-08-2009

Tagged Under : ,

I just finished reading Brownfield Application Development in .Net by Kyle Baley and Donald Belcham and thought I’d put together a quick review some of the strengths and weaknesses the book has to offer.

It’s broken up into two sections with the first half of the book describing how to create a healthy ecosystem for you code to grow in. This gets into areas such as project structure, automated testing, automated builds, continuous integration, etc. They even get into some of the various personas you may run into when working on a Brownfield application (such as the “Ivory Tower Architect” and “The Hero Developer”) and how to effectively work with those personalities. The second half of the book discusses how to make the code itself flexible and maintainable. This includes everything from design patterns to explaining how to create an anti-corruption layer in your code to minimize the impact changes will make on your software in the future.

One of my personal favorite sections included in the book was the awesome explanation of the differences between MVP and MVC patterns. Very clear and concise. I had struggled in the past really understanding the finer points of how the two differed, but the author did a great job comparing the two (as well as their variations).

There are lot of good book available on agile development techniques and software design principles, but this has to be the best I’ve read yet that explains the nuts and bolts of how to apply these ideals to .Net development. There are a lot of great tidbits in there that can be applied to development in any language (although the book is really geared towards tools that are readily available to .Net developers).

And now for a little constructive criticism. The first few chapters, while very informative, seemed to be longer than they should have been. Those could have been reduced by about 25-30% without losing any value. I also felt a little short-changed by it’s explanation of AOP in chapter 8. It started discussing AOP and even gave a code example, but didn’t go deep enough to really explain it clearly. And to be fair, as the book stated, explaining AOP was well beyond the scope of the book, which I fully agree with. But I think that it would have been better to scale back the attempted explanation if it wasn’t going to give a thorough explanation.

All in all though, this is (by far) my favorite .Net specific development book (and I’ve read quite a few!). It offers a lot of practical advice that you can should start applying right away. It hasn’t been released yet, but is available from Manning via their Early Access program. If you’re a .Net developer, regardless of whether or not you’re working on Brownfield applications, I’d highly recommend it!

Share/Save/Bookmark

Comparing Design Patterns in Ruby and C#: The Command Pattern (with Robots!)

Filed Under (.Net, Ruby) by John Miller on 28-08-2009

Tagged Under : , , ,

The command pattern is another one of those patterns that we all (whether we realize it or not) see almost every day. It’s commonly used in UI development but it’s a pattern that can be applied in many situations. In rails, ActiveRecord migrations are a perfect example of a command implementation, including “up” and “down” methods for applying and rolling back a migration respectively.

The beauty of the command pattern is it’s ability to encapsulate complicated logic into an easy to use interface. This usually includes:

  1. An ICommand interface or base class that defines the command structure
  2. Concrete command implementations
  3. A receiver that is fed commands to execute. When these commands are actually executed is completely independent of when the receiver is given the commands. It may choose to execute them right away, but it may just as well decide to hold on to them for later use.

Source Code

All of the code in this example is available to download:

Download the Source

Or, you can pull the source directly from github using the below clone url:

git://github.com/johnmiller/CommandPattern.git

Example Overview

The example below involves a robot that moves around on a XY plane similar to:

XYPlane

The robot is given starting coordinates and moves from there. However, it can only perform certain actions:

  1. Move forward
  2. Turn left
  3. Turn right
  4. Reset

As it is given commands, it stores them in an internal collection. If reset is called, it “undo’s” all the commands executed to that point.

C# Example

The ICommand is pretty simple and only includes two method declarations: Execute() and Undo(). All of our concrete commands will need to implement this interface.


public interface ICommand
{
void Execute();
void Undo();
}

Before we create any concrete command classes, let’s take a look at our Robot class. When a new robot is created, we give it a starting location and direction. Notice that when a user calls ExecuteCommand() it immediately performs the instructions given and then stores the command in an internal list. If Reset() is called it iterates through the list in reverse order and calls Undo() on each.


public class Robot
{
public Location Position { get; set; }
public string Direction { get; set; }
private IList<ICommand> _commandsExecuted = new List<ICommand>();

public Robot(Location position, string direction)
{
Position = position;
Direction = direction;
}

public void ExecuteInstruction(ICommand command)
{
command.Execute();
_commandsExecuted.Add(command);
}

public void Reset()
{
foreach (var command in _commandsExecuted.Reverse())
command.Undo();
}
}

The Robot.Position property is of type Location which is a simple class holding the X and Y coordinates.


public class Location
{
public int X { get; set; }
public int Y { get; set; }

public Location(int x, int y)
{
X = x;
Y = y;
}
}

The first command we’ll look at is the MoveForwardCommand which…moves the robot forward one space. But we need to be sure that the robot is moving forward in the direction that it is facing. Internally it contains a list of algorithms for moving the robot depending on the based on it’s current direction. It can also go backwards if Undo() is called.


public class MoveForwardCommand : ICommand
{
private Robot _robot;
private IDictionary<string, Action<Robot>> _moveActions;

public MoveForwardCommand(Robot robot)
{
_robot = robot;
_moveActions = new Dictionary<string, Action<Robot>>
{
{"N", r => r.Position.Y += 1 },
{"E", r => r.Position.X += 1 },
{"S", r => r.Position.Y -= 1 },
{"W", r => r.Position.X -= 1 }
};
}

public void Execute()
{
_moveActions[_robot.Direction](_robot);
}

public void Undo()
{
var oppositeDirection = Compass.GetOppositeDirection(_robot.Direction);
_moveActions[oppositeDirection](_robot);
}
}

The Undo() method uses a class called Compass to find the backwards direction. This is a simple utility class to aid in finding left, right, and opposite directions. To find the direction to the right or left, we find the current direction’s place in the list and move accordingly. Although we need to ensure that when asked to turn right when facing west, it moves to the start of the list to get north (the opposite holds true when turning left when facing north).


public class Compass
{
private static IList<string> _directions = new List<string>{"N", "E", "S", "W"};

public static string GetRightTurnDirection(string direction)
{
if (direction == _directions[3]) return _directions[0];

return _directions[_directions.IndexOf(direction) + 1];
}

public static string GetLeftTurnDirection(string direction)
{
if (direction == _directions[0]) return _directions[3];

return _directions[_directions.IndexOf(direction) - 1];
}

public static string GetOppositeDirection(string direction)
{
var directionToTheRight = GetRightTurnDirection(direction);
return GetRightTurnDirection(directionToTheRight);
}
}

The next set of commands we’ll create will allow the robot to turn left and right. This doesn’t change the space the robot is on, only the direction that it is looking.


public class TurnLeftCommand : ICommand
{
private Robot _robot;

public TurnLeftCommand(Robot robot)
{
_robot = robot;
}

public void Execute()
{
_robot.Direction = Compass.GetLeftTurnDirection(_robot.Direction);
}

public void Undo()
{
_robot.Direction = Compass.GetRightTurnDirection(_robot.Direction);
}
}

public class TurnRightCommand : ICommand
{
private Robot _robot;

public TurnRightCommand(Robot robot)
{
_robot = robot;
}

public void Execute()
{
_robot.Direction = Compass.GetRightTurnDirection(_robot.Direction);
}

public void Undo()
{
_robot.Direction = Compass.GetLeftTurnDirection(_robot.Direction);
}
}

Last, let’s take a look at a unit test that puts the robot to work (the source code linked to earlier in the post includes a lot more unit tests if you’re interested in seeing more!).


[TestFixture]
public class When_a_robot_is_given_multiple_commands
{
private Robot _robot;

[SetUp]
public void EstablishContext()
{
_robot = new Robot(new Location(5, 5), "W");
_robot.ExecuteInstruction(new TurnLeftCommand(_robot));
_robot.ExecuteInstruction(new TurnLeftCommand(_robot));
_robot.ExecuteInstruction(new MoveForwardCommand(_robot));
_robot.ExecuteInstruction(new TurnRightCommand(_robot));
_robot.ExecuteInstruction(new MoveForwardCommand(_robot));
_robot.ExecuteInstruction(new TurnRightCommand(_robot));
_robot.ExecuteInstruction(new MoveForwardCommand(_robot));
_robot.ExecuteInstruction(new MoveForwardCommand(_robot));
_robot.ExecuteInstruction(new TurnRightCommand(_robot));
}

[Test]
public void Should_end_up_at_the_expected_location()
{
Assert.That(_robot.Position.X, Is.EqualTo(4));
Assert.That(_robot.Position.Y, Is.EqualTo(4)); ;
}

[Test]
public void Should_be_facing_the_expected_direction()
{
Assert.That(_robot.Direction, Is.EqualTo("N"));
}

[Test]
public void Should_be_able_to_undo_the_command()
{
_robot.Reset();
Assert.That(_robot.Position.X, Is.EqualTo(5));
Assert.That(_robot.Position.Y, Is.EqualTo(5));
Assert.That(_robot.Direction, Is.EqualTo("W"));
}
}

Ruby Example

With ruby we won’t need to create an abstraction for our command objects, so we’ll jump right into creating our Robot object. Besides basic syntax differences, this is very similar to our C# implementation.


class Robot
attr_accessor :position, :direction

def initialize(position, direction)
@position = position
@direction = direction
@commands_executed = []
end

def execute_instruction(command)
command.execute
@commands_executed << command
end

def reset
@commands_executed.reverse_each{|x| x.undo}
end
end

It also uses a custom Location class to store X and Y coordinates.


class Location
attr_accessor :x, :y

def initialize(x, y)
@x = x
@y = y
end
end

Next up is the MoveForwardCommand. The @move_action variable contains a hash of Proc objects which contain the logic for moving the robot. Note that we use the “call” method to run the proc.


class MoveForwardCommand
def initialize(robot)
@robot = robot
@move_actions = {:N => Proc.new{|r| r.position.y += 1},
:E => Proc.new{|r| r.position.x += 1},
:S => Proc.new{|r| r.position.y -= 1},
:W => Proc.new{|r| r.position.x -= 1}}
end

def execute
@move_actions[@robot.direction].call @robot
end

def undo
opposite_direction = Compass.get_opposite_direction @robot.direction
@move_actions[opposite_direction].call @robot
end
end

Like our C# example, we make use of a custom Compass class to help find our directions. I really like the explicit “first” and “last” properties that come with the array object, seems to make the code a little easier to read.


class Compass
@directions = [:N, :E, :S, :W]

def self.get_right_turn_direction(direction)
return @directions.first if direction == @directions.last
@directions[@directions.index(direction) + 1]
end

def self.get_left_turn_direction(direction)
return @directions.last if direction == @directions.first
@directions[@directions.index(direction) - 1]
end

def self.get_opposite_direction(direction)
direction_to_the_right = get_right_turn_direction direction
get_right_turn_direction direction_to_the_right
end
end

And our commands to allow the robot to turn left and right.


class TurnLeftCommand
def initialize(robot)
@robot = robot
end

def execute
@robot.direction = Compass.get_left_turn_direction @robot.direction
end

def undo
@robot.direction = Compass.get_right_turn_direction @robot.direction
end
end

class TurnRightCommand
def initialize(robot)
@robot = robot
end

def execute
@robot.direction = Compass.get_right_turn_direction @robot.direction
end

def undo
@robot.direction = Compass.get_left_turn_direction @robot.direction
end
end

Last we’ll take a look at a unit test to that puts the robot through it’s paces. (There are also many more tests in the source code download if you’d like see more examples).


describe "When asked to perform multiple commands" do
before(:each) do
@robot = Robot.new Location.new(5,5), :W
@robot.execute_instruction TurnLeftCommand.new(@robot)
@robot.execute_instruction TurnLeftCommand.new(@robot)
@robot.execute_instruction MoveForwardCommand.new(@robot)
@robot.execute_instruction TurnRightCommand.new(@robot)
@robot.execute_instruction MoveForwardCommand.new(@robot)
@robot.execute_instruction TurnRightCommand.new(@robot)
@robot.execute_instruction MoveForwardCommand.new(@robot)
@robot.execute_instruction MoveForwardCommand.new(@robot)
@robot.execute_instruction TurnRightCommand.new(@robot)
end

it "should end up at the expected location" do
@robot.position.x.should == 4
@robot.position.y.should == 4
end

it "should be facing the expected direction" do
@robot.direction.should == :N
end

it "should be able to undo all of the commands" do
@robot.reset
@robot.position.x.should == 5
@robot.position.y.should == 5
@robot.direction.should == :W
end
end

In our next post we’ll take a look at how we can solve the same problem using the State pattern!

kick it on DotNetKicks.com

Share/Save/Bookmark

Comparing Design Patterns in Ruby and C#: The Iterator Pattern

Filed Under (.Net, Ruby) by John Miller on 05-08-2009

Tagged Under : , , ,

Continuing our exploration of design patterns in Ruby and C#, we’re going to dive into the Iterator pattern. Like most design patterns, if you google (or bing) for an example you will run into several different implementations because there are many ways to iterate a collection of objects. In it’s classic (well, classing in the .Net\Java sense) form, the pattern is made of:

  1. An interface defining the iterator. This typically involves two methods: HasNext() and MoveNext().
  2. An concrete iterator implementation
  3. An interface defining an enumerable collection. The only method really needed here would be GetIterator() which will return the iterator object.
  4. A concrete enumerable implementation.

The book Design Patterns in Ruby actually defines that type of implementation as an external iterator. This form gives you a type of hook into the collection that allows you to pull out an object one at a time and work with it externally, away from the insides of the collection. The other type of implementation that it describes is an internal iterator. This form involves a method that passes logic (think anonymous method in C# or code block in Ruby) into a method on the collection. The collection then internally iterates through it’s items and applies the logic on each item. This is a very common way of working with collections in Ruby and is slowly building adoption in C#. As we work through the examples below, we’ll take a look at both external and internal implementations.

The following examples will consist of a used car sales lot which will consist of a collection of vehicles.

C# Example - External Iterator From Scratch

First off, let’s create a basic Vehicle object.


public class Vehicle
{
    public string Name { get; set; }

    public Vehicle(string name)
    {
        Name = name;
    }
}

Our next step is to create an ISimpleIterator interface which we’re going to make generic so we aren’t tied to a specific type of object. It really only needs two methods, HasNext() which will let us know if we’ve reached the end of the collection, and MoveNext() which will return the item in the next position.


public interface ISimpleIterator<T>
{
    bool HasNext();
    T MoveNext();
}

And now we’ll create a concrete implementation of the iterator.


public class SimpleIterator<T> : ISimpleIterator<T>
{
    private int _position = 0;
    private T[] _items;

    public SimpleIterator(T[] items)
    {
        _items = items;
    }

    public bool HasNext()
    {
        return _position < _items.Length;
    }

    public T MoveNext()
    {
        var item = _items[_position];
        _position++;
        return item;
    }
}

Next, let’s create our ISimpleEnumerable interface. We’ll keep this one generic as well since there’s no reason to lock it into only Vehicle objects. Note that it only needs one method that will return a generic ISimpleIterator.


public interface ISimpleEnumerable<T>
{
    ISimpleIterator<T> GetIterator();
}

And our enumerable object will be a SalesLot entity. The GetIterator() method will return a strongly typed vehicle iterator.


public class SalesLot : ISimpleEnumerable<Vehicle>
{
    private Vehicle[] _vehicles = {
                                     new Vehicle("Toyota Camry"),
                                     new Vehicle("Jeep Grand Cherokee"),
                                     new Vehicle("Honda CRV")
                                 };

    public ISimpleIterator<Vehicle> GetIterator()
    {
        return new SimpleIterator<Vehicle>(_vehicles);
    }
}

Let’s see what this code would actually look like if we tried to run it. All we have to do is grab the iterator and wrap it in a while loop.


var salesLot = new SalesLot();
var vehiclesIterator = salesLot.GetIterator();

while (vehiclesIterator.HasNext())
    Console.WriteLine(vehiclesIterator.MoveNext().Name);

Output:

Toyota Camry
Jeep Grand Cherokee
Honda CRV

C# Example - External Iterator Using Built-In IEnumerable Interface

Our design can be hugely simplified by using the IEnumerable interface from the base class library. In the below code sample, our SalesLot object no longer returns an ISimpleIterator, instead it’s passes back a IEnumerator which is also built in the .Net framework. The two GetEnumerator() methods are all that’s needed to fulfill the IEnumerable interface contract. And since all built-in collections implement this interface, we can easily pass that call to the inner list.


public class SalesLot : IEnumerable<Vehicle>
{
    private IEnumerable<Vehicle> _vehicles = new List<Vehicle> {
                                     new Vehicle("Toyota Camry"),
                                     new Vehicle("Jeep Grand Cherokee"),
                                     new Vehicle("Honda CRV")
                                 };

    public IEnumerator<Vehicle> GetEnumerator()
    {
        return _vehicles.GetEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }
}

And using it is just as easy as our earlier example.


var salesLot = new SalesLot();
var enumerator = salesLot.GetEnumerator();

while (enumerator.MoveNext())
    Console.WriteLine(enumerator.Current.Name);

And any class that implements the IEnumerable interface is also able to be iterated over using the foreach construct.


var salesLot = new SalesLot();

foreach (var vehicle in salesLot)
    Console.WriteLine(vehicle.Name); 

C# Example - Adding an Internal Iterator to the SalesLot Class

The previous examples all used external iterators to navigate the collection of cars. But we could have easily used an internal iterator as well. To do this, we need to add a method to the SalesLot object that will allow us to pass in an anonymous method or lambda expression to apply to each vehicle in the collection.


public class SalesLot
{
    private IEnumerable<Vehicle> _vehicles = new List<Vehicle> {
                                     new Vehicle("Toyota Camry"),
                                     new Vehicle("Jeep Grand Cherokee"),
                                     new Vehicle("Honda CRV")
                                 };

    public void ForEach(Action<Vehicle> action)
    {
        foreach (var vehicle in _vehicles)
            action(vehicle);
    }
}

And using it becomes just a couple lines of code.


var salesLot = new SalesLot();
salesLot.ForEach(vehicle => Console.WriteLine(vehicle.Name));

C# Example - Internal Iterator Using the Built-In ForEach List Extension Method

With the addition of Linq, we were given a ForEach extension method on generic lists. Using it is exactly the same as our hand-rolled example.


var salesLot = new List<Vehicle> {
                             new Vehicle("Toyota Camry"),
                             new Vehicle("Jeep Grand Cherokee"),
                             new Vehicle("Honda CRV")
                         };

salesLot.ForEach(vehicle => Console.WriteLine(vehicle.Name));

Ruby Example - External Iterator From Scratch

To get started with our Ruby examples, we’ll create our Vehicle object.


class Vehicle
  attr_accessor :name

  def initialize(name)
    @name = name
  end
end

And since Ruby suports duck-typing, we don’t need to create an abstract class or interface to define our iterator. We just need to make sure it has the appropriate methods. Notice that our functions that return a value (such as has_next or move_next) do not need to include the “return” keyword. In Ruby the last line of a mehod is the return value.


class SimpleIterator
  def initialize(items)
    @items = items
    @position = 0
  end

  def has_next
    @position < @items.length
  end

  def move_next
    item = @items[@position]
    @position += 1
    item
  end
end

We are also free to go ahead with creating the SalesLot class without defining an Enumerable abstraction as long as we include a get_iterator method that returns a SimpleIterator.


class SalesLot
  def initialize
    @vehicles = [Vehicle.new("Toyota Camry"), Vehicle.new("Jeep Grand Cherokee"), Vehicle.new("Honda CRV")]
  end

  def get_iterator
    SimpleIterator.new(@vehicles)
  end
end

Actually using the class is very similiar to the C# example.


sales_lot = SalesLot.new
vehicle_iterator = sales_lot.get_iterator

while vehicle_iterator.has_next
  puts vehicle_iterator.move_next.name
end

Output:

Toyota Camry
Jeep Grand Cherokee
Honda CRV

Ruby Example - Creating an Internal Iterator Using the Enumerable Module

While external iterators have their place, Rubyists tend to favor using internal iterators when working with collections. We could easily tack on our own for_each method to the SalesLot object (as we did in the C# example) but instead let’s jump straight into some of the cool things we can leverage in the library. Ruby ships with a handy module called Enumerable that we can include on our SalesLot object which will give us a lot of functionality for free. To use it, we just need to include the Enumerator module and add an “each” method that accepts a code block.


class SalesLot
  include Enumerable

  def initialize
    @vehicles = [Vehicle.new("Toyota Camry"), Vehicle.new("Jeep Grand Cherokee"), Vehicle.new("Honda CRV")]
  end

  def each(&amp;amp;amp;amp;amp;block)
    @vehicles.each(&amp;amp;amp;amp;amp;block)
  end
end

To be able to take advantage of the features given to us from the Enumerable module, our Vehicle needs to add a method defining the “<=>” comparison operator. This method accepts another Vehicle record to compare to and will return -1, 0, or 1 depending on whether the receiver is less than, equal to, or greater than the vehicle being passed in as an argument. For those of you familiar with the IComparable interface in .Net, this works exactly the same way.


class Vehicle
  attr_accessor :name

  def initialize(name)
    @name = name
  end

  def <=>(other)
    @name <=> other.name
  end
end

And now we can iterate through our collection in just a couple of lines.


sales_lot = SalesLot.new
sales_lot.each {|vehicle| puts vehicle.name}

But that’s just the tip of the iceberg. We are given a lot of added functionality that allows us to search and sort vehicles in the sales lot.


sales_lot.include? "Ford Escape"
sales_lot.find_all {|vehicle| vehicle.name.length > 12}
sales_lot.sort

And this functionality is available when working with arrays which allows us to do a lot of work with our collections without having to write much code.


vehicles = [Vehicle.new("Toyota Camry"), Vehicle.new("Jeep Grand Cherokee"), Vehicle.new("Honda CRV")]
vehicles.each {|vehicle| puts vehicle.name}

While the iterator pattern may look complex in it’s natural form, both Ruby and C# give us a lot of capabilities out of the box. Neither need much (if any) customization to do advanced work with collections.

Next time, we’ll check out the Command pattern!

kick it on DotNetKicks.com

Share/Save/Bookmark

Comparing Design Patterns in Ruby and C#: The Composite Pattern

Filed Under (.Net, Ruby) by John Miller on 22-07-2009

Tagged Under : , , ,

In the last post of the series, we took a look at the Observer pattern. This time we’re going to explore the Composite pattern. The Composite pattern gives us the ability to take a complex procedure that may involve many steps and turn it into something that is simple for consumers to use.

The classic definition of the Composite pattern involves three pieces: Component, Leaf, and Composite Component. The component defines the interface that the units (leaves and\or composite components) must implement. A leaf is an implementation of a component that performs work. The composite component also implements the component interface but that’s where the similarities end. Under the covers, it contains a collection of components which could be leaves on nested composites. When an interface method is called, it delegates the call to it’s child components. This may sound more complicated than it actually is. Let’s take a look at an example to see how this could work.

C# Example

In this example, we’re going to take the process of changing a car’s oil and break it down to a group of independent tasks. Following our definition above, let’s define an IComponent interface. Per the contract of this interface, all of our “task” objects will need to include a PerformTask() method.


public interface IComponent
{
    void PerformTask();
}

Next, we’re going to create a base class for the tasks that are made up of a collection of child tasks. Notice that although it implements the PerformTask() method of the IComponent interface, it actually delegates the work to it’s child components.


public abstract class CompositeComponent : IComponent
{
    private IList<IComponent> _tasks = new List<IComponent>();

    public void PerformTask()
    {
        foreach (var task in _tasks)
            task.PerformTask();
    }

    public void AddTask(IComponent task)
    {
        _tasks.Add(task);
    }

    public void RemoveTask(IComponent task)
    {
        _tasks.Remove(task);
    }
}

Now let’s create our first needed task (aka. leaf). This one represents the draining of the old oil in the vehicle.


public class DrainOldOilTask : IComponent
{
    public void PerformTask()
    {
        Console.WriteLine("Draining old oil.");
    }
}

The next step is to replace the oil filter which is made of two steps, removing the old filter and installing the new one. To demonstrate this, we’ll create a new CompositeComponent subclass.


public class RemoveOldFilterTask : IComponent
{
    public void PerformTask()
    {
        Console.WriteLine("Removing old filter.");
    }
}

public class InstallNewFilterTask : IComponent
{
    public void PerformTask()
    {
        Console.WriteLine("Installing new filter.");
    }
}

public class ReplaceFilterTask : CompositeComponent
{
    public ReplaceFilterTask()
    {
        AddTask(new RemoveOldFilterTask());
        AddTask(new InstallNewFilterTask());
    }
}

Last, we need to create a task for adding the new oil as well as a composite “ChangeOil” task that ties it all together. Notice that the ChangeOil object is composed of both regular tasks (DrainOilTask and AddNewOilTask) as well as a composite task (ReplaceFilterTask).


public class AddNewOilTask : IComponent
{
    public void PerformTask()
    {
        Console.WriteLine("Adding new oil.");
    }
}

public class ChangeOil : CompositeComponent
{
    public ChangeOil()
    {
        AddTask(new DrainOldOilTask());
        AddTask(new ReplaceFilterTask());
        AddTask(new AddNewOilTask());
    }
}

Now the entire process is a simple method call.


new ChangeOil().PerformTask();

Output
Draining old oil.
Removing old filter.
Installing new filter.
Adding new oil.

Ruby Example

With Ruby, we no longer need to define a component interface. We just need ensure that our classes define a perform_work() method. We will, however, want to create a base class for our composite components.


class CompositeComponent
  def initialize
    @tasks = []
  end

  def perform_task
    @tasks.each {|task| task.perform_task}
  end

  def add_task(task)
    @tasks << task
  end

  def remove_task(task)
    @tasks.delete task
  end
end

Now we’ll create our task objects. Besides basic syntax, the structure of these classes are pretty much the same C# versions.


class DrainOldOilTask
  def perform_task
    puts "Draining old oil."
  end
end

class RemoveOldFilterTask
  def perform_task
    puts "Removing old filter."
  end
end

class InstallNewFilterTask
  def perform_task
    puts "Installing new filter."
  end
end

class ReplaceFilterTask < CompositeComponent
   def initialize
     super
     add_task RemoveOldFilterTask.new
     add_task InstallNewFilterTask.new
   end
end

class AddNewOilTask
  def perform_task
    puts "Adding new oil."
  end
end

class ChangeOil < CompositeComponent
   def initialize
     super
     add_task DrainOldOilTask.new
     add_task ReplaceFilterTask.new
     add_task AddNewOilTask.new
   end
end

Using the objects is also very much the same.


ChangeOil.new.perform_task

Output
Draining old oil.
Removing old filter.
Installing new filter.
Adding new oil.

As you can see, implementing the pattern in the two languages is pretty similar. The biggest difference is the lack of need for a component interface within the Ruby example.

Next time, we’ll be looking at the Iterator pattern. Stay tuned!

kick it on DotNetKicks.com

Share/Save/Bookmark

Comparing Design Patterns in Ruby and C#: The Observer Pattern

Filed Under (.Net, Ruby) by John Miller on 15-07-2009

Tagged Under : , , ,

Continuing our comparison of design patterns in Ruby and C#, we’re taking a look at the Observer pattern. With this pattern, we have a subject and a list of observers that are interested in knowing when changes occur on the subject. This happens in a push model, the subject maintains the list observers and notifies each when needed.

In our examples, we’re going to create a Vehicle object that contains a couple of key properties, Mileage and MileageAtLastOilChange. When a new Vehicle instance is created both properties start at zero. As the vehicle’s Drive() method is called and miles are added to it, it notifies any known observers. The MilesUntilNextOilChange property lets others know how long the vehicle can be driven until it should get an oil change. When the PerformOilChangeMethod() is called, the MileageAtLastOilChange property is set to the current mileage and registered observers are notified that changes occurred.

We are also going to create a Dashboard object that will let us know how many miles the vehicle can be driven until it needs it’s next oil change as well as a warning message alerting the driver that it needs a oil change when it reaches 3000 miles.

C# Example

First we’ll create our Vehicle object as well as an IVehicleObserver interface that must be implemented by any Vehicle observers. Note that the Vehicle object contains an AddObserver() that allows observers to register themselves with the Vehicle.


using System.Collections.Generic;

namespace DesignPatterns.ObserverPattern
{
    public class Vehicle
    {
        private IList<IVehicleObserver> _observers = new List<IVehicleObserver>();

        public int Mileage { get; private set; }
        public int MileageAtLastOilChange { get; private set; }
        public int MilesUntilNextOilChange { get { return 3000 - (Mileage - MileageAtLastOilChange); } }

        public Vehicle()
        {
            Mileage = 0;
            MileageAtLastOilChange = 0;
        }

        public void Drive(int miles)
        {
            Mileage += miles;
            NotifyObservers();
        }

        public void PerformOilChange()
        {
            MileageAtLastOilChange = Mileage;
            NotifyObservers();
        }

        public void AddObserver(IVehicleObserver observer)
        {
            _observers.Add(observer);
        }

        private void NotifyObservers()
        {
            foreach (var observer in _observers)
                observer.Notify(this);
        }
    }
}

namespace DesignPatterns.ObserverPattern
{
    public interface IVehicleObserver
    {
        void Notify(Vehicle vehicle);
    }
}

And now we’ll create our Dashboard class which will implement the IVehicleObserver interface. When the Notify() method is called, it updates the Message property to reflect the vehicle’s current status.


namespace DesignPatterns.ObserverPattern
{
    public class Dashboard : IVehicleObserver
    {
        public string Message { get; private set; }

        public Dashboard()
        {
            Message = string.Empty;
        }

        public void Notify(Vehicle vehicle)
        {
            Message = vehicle.MilesUntilNextOilChange <= 0
                      ? "Time for an oil change!"
                      : string.Format("Next oil change is due in {0} miles.", vehicle.MilesUntilNextOilChange);
        }
    }
}

Let’s take a look at how these two will work together.


var dashboard = new Dashboard();
var vehicle = new Vehicle();

vehicle.AddObserver(dashboard);

vehicle.Drive(2000);
Console.WriteLine(dashboard.Message);

vehicle.Drive(1500);
Console.WriteLine(dashboard.Message);

vehicle.PerformOilChange();
Console.WriteLine(dashboard.Message);

vehicle.Drive(1000);
Console.WriteLine(dashboard.Message);

Ruby Example

The Ruby example really isn’t that much unlike the C# version. The big difference is that we don’t need to create an IVehicleObserver interface, we just need to make sure our Dashboard object has a “notify” method that accepts a Vehicle object.


class Vehicle
  attr_reader :mileage, :mileage_at_last_oil_change

  def initialize
    @mileage = 0
    @mileage_at_last_oil_change = 0
    @observers = []
  end

  def drive(miles)
    @mileage += miles
    notify_observers
  end

  def miles_until_next_oil_change
    3000 - (@mileage - @mileage_at_last_oil_change)
  end

  def perform_oil_change
    @mileage_at_last_oil_change = @mileage
    notify_observers
  end

  def add_observer(observer)
    @observers << observer
  end

  private

  def notify_observers
    @observers.each {|observer| observer.notify self}
  end
end

class Dashboard
  attr_reader :message

  def initialize
    @message = ""
  end

  def notify(vehicle)
    @message = vehicle.miles_until_next_oil_change <= 0 ?
                "Time for an oil change!" :
                "Next oil change is due in #{vehicle.miles_until_next_oil_change} miles."
  end
end

And using the objects is very similiar to the C# example as well.


require "dashboard"
require "vehicle"

dashboard = Dashboard.new
vehicle = Vehicle.new

vehicle.add_observer dashboard

vehicle.drive 2000
puts dashboard.message

vehicle.drive 1500
puts dashboard.message

vehicle.perform_oil_change
puts dashboard.message

vehicle.drive 1000
puts dashboard.message

Simplifying Our Objects

Both languages have built-in mechanisms that we can take advantage of that can make implementing the Observer pattern easy.

In .Net, we’re given out-of-the-box event handling. We just need to create a delegate that defines the method our observers will use for receiving notifications. This reduces the need for an IVehicleObserver interface and simplifies our design.


public delegate void MilesChangedHandler(Vehicle vehicle);

public class Vehicle
{
    public int Mileage { get; private set; }
    public int MileageAtLastOilChange { get; private set; }
    public int MilesUntilNextOilChange { get { return 3000 - (Mileage - MileageAtLastOilChange); } }
    public event MilesChangedHandler MilesChangedEvent;

    public Vehicle()
    {
        Mileage = 0;
        MileageAtLastOilChange = 0;
    }

    public void Drive(int miles)
    {
        Mileage += miles;
        NotifyObservers();
    }

    public void PerformOilChange()
    {
        MileageAtLastOilChange = Mileage;
        NotifyObservers();
    }

    private void NotifyObservers()
    {
        if (MilesChangedEvent != null)
            MilesChangedEvent(this);
    }
}

And no changes have to be made to our Dashboard object.


public class Dashboard : IVehicleObserver
{
    public string Message { get; private set; }

    public Dashboard()
    {
        Message = string.Empty;
    }

    public void Notify(Vehicle vehicle)
    {
        Message = vehicle.MilesUntilNextOilChange <= 0
                             ? "Time for an oil change!"
                             : string.Format("Next oil change is due in {0} miles.", vehicle.MilesUntilNextOilChange);
    }
}

Using the classes changes a bit, note how we subscribe to event on the Vehicle object.


var dashboard = new Dashboard();
var vehicle = new Vehicle();

vehicle.MilesChangedEvent += dashboard.Notify;

vehicle.Drive(2000);
Console.WriteLine(dashboard.Message);

vehicle.Drive(1500);
Console.WriteLine(dashboard.Message);

vehicle.PerformOilChange();
Console.WriteLine(dashboard.Message);

vehicle.Drive(1000);
Console.WriteLine(dashboard.Message);

Ruby also has some built goodness to make our work a little easier. We are actually given an Observable module that we can add to our Vehicle class that will handle the adding, removing, and notifying of observers. The only minor addition we need to add to our object is the a call to the “changed” method when we want to indicate that our object’s state has changed.


require "observer"

class Vehicle
  include Observable

  attr_reader :mileage, :mileage_at_last_oil_change

  def initialize
    @mileage = 0
    @mileage_at_last_oil_change = 0
    @observers = []
  end

  def drive(miles)
    @mileage += miles
    changed
    notify_observers self
  end

  def miles_until_next_oil_change
    3000 - (@mileage - @mileage_at_last_oil_change)
  end

  def perform_oil_change
    @mileage_at_last_oil_change = @mileage
    changed
    notify_observers self
  end
end

To use the module, our observers have to have an “update” method so we’ll need to rename our “notify” method on the Dashboard object.


class Dashboard
  attr_reader :message

  def initialize
    @message = ""
  end

  def update(vehicle)
    @message = vehicle.miles_until_next_oil_change <= 0 ?
                "Time for an oil change!" :
                "Next oil change is due in #{vehicle.miles_until_next_oil_change} miles."
  end
end

And our usage stays exactly the same!


require "dashboard"
require "vehicle"

dashboard = Dashboard.new
vehicle = Vehicle.new

vehicle.add_observer dashboard

vehicle.drive 2000
puts dashboard.message

vehicle.drive 1500
puts dashboard.message

vehicle.perform_oil_change
puts dashboard.message

vehicle.drive 1000
puts dashboard.message

That’s it for the Observer pattern, next time we’ll take a look at the Composite pattern.

kick it on DotNetKicks.com

Share/Save/Bookmark

Comparing Design Patterns in Ruby and C#: The Strategy Pattern

Filed Under (.Net, Ruby) by John Miller on 03-07-2009

Tagged Under : , , ,

In the previous post of this series, we looked at how the Template pattern is implemented in both Ruby and C#. In this post, we’ll take a look at the Strategy pattern…one of my favorites.

In it’s classic form, the Strategy pattern consists of a context class and various “strategies” which share a common interface. The context class is given a strategy to which it can delegate work to. Think of it as passing an algorithm to a class. To change the way the class works, change the algorithm you feed it. This makes it really easy to adhere to the open-closed principle which states that an object should be open for extension but closed for modification. We can drastically change how our class operates without changing a line of code in the class itself.

In .Net, the Sort method on generic lists is a perfect example of how the Strategy pattern can be applied. To change how the list is sorted, you simply pass in a method that matches the Comparison<T> delegate or a class that implements IComparer<T>. (See my earlier post on the various ways you can sort a generic list in .Net).

Ruby has a really cool example built in as well with it’s rdoc utility which uses strategies both for distilling documentation from various languages (C, Ruby, etc) and in how it ouputs the documentation (HTML, XML, CHM).

In our examples below, we’re creating a Driver object that has three different properties: DrivingHabit, MilesDriven, and SpeedingTickets. It also has a method “Drive” which accepts the number of hours that the driver should drive as a parameter. The Drive method delegates the actual "driving” logic to the driving habit that it is composed with. A cautious driver follows the speed limit (55mph) and never gets a speeding ticket. A reckless driver, however, travels along at 80mph and gets a speeding ticket every 1/2 hour.

C# Example

For the Strategy pattern to work in a static language, we must first define a contract that the strategies themselves must adhere to as well as the context class. So we’ll start by creating the Driver object and defining the IDrivingHabit interface.


namespace DesignPatterns.StategyPattern
{
    public class Driver
    {
        public IDrivingHabit DrivingHabit { get; set; }
        public int MilesDriven { get; set; }
        public int SpeedingTickets { get; set; }

        public Driver(IDrivingHabit drivingHabit)
        {
            DrivingHabit = drivingHabit;
        }

        public void Drive(int hours)
        {
            DrivingHabit.Drive(this, hours);
        }
    }
}

namespace DesignPatterns.StategyPattern
{
    public interface IDrivingHabit
    {
        void Drive(Driver driver, int duration);
    }
}

Now let’s create our strategies.


namespace DesignPatterns.StategyPattern
{
    public class CautiousDrivingHabit : IDrivingHabit
    {
        public void Drive(Driver driver, int hours)
        {
            driver.MilesDriven =  hours * 55;
        }
    }
}

namespace DesignPatterns.StategyPattern
{
    public class RecklessDrivingHabit : IDrivingHabit
    {
        public void Drive(Driver driver, int hours)
        {
            driver.MilesDriven += hours * 80;
            driver.SpeedingTickets += hours * 2;
        }
    }
}

And to see how this would actually be used, we’ll take a look at the unit tests.


using NUnit.Framework;

namespace DesignPatterns.StategyPattern
{
    [TestFixture]
    public class When_a_cautious_driver_is_on_the_road_for_3_hours
    {
        private Driver granny;

        [SetUp]
        public void EstablishContext()
        {
            granny = new Driver(new CautiousDrivingHabit());
            granny.Drive(3);
        }

        [Test]
        public void Should_move_a_total_of_165_miles()
        {
            Assert.That(granny.MilesDriven, Is.EqualTo(165));
        }

        [Test]
        public void Should_not_receive_any_speeding_tickets()
        {
            Assert.That(granny.SpeedingTickets, Is.EqualTo(0));
        }
    }

    [TestFixture]
    public class When_a_reckless_driver_is_on_the_road_for_3_hours
    {
        private Driver speedRacer;

        [SetUp]
        public void EstablishContext()
        {
            speedRacer = new Driver(new RecklessDrivingHabit());
            speedRacer.Drive(3);
        }

        [Test]
        public void Should_move_a_total_of_240_miles()
        {
            Assert.That(speedRacer.MilesDriven, Is.EqualTo(240));
        }

        [Test]
        public void Should_receive_a_speeding_ticket_for_every_half_hour_on_the_road()
        {
            Assert.That(speedRacer.SpeedingTickets, Is.EqualTo(6));
        }
    }
}

Pretty simple, eh? Let’s take a look at how we would do this in Ruby.

Ruby Example

First, we’ll create the Driver object. So far doesn’t seem that much different from the C# example.


class Driver
  attr_accessor :driving_habit, :miles_driven, :speeding_tickets

  def initialize(driving_habit)
    @driving_habit = driving_habit
    @miles_driven = 0
    @speeding_tickets = 0
  end

  def drive(hours)
    @driving_habit.drive self, hours
  end
end

Next we’re going to jump straight into creating our Strategy classes. Since Ruby supports duck typing, we really have no need to create an object that defines what our strategies should look like. We could define a base DrivingHabit object that included a Drive method that we can override in our implementations, but that would be producing extra code for no added benefit. We’re ok as long as the object we pass in has a Drive method that matches the required signature.


class CautiousDrivingHabit
  def drive(driver, hours)
    driver.miles_driven += hours * 55
  end
end

require 'lib/driver'

class RecklessDrivingHabit
  def drive(driver, hours)
    driver.miles_driven += hours * 80
    driver.speeding_tickets += hours * 2
  end
end

And now we’ll take a look at the corresponding unit tests.


require 'lib/cautious_driving_habit'

describe "When a cautious driver is on the road for 3 hours" do
  before(:each) do
    @granny = Driver.new(CautiousDrivingHabit.new)
    @granny.drive 3
  end

  it "should move a total of 165 miles" do
    @granny.miles_driven.should == 165
  end

  it "should not receive any speeding tickets" do
    @granny.speeding_tickets.should == 0
  end
end

require 'lib/reckless_driving_habit'

describe "When a reckless driver is on the road for 3 hours" do
  before(:each) do
    @speed_racer = Driver.new(RecklessDrivingHabit.new)
    @speed_racer.drive 3
  end

  it "should move a total of 240 miles" do
    @speed_racer.miles_driven.should == 240
  end

  it "should not receive a speeding ticket for every half hour on the road" do
    @speed_racer.speeding_tickets.should == 6
  end
end

Simplifying the Strategy Pattern

For simple scenarios (such as this one) where the strategies are extremely basic, we can actually reduce the need for the strategy classes themselves. In C#, we just need to add an overloaded Drive method that accepts a delegate that matches the Drive method in the IDrivingHabit interface. (We could have changed the contructor to do this instead.)


public void Drive(int hours, Action<Driver, int> drivingHabit)
{
     drivingHabit(this, hours);
}

And to use it, we pass a lambda expression in that contians our logic.


speedRacer.Drive(3, (driver, hours) =>
                     {
                          driver.MilesDriven += hours*80;
                          driver.SpeedingTickets += hours*2;
                     });

We can do something very similiar in Ruby. We’ll create a new method that accepts a code block as a second parameter. Note that we had to create a new name for this method (Ruby doesn’t support method overloading).


def drive_using_habit(hours, &amp;amp;driving_habit)
 driving_habit.call self, hours
end

And the code using this.


@speed_racer.drive_using_habit(3) do |driver, hours|
    driver.miles_driven += hours * 80
    driver.speeding_tickets += hours * 2
end

In the next post, we’ll take a look at a very similiar pattern, the Observer pattern.

kick it on DotNetKicks.com

Share/Save/Bookmark

Re: An Anemic Community

Filed Under (.Net) by John Miller on 15-06-2009

Tagged Under : ,

Kevin wrote an interesting post in which he expressed his concern for the anemic state of the .Net developer community when compared to that of other communities. I started jotting down a response and saw I was getting carried away so I thought I’d post my thoughts here instead.

I heard a comment a couple months ago that went something like “If you wanna see what cool new features Microsoft will introduce in the next 2-3 years, look at what’s happening in open source today”. This was said half-jokingly but it bears a certain amount of truth to it. NHibernate is a couple of releases ahead of Entity Framework, NUnit is steps beyond MSTest, etc. (Although if ASP.Net MVC is any indication of the future, I think it’s turning in the right direction.)

But it doesn’t sound like Kevin’s beef is really with Microsoft, instead he’s questioning the maturity of the .Net developer community when compared to that of other communities. That’s fair, I would agree that the .Net community is a step behind others. I think this comes down to fundamentals. .Net devs are commonly directed to tools and black-box frameworks to cut their teeth on while many other communities seem to favor learning the basics first. (Obviously this isn’t a blanket statement, there are a plenty of awesome .Net developers that hold good practices near and dear to their heart). There are so many frameworks available in the .Net community that abstract out “the hard stuff” that it’s easy to get by with just focusing on tools alone. And this mindset is reinforced by a job market that puts substantially more weight in tools than it does good software design…which is why it seems that 90% of the job posting in our area are looking for Sharepoint experience and zero have TDD as a prerequisite (although that may be just the Cleveland region, not exactly a hotbed for agile tech). And to be honest, I can’t fault a fella for focusing on tooling when it’s pulling in lucrative work. But our result then is a community of devs so focused on learning how to steer a black-box to fit their needs, that they never take the time to properly learn the basics. And without that solid foundation, it’s extremely difficult to write software that’s clean and maintainable. Ian does a great job in talking about this is a recent post.

For us to see a dramatic uptick in the quality of the software outputted by the community, we need to start by accepting that we don’t need to learn every new tool that comes out of Redmond and instead focus that energy on building our own developer muscles first. (Don’t get me wrong, the tools we use are always going to be an important segment of our arsenal but having a better understanding of the pieces that make up that tool will make it easier for you to learn how to use it effectively as well make you a better judge on whether or not it’s the right fit for the job.)

All that said, I think the community has actually grown quite a bit especially in the last year or so. Much of this is thanks to groups like Alt.Net that have spent a lot of energy to introduce others to these principles. But we all have to do our own part to keep the momentum going. Something as small as blogging every now and then, or mentoring a coworker, or starting a book club can make a profound impact.

DotNetKicks Image

Share/Save/Bookmark

Comparing Design Patterns in Ruby and C#: The Template Pattern

Filed Under (.Net, Ruby) by John Miller on 24-04-2009

Tagged Under : , , ,

Most of my career has been in .Net development and I’m pretty comfortable applying design patterns in C#, but as I’m learning Ruby, I was finding it difficult to figure out how to implement them without creating awkward, hard-to-read code. Recently a local Ruby guru, Nate Klaiber, recommended that I pick up the book Design Patterns in Ruby. Well, he more than recommended it, he actually gave a copy autographed by the author (totally unexpected but very, very appreciated!). He has a thorough review of the book (and many others) on his book review site.

As I read through the book, I’m going to do a series of posts showing examples of how each pattern would be applied in both C# and Ruby. (The book has around a dozen patterns so this will probably take several weeks to get through them all).

The first one we’re going to work through is the Template pattern, which is arguably one of the easiest patterns to learn. The template pattern involves creating a base class with methods that can be overridden by subclasses. The base class itself has a central method that will call the other methods in the object.

In the examples below, we’re going to create two vehicle factory classes, one that creates a vehicle specifically for winter travelling, and another that creates vehicles for summertime cruising.

*Note: I’m certainly no Ruby expert (or C# expert for that matter), but am learning here as I go. If you have a better way to do something, please leave a comment!

C# Example

The template method is all over the .Net framework. A perfect example is ASP.Net’s page lifecycle. You’re given hooks to perform actions during page load, init, etc.

Let’s start by creating our Vehicle class.


using System.Collections.Generic;

namespace DesignPatterns.TemplatePattern
{
    public class Vehicle
    {
        public string SteeringWheel { get; set; }
        public string Tires { get; set; }
        public string Seats { get; set; }
        public string Engine { get; set; }
        public string MakeModel { get; set; }
        public IList<string> Amenities { get; set; }

        public Vehicle()
        {
            Amenities = new List<string>();
        }
    }
}

Next we’ll create our base class. Note that CreateVehicle() is the only public method. The rest are only accessible to objects that derive from this class. And some of the “hook” methods have a default implementation while others are declared abstract and must be overridden by the subclass.


namespace DesignPatterns.TemplatePattern
{
    public abstract class VehicleFactoryBase
    {
        protected Vehicle VehicleUnderConstruction { get; set; }

        protected virtual void AddSteeringWheel()
        {
            VehicleUnderConstruction.SteeringWheel = "Standard Steering Wheel";
        }

        protected virtual void AddTires()
        {
            VehicleUnderConstruction.Tires = "All Season Tires";
        }

        protected virtual void AddSeats()
        {
            VehicleUnderConstruction.Seats = "Cloth Bucket Seats";
        }

        protected virtual void AddAmenities()
        {

        }

        protected abstract void AddEngine();

        protected abstract void AddMakeModel();

        public Vehicle CreateVehicle()
        {
            VehicleUnderConstruction = new Vehicle();
            AddSteeringWheel();
            AddTires();
            AddSeats();
            AddAmenities();
            AddEngine();
            AddMakeModel();
            return VehicleUnderConstruction;
        }
    }
}

Now we’re ready to create our first implementation, a vehicle factory that creates vehicles designed for living in the snow belt.


namespace DesignPatterns.TemplatePattern
{
    public class WinterVehicleFactory : VehicleFactoryBase
    {
        protected override void AddTires()
        {
            VehicleUnderConstruction.Tires = "Snow Tires";
        }

        protected override void AddAmenities()
        {
            VehicleUnderConstruction.Amenities.Add("4 Wheel Drive");
            VehicleUnderConstruction.Amenities.Add("Snow Plow");
        }

        protected override void AddEngine()
        {
            VehicleUnderConstruction.Engine = "4.7L V-8";
        }

        protected override void AddMakeModel()
        {
            VehicleUnderConstruction.MakeModel = "Jeep Grand Cherokee";
        }
    }
}

Our second implementation will be a vehicle factory that creates our summer cruiser.


namespace DesignPatterns.TemplatePattern
{
    public class SummerVehicleFactory : VehicleFactoryBase
    {
        protected override void AddSeats()
        {
            VehicleUnderConstruction.Seats = "Leather Bucket Seats";
        }

        protected override void AddAmenities()
        {
            VehicleUnderConstruction.Amenities.Add("Premium Sound System");
        }

        protected override void AddEngine()
        {
            VehicleUnderConstruction.Engine = "3.7L V6";
        }

        protected override void AddMakeModel()
        {
            VehicleUnderConstruction.MakeModel = "Nissan 370Z Coupe";
        }
    }
}

And finally, below are the unit tests needed to verify both factories creates their vehicles as expected.


using NUnit.Framework;

namespace DesignPatterns.TemplatePattern
{
    [TestFixture]
    public class When_creating_a_winter_vehicle
    {
        private Vehicle winterVehicle;

        [SetUp]
        public void EstablishContext()
        {
            winterVehicle = new WinterVehicleFactory().CreateVehicle();
        }

        [Test]
        public void Should_create_a_Jeep_Grand_Cherokee()
        {
            Assert.That(winterVehicle.MakeModel, Is.EqualTo("Jeep Grand Cherokee"));
        }

        [Test]
        public void Should_have_a_standard_steering_wheel()
        {
            Assert.That(winterVehicle.SteeringWheel, Is.EqualTo("Standard Steering Wheel"));
        }

        [Test]
        public void Should_have_snow_tires()
        {
            Assert.That(winterVehicle.Tires, Is.EqualTo("Snow Tires"));
        }

        [Test]
        public void Should_have_a_V8_engine()
        {
            Assert.That(winterVehicle.Engine, Is.EqualTo("4.7L V-8"));
        }

        [Test]
        public void Should_have_standard_cloth_seats()
        {
            Assert.That(winterVehicle.Seats, Is.EqualTo("Cloth Bucket Seats"));
        }

        [Test]
        public void Should_have_4_wheel_drive()
        {
            Assert.That(winterVehicle.Amenities.Contains("4 Wheel Drive"));
        }

        [Test]
        public void Should_have_a_snow_plow()
        {
            Assert.That(winterVehicle.Amenities.Contains("Snow Plow"));
        }

        [Test]
        public void Should_not_have_any_other_amenities()
        {
            Assert.That(winterVehicle.Amenities.Count, Is.EqualTo(2));
        }
    }
}

using NUnit.Framework;

namespace DesignPatterns.TemplatePattern
{
    [TestFixture]
    public class When_creating_a_summer_vehicle
    {
        private Vehicle summerVehicle;

        [SetUp]
        public void EstablishContext()
        {
            summerVehicle = new SummerVehicleFactory().CreateVehicle();
        }

        [Test]
        public void Should_create_a_Nissan_370Z()
        {
            Assert.That(summerVehicle.MakeModel, Is.EqualTo("Nissan 370Z Coupe"));
        }

        [Test]
        public void Should_have_a_standard_steering_wheel()
        {
            Assert.That(summerVehicle.SteeringWheel, Is.EqualTo("Standard Steering Wheel"));
        }

        [Test]
        public void Should_have_all_season_tires()
        {
            Assert.That(summerVehicle.Tires, Is.EqualTo("All Season Tires"));
        }

        [Test]
        public void Should_have_a_V6_engine()
        {
            Assert.That(summerVehicle.Engine, Is.EqualTo("3.7L V6"));
        }

        [Test]
        public void Should_have_leather_seats()
        {
            Assert.That(summerVehicle.Seats, Is.EqualTo("Leather Bucket Seats"));
        }

        [Test]
        public void Should_have_a_premium_sound_system()
        {
            Assert.That(summerVehicle.Amenities.Contains("Premium Sound System"));
        }

        [Test]
        public void Should_not_have_any_other_amenities()
        {
            Assert.That(summerVehicle.Amenities.Count, Is.EqualTo(1));
        }
    }
}

Ruby Example

Now let’s create the same vehicle class in Ruby. Really impressed with how much smaller this class is!


class Vehicle
  attr_accessor :steering_wheel, :tires, :seats
  attr_accessor :amenities, :engine, :make_model

  def initialize
    @amenities = []
  end
end

Next, we’ll create our base vehicle factory class. It’s worth noting that Ruby doesn’t have an “abstract” keyword. To get the same effect, we’ll raise an exception if an expected method was not overridden in a subclass.


require 'lib/Vehicle'

class VehicleFactoryBase
  def create_vehicle
    @vehicle_under_construction = Vehicle.new
    add_steering_wheel
    add_tires
    add_seats
    add_amenities
    add_engine
    add_make_model
    @vehicle_under_construction
  end

  protected

  def add_steering_wheel
    @vehicle_under_construction.steering_wheel = "Standard Steering Wheel"
  end

  def add_tires
    @vehicle_under_construction.tires = "All Season Tires"
  end

  def add_seats
    @vehicle_under_construction.seats = "Cloth Bucket Seats"
  end

  def add_amenities
  end

  def add_engine
    raise "subclass must include the logic for setting the engine"
  end

  def add_make_model
    raise "subclass must include the logic for setting the make and model"
  end
end

And here’s our first subclass, the winter vehicle factory.


require 'lib/Vehicle'
require 'lib/VehicleFactoryBase'

class WinterVehicleFactory < VehicleFactoryBase
    def add_tires
      @vehicle_under_construction.tires = "Snow Tires"
    end

    def add_amenities
      @vehicle_under_construction.amenities.push "4 Wheel Drive"
      @vehicle_under_construction.amenities.push "Snow Plow"
    end

    def add_engine
      @vehicle_under_construction.engine = "4.7L V-8"
    end

    def add_make_model
      @vehicle_under_construction.make_model = "Jeep Grand Cherokee"
    end
end

Next up is the summer vehicle factory.


require 'lib/Vehicle'
require 'lib/VehicleFactoryBase'

class SummerVehicleFactory < VehicleFactoryBase
    def add_seats
      @vehicle_under_construction.seats = "Leather Bucket Seats"
    end

    def add_amenities
      @vehicle_under_construction.amenities.push "Premium Sound System"
    end

    def add_engine
      @vehicle_under_construction.engine = "3.7L V6"
    end

    def add_make_model
      @vehicle_under_construction.make_model = "Nissan 370Z Coupe"
    end
end

And of course our unit tests.


require 'rubygems'
require "spec"
require 'lib/WinterVehicleFactory'

describe "A newly created vehicle" do
  before(:each) do
    @winter_vehicle = WinterVehicleFactory.new.create_vehicle
  end

  it "should be a Jeep Grand Cherokee" do
    @winter_vehicle.make_model.should == "Jeep Grand Cherokee"
  end

  it "should have a standard steering wheel" do
    @winter_vehicle.steering_wheel.should == "Standard Steering Wheel"
  end

  it "should have snow tires" do
    @winter_vehicle.tires.should == "Snow Tires"
  end

  it "should have a V8 engine" do
    @winter_vehicle.engine.should == "4.7L V-8"
  end

  it "should have standard cloth seats" do
    @winter_vehicle.seats.should == "Cloth Bucket Seats"
  end

  it "should have 4 wheel drive" do
    @winter_vehicle.amenities.should include("4 Wheel Drive")
  end

  it "should have a snow plow" do
    @winter_vehicle.amenities.should include("Snow Plow")
  end

  it "should not have any other amenities" do
    @winter_vehicle.amenities.length.should == 2
  end
end

require 'rubygems'
require "spec"
require 'lib/SummerVehicleFactory'

describe "When creating a summer cruiser" do
  before(:each) do
    @summer_cruiser = SummerVehicleFactory.new.create_vehicle
  end

  it "should be a Nissan 370Z" do
    @summer_cruiser.make_model.should == "Nissan 370Z Coupe"
  end

  it "should have a standard steering wheel" do
    @summer_cruiser.steering_wheel.should == "Standard Steering Wheel"
  end

  it "should have all season tires" do
    @summer_cruiser.tires.should == "All Season Tires"
  end

  it "should have a V6 engine" do
    @summer_cruiser.engine.should == "3.7L V6"
  end

  it "should have leather seats" do
    @summer_cruiser.seats.should == "Leather Bucket Seats"
  end

  it "should have a premium sound system" do
    @summer_cruiser.amenities.should include("Premium Sound System")
  end

  it "should not have any other amenities" do
    @summer_cruiser.amenities.length.should == 1
  end
end

In the next post we’ll look at the strategy pattern. Stay tuned!
kick it on DotNetKicks.com

Share/Save/Bookmark

Using Reflection to Find the Connection String Being Used By NHibernate

Filed Under (.Net, NHibernate) by John Miller on 14-03-2009

Tagged Under : , ,

In my last post, we discussed how to run a Sql script from C# to insert lookup data when we regenerate our database for integration tests. But we want to make sure that the connection string that’s being used by NHibernate is the same connection string being used by our InsertTestData() method. To do that, we can use reflection to find the value of the ConnectionString property of the ISessionFactory.ConnectionProvider object.

public static class NHibernateHelper
{
    private static readonly ISessionFactory _sessionFactory = Configuration.BuildSessionFactory();
    private static Configuration _configuration;
    public static ISessionFactory SessionFactory
    {
        get { return _sessionFactory; }
    }
    public static Configuration Configuration
    {
        get
        {
            if (_configuration == null)
                _configuration = new Configuration().Configure();
            return _configuration;
        }
    }
    public static string ConnectionString
    {
        get
        {
            var propertyType = typeof (DriverConnectionProvider);
            var propertyInfo = propertyType.GetProperty("ConnectionString"
                                                , BindingFlags.Instance | BindingFlags.NonPublic);
            return (string) propertyInfo.GetValue(SessionFactory.ConnectionProvider, null);
        }
    }
    public static ISession GetSession()
    {
        var session = _sessionFactory.OpenSession();
        session.FlushMode = FlushMode.Never;
        return session;
    }
}

Now we can change the InsertTestData() method to use this connection string.

public void InsertTestData()
{
    using (var conn = new SqlConnection(NHibernateHelper.ConnectionString))
    {
        FileInfo fileInfo = new FileInfo(@"Sql\InsertSeedData.sql");
        var sql = fileInfo.OpenText().ReadToEnd();
        Server server = new Server(new ServerConnection(conn));
        server.ConnectionContext.ExecuteNonQuery(sql);
    }
}

Update:

Matt pointed out below that we really don’t need to use reflection to do this, NHibernate handles it for us. Thanks Matt!
public static string ConnectionString
{
    get
    {
        return Configuration.GetProperty("connection.connection_string");
    }
}

DotNetKicks Image

Share/Save/Bookmark