Re: multiple inheritance



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 )
{
}
}




.



Relevant Pages

  • Re: multiple inheritance
    ... Top level specification of state space in multiple inheritance ... The PI design technique is a wrapper for functionality around ... The re-write of your code shows the 'statically false' ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Cant get Global.asax to execute Sub
    ... The Math class, for example, is not much more than a bunch of ... The File class has all the functionality needed to ... >> of the needs of the house. ... >>> Tom ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Creating and using arrays - again
    ... To get the sort of "object" functionality ... Each child word has the ... It would cost us nothing but tradition to remove ... -- power we don't need. ...
    (comp.lang.forth)
  • Re: multiple inheritance
    ... Top level specification of state space in multiple inheritance ... The PI design technique is a wrapper for functionality around ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: COM support in my application
    ... Make a dll and export the methods which expose the functionality. ... > I have a MFC application with several child dialogs. ...
    (microsoft.public.vc.mfc)

Loading