While learning the Ruby programming language I have noticed that Ruby uses
an initialization scheme that I have not seen used in C# and I was wondering
what you all thought about it.
Specifically I would like to know your thoughts on:
- How testable this pattern is
- Could this help hide or make dependency injection/service location
easier to use
- Does this constitute better design
- Is my assumption about Ruby object creation with property setting
correct
In C# we can create an object and initialize several properties in the same
line. This is normally followed by a call to a method. This can also be done
in Ruby but I believe it requires a little setup by the developer. Commonly
Ruby code combines the method call and the property initialization into one
method. The way this works is the method is passed a lambda/block that does
the property setup.
Here is an example of the normal way to do this in C# and a possible way to
do this with a Ruby style. Service1 is setup like normal, but Service2 is
setup Ruby style. This example is very contrived since it only has 1 method,
but I think it illustrates the pattern well enough to discuss it. In real
code I would assume that there would be more interaction with the service
inside of the lambda method.
using System;
namespace rubyInitialize
{
class Program
{
static void Main()
{
//C# style with property initializer
var service1 = new Service
{
Setting1 = "1",
Setting2 = "2",
Setting3 = "3"
};
service1.ExecuteOldStyle();
Console.WriteLine("{0}==={0}", Environment.NewLine);
//Ruby style with setup lambda
Service.ExecuteNewStyle(service2 =>
{
service2.Setting1 = "1";
service2.Setting2 = "2";
service2.Setting3 = "3";
});
Console.ReadLine();
}
}
class Service
{
public string Setting1 { get; set; }
public string Setting2 { get; set; }
public string Setting3 { get; set; }
public void ExecuteOldStyle()
{
DisplaySettings();
}
public static void ExecuteNewStyle(Action<Service> setup)
{
var service = new Service();
setup(service);
service.DisplaySettings();
}
private void DisplaySettings()
{
Console.WriteLine("Setting1: {0}", Setting1);
Console.WriteLine("Setting2: {0}", Setting2);
Console.WriteLine("Setting3: {0}", Setting3);
}
}
}
I am thinking this might be really useful when the static method is also a
factory method to figure out what kind of object to create. This way the
lambda's parameter object would not be known by the developer at compile
time since it might actually be a derived type. (Normally you do this in C#
with an interface) Aka. Service had a sub-class "SpecialService" but the
caller only had to know about "Service".
--
Thanks,
Jason
P.S. I also asked this at my work. Management said "stop talk, fix more
bugs". Fellow developers said "this might be useful with extension methods
since they are already static"
--
You received this message because you are subscribed to the Google Groups
"Seattle area Alt.Net" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/altnetseattle?hl=en.
