Hi all,
this is the first post of the Butchering Design Patterns series. What we do here is try to highlight Design Patterns very common between butchers. Just like everyone, they often don't know they're using these patterns, they just go ahead with their unplanned coding and these patterns just emerge. Some of them make sense, some others do not, but after seeing them a number of times you may need to classify them.
Open Door - the Open Door Pattern is not particularly exciting but is very common between coding butchers.
Definition: define an abstract class declaring all your variable members as public, then implement a getter and setter for each of them. Define a concrete child class for your abstract class; when you need to set/get the variable member value, just use the first way that comes to your mind (access directly or through the getter/setter), or toss a coin if in doubt.
Frequency of use: very high
UML Diagram:
Partecipants:
AbstractOpenDoor: declares an interface common to all concrete open doors.
ConcreteOpenDoor: inherits from abstract open door.
Code Sample:
this is the first post of the Butchering Design Patterns series. What we do here is try to highlight Design Patterns very common between butchers. Just like everyone, they often don't know they're using these patterns, they just go ahead with their unplanned coding and these patterns just emerge. Some of them make sense, some others do not, but after seeing them a number of times you may need to classify them.
Open Door - the Open Door Pattern is not particularly exciting but is very common between coding butchers.
Definition: define an abstract class declaring all your variable members as public, then implement a getter and setter for each of them. Define a concrete child class for your abstract class; when you need to set/get the variable member value, just use the first way that comes to your mind (access directly or through the getter/setter), or toss a coin if in doubt.
Frequency of use: very high
UML Diagram:
Partecipants:
AbstractOpenDoor: declares an interface common to all concrete open doors.
ConcreteOpenDoor: inherits from abstract open door.
Code Sample:
// Open Door Pattern -- Structural example
using System;
namespace DotNetButchering.ButcheringPatterns.OpenDoor.Structural
{
// MainApp test application
class MainApp
{
const string scuffia = "Dirty Sanchez Lover";
static void Main()
{
ConcreteOpenDoor myOpenDoor = new ConcreteOpenDoor(0);
//It's good practice to use getter/setter
if (myOpenDoor.GetGenericMember() == 0)
myOpenDoor.SetGenericMember(1);
//...
//Now I am in a bit of a rush, I'll access directly
myOpenDoor.m_genericMember = 2;
//..
//I am not the butcher who developed this, and I'll probably never notice
//that m_genericMember is public
if(scuffia == "Dirty Sanchez Lover")
myOpenDoor.SetGenericMember(3);
//..
// Wait for user
Console.Read();
}
}
// "Abstract Open Door"
abstract class AbstractOpenDoor
{
public T m_genericMember;
public virtual T GetGenericMember()
{
return m_genericMember;
}
public virtual void SetGenericMember(T genericValue)
{
m_genericMember = genericValue;
}
}
//"Concrete Open Door"
class ConcreteOpenDoor: AbstractOpenDoor
{
public ConcreteOpenDoor(T initValue)
{
m_genericMember = initValue;
}
//whatever
}
That's all about the open door pattern. Keep in mind it is common to find it used without any abstract base.
2 comments:
Ok...well...never used it, but I wish to use it now on!
It seems the best way to butcher your own classes and mess everything...the best!!!
I like it! I was thinking protected proxy, but this one sounds better.
Post a Comment