Lebesque,
(IMHO)
The import of your PI technique to C# language architecture is the
potential for a 'low cost' functional wrapper on existing state space.
The 'wrapper' expression would allow a semantic pass through of all
'existing target' (the class being wrapped) functionality and state space.
The state space of the wrapper itself would not be accessible to the
target. It would be accessible, as coded, to the client.
The temporal data channel (return/parameter streams of target methods)
could be passed through.
The semi-persistent data facade (properties, fields) of the target could
be passed through.
I am not qualified to judge if this is good (or bad) without significant
efforts to compare to strategic C# design and alternative solutions. But
hopefully Anders and the dev team will look at this if they are already
not aware of the approach (which I suspect they are).
I DO think (hip shot) that the PI technique is an excellent way of
understanding the architectural partitioning of the state space.
I recast your code into role based artifacts as inheritance (parent/child)
and embedding (house/mansion) phenomena.
I really liked coding this approach and it helped me to better articulate
some of the key issues with MI vs Interface (state space specification at
the top level). Without shooting my self in the foot (hip shot astray) I
could see where this is a good solution to have in approaching the C# MI
inheritance flaw (IMHO).
Thanks so much for your input and the 'mud' article.
BTW - The 'ball of mud' paradigm is an eloquent articulation to explain
the use of MI as a strategic approach to long term functional migration
(away from a big ball of mud
Shawnk
PS. The rewrite of the code is below (I hope I copied it in right -
compiles and runs OK for me)
Key point : There is no instance of 'House' identity due to the lack
of instrinsic state space removed via the PI approach.
---------------------
public
class MS_example_03_dem_cls
{
Parent m_parent_ins;
Child m_child_ins;
House m_house_ins;
Mansion m_mansion_ins;
public
void Demo_MI_operator()
{
m_parent_ins = new Parent ( "Fred Flintstone" );
m_child_ins = new Child ( "Pebbles" );
// What we would like to do is MI for house with the identity
functionality (instance name)
m_house_ins = new House ( m_child_ins );
m_mansion_ins = new Mansion ( "Mansion" );
// House now contains 'resident' functionality of child/parent.
// All 'resident' function must be 'coded out' indivdually
// Incoming client requests are funnelled to the 'delegated functionality
resident in child'
m_parent_ins. Print_identity();
m_child_ins. Print_identity();
// See if house can behave like parent
//
// With MI we could just 'pass through' the child functionality to do
the following
// Also we could set the name of the house to 'House' for its correct
identity
//
// m_house_ins. Print_identity();
//
// With PI the code to 'pass through' the identity fucntion is the
Del..() method.
//
m_house_ins. Delegation_cost_Print_identity();
//
// With true inheritance we get a no cost 'pass through' of both state
and function
//
m_mansion_ins. Print_identity();
//
// This inheritance is an excellent mechanism for the stratigic migration
of common
// function (inclusive of state) toward a target base class library
//
}
} // End_of_class
class Parent
{
private string name;
public Parent( string identity)
{
name = identity;
}
public void Print_identity()
{
Console.WriteLine(" My identity is {0} ", name);
}
}
class Child : Parent
{
public Child (string identity ) : base ( identity )
{
}
public static implicit operator House(Child child)
{
return new House(child);
}
}
class House
{
private Child child;
public House(Child child)
{
this.child = child;
}
public void Delegation_cost_Print_identity()
{
child.Print_identity();
}
}
class Mansion : Child
{
public Mansion(string identity ) : base ( identity )
{
}
}