Wednesday, February 18, 2009

The OO light bulb goes on

I had a light bulb moment a few months ago that I want to share. Bare with me.

OO programs when running are a network of in memory 'object's each with specific behavior and state.

Traditional OO programming languages like C# 1.1 and Java allow you to specify classes of objects, defining generalizations about how certain types of object behave.

In C# an object is an instance of a class.

In True OO this is only one of many ways to get your running object in memory. Why limit yourself to this factory technique... Why not create a bare object and add methods to it at runtime? Why not mix together sub-class modules of functionality?

As long as at the end you have a network of objects in memory that behave the way you need them to, to model your domain, why limit yourself to this one technique of object creation?

Type safety?

I recently heard a podcast (can't recall which...) where the speaker said "type checking in the compiler is just a form of unit testing". Personally I am still letting that sink in.

I guess, if I were you, and I had read this far, I would get to this point and have one question "So What?"

Thinking of classes as only one way to get objects into memory is liberating:-

I had a class I wrote the other day that was part of a UAT framework based on White...

 public class CaseHelper : ScreenHelper
{
public CaseHelper(Window window)
: base(window)
{}

public string PatientId
{
get { return PatientIdBox.Text; }
set { PatientIdBox.SetValue(value); }
}

public string GivenName
{
get { return GivenNameBox.Text; }
set { GivenNameBox.SetValue(value); }
}

public string FamilyName
{
get { return FamilyNameBox.Text; }
set { FamilyNameBox.SetValue(value); }
}

public string DateOfBirth
{
get { return DateOfBirthBox.Text; }
set { DateOfBirthBox.SetValue(value); }
}

public string Gender
{
get { return GenderBox.SelectedItemChildName(); }
set { GenderBox.SelectItemByChildName(value); }
}

public void ClickSave()
{
SaveButton.Click();
}

public string BarcodeNo
{get { return BarcodeNoBox.Text; }}

private TextBox PatientIdBox
{get { return Get<TextBox>("patientId"); }}

private TextBox GivenNameBox
{get { return Get<TextBox>("givenName"); }}

private TextBox FamilyNameBox
{get { return Get<TextBox>("familyName"); }}

private TextBox DateOfBirthBox
{get { return Get<TextBox>("dateOfBirth"); }}

private ComboBox GenderBox
{get { return Get<ComboBox>("gender"); }}

private TextBox BarcodeNoBox
{get { return Get<TextBox>("barcodeNo"); }}

private Button SaveButton
{get { return Get<Button>("saveButton"); }}

}



As you can see lots of duplication that is hard to factor out further. I could turn to code generation., but what frustrates me is in Ruby I would be able to write helpers for each type of control and the code would become...


class CaseHelper < ScreenHelper
has_text "patientId"
has_text "barcodeNo"
has_button "saveButton"
has_combo "gender"
has_text "giveName"
has_text "familyName"
has_text "dataOfBirth"
end


That I can handle. This is possible because defining a class is ruby is done at execution time. All you are doing is executing code that is creating objects. (a class in an object that has a new method that makes other objects). has_text is just a method that defines methods. Easy.
Post a Comment

GitHub Projects