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.

1 comment:

Curious Attempt Bunny said...

> 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?

Yes! This is something that I've been thinking about too. It seems to me that OO has very little necessity for interfaces and inheritance. Ruby, Groovy, and JavaScript all serve as good illustrations of this point to me.

GitHub Projects