Architecture

Re: Abstract Class & Inheritance

cmay — Wed, 03 May 2006 18:01:43 GMT

biswajitdash:

I think you mean the other way around... casting a DerivedClass as a BaseClass.

Following is down-casting as you are moving away from the base type.

BaseClass objRef = null; // BASE TYPE REFERENCE
DerivedClass d = new DerivedClass()
objRef = d; // Still a BASE TYPE REFERENCE
((DerivedClass)objRef).Add(1, 2, 3); // EXPLICIT DOWN-CAST

Sorry I thought you were taking about the spot in my code where I was using a DerivedClass as a Base class.

biswajitdash:

I guess now all agree that, what djdouma wants is not possible in C# and does not make any sense either.

Agreed!

Re: Abstract Class & Inheritance

biswajitdash — Wed, 03 May 2006 17:16:49 GMT

I think you mean the other way around... casting a DerivedClass as a BaseClass.

Following is down-casting as you are moving away from the base type.

BaseClass objRef = null; // BASE TYPE REFERENCE
DerivedClass d = new DerivedClass()
objRef = d; // Still a BASE TYPE REFERENCE
((DerivedClass)objRef).Add(1, 2, 3); // EXPLICIT DOWN-CAST

But you can't do an implicit upcast when the operation you are trying to execute doesn't exist on the base class, which is what you were trying to do in your code example.

I revisited my post. My mistake. Insteade of compile-time I had written run-time. My intention was compile-time failuer.

I guess now all agree that, what djdouma wants is not possible in C# and does not make any sense either.

Re: Abstract Class & Inheritance

cmay — Wed, 03 May 2006 16:49:29 GMT

biswajitdash:

All confusion has started, from the shadowing concept that you are trying to forcefully introduce into C# language. It simply does not exist in C#. You can never hide a base class method that differs by signature, in C#. So, the what original the poster asked for is not possible in C#.

Since it does not exist in this language, whatever code example or logic you try to give, will not hold good from C# point of view. I am not disagreeing from VB.NET point of view.

I believe I indicated this in my post:

cmay:

Maybe I misspoke here.

I tried to do it in C# and it would always show the base interface as well (it indicated that the method was from the base class and not the subclass, but still I couldn't hide that inteface).

biswajitdash:

In none of my posts I have told that each and every concrete method implementation has to be declared in an interface or abstract classs. And of course it will be madness to put everything into an interface.

When you said "Always program to an abstract/interface and not an implementation." I wasn't sure if you were actually advocating literally always programming against an abstract/interface. Some people do in fact do this, and I'm glad to say we both thing it is madness.

biswajitdash:

In your code example you have explicitely down-casted the BaseClass TYPE REFERENCE into a DerivedClass TYPE. This way the DerivedClass specific method is visible for sure, but this is NOT what real polymorphism is.

I think you mean the other way around... casting a DerivedClass as a BaseClass.

biswajitdash:

Polymorphism is executing an operation, without knowing about its specific implementation details in run-time. In OO operation is different from implemented method. Thing defined as a contract is operation and actual implementation is method. Thats why all polymorphic calls are made from a base type and not a derived type. Its always based on implicit up-casting.

But you can't do an implicit upcast when the operation you are trying to execute doesn't exist on the base class, which is what you were trying to do in your code example.

BaseClass has Add w/ two parameters, DerivedClass includes Add with 3 parameters.

You can't say:

	    BaseClass b = new BaseClass();
            DerivedClass d = new DerivedClass();
            BaseClass objRef = null;

            // Polymorphic call here. Will fail. Because 
            // type BaseClass does not have any Add() 
            // method that takes 3 arguments.
            objRef = d;

            objRef.Add(1, 2, 3); // Will fail.

That will never work, and it has nothing to do with shadows or new. If you were working in Javascript the above code would work, but in C#, or VB.Net or Java this won't even compile.

Re: Abstract Class & Inheritance

Caddre — Wed, 03 May 2006 16:30:06 GMT

biswajitdash:
And how exactly you make methods shadow in C#, where the method signature itself differs? Can you give working example code?

The link below is a blog entry in Dino's blog and the replies seems to imply there is no equivalent of Shadow in C#.

http://weblogs.asp.net/despos/archive/2004/03/10/86995.aspx

Re: Abstract Class & Inheritance

TAsunder — Wed, 03 May 2006 15:40:36 GMT

cmay:

You don't lose any polymorphism doing this. That is why the method shadows the inherited classes methods.

Obviously I wasn't trying to put a lot of real world relevance into my example with my Add method.

The issue is that there may be times when you want to inherit from a class and have a simliar named method with a different signature, maybe do different things, without breaking anything in the base class.

You don't always have access to the source code to change the class you are inheriting from, and you don't always want to change the base class anyway.

If I use shadows on a method and you pass the object polymorphically as its base class's type, then the base class "Add" method will be available, not the shadows method, so polymorphism is fully available.

But this is not what his sample code seemed to indicate. Take a look at it again. From what I can see, he has an add method that does nothing in the base class, and exists only as a signature of what the inherited classes have to do, even though it will be with different parameters always. The class is fully abstract. It might be that you interpreted my post as an answer to you and not the OP? I agree with your solution as a solution to something else, but I don't think it has to do with what he is trying to accomplish.

It's true, you can in theory achieve polymorphism with shadows, but not in the case of the original post. In the original post, the add method does nothing in the base class. You can't call it at all and have anything meaningful done, unless the sub classes override the add with no parameters.

It is the OP's scenario that violates polymorphism and makes no sense. The add method is abstract, and won't ever be called. Seems like he wants to structure his app so that all DAL objects inherit from a base class that has Add and Delete with no parameters, but those will never be called. For polymorphic operations, a method should be able to operate on the base class and have the base class methods do something useful. In this example, that is not the case. I can't write a method that takes in a "Base" object and then call add, because any particular sub class has its own version of what has to be passed in to do an add.z

What is the purpose then? It's not like something is going to call Add() with no parameters. Always he will have to call Add with specific parameters. Which totally defeats the purpose of having an add in the first place.

Re: Abstract Class & Inheritance

biswajitdash — Wed, 03 May 2006 15:35:04 GMT

Answering the original post: Either define overloaded Add() methods into an abstract base class, or forget about inheritance and go by concrete type calls. The question does not have any straight-forward inheritance based solution in C#.

Answering the cmay's last post:

I am not sure where the disconnect here is.

All confusion has started, from the shadowing concept that you are trying to forcefully introduce into C# language. It simply does not exist in C#. You can never hide a base class method that differs by signature, in C#. So, the what original the poster asked for is not possible in C#.

Since it does not exist in this language, whatever code example or logic you try to give, will not hold good from C# point of view. I am not disagreeing from VB.NET point of view.

I have been answering everything keeping in mind the original post and the shadow concept that came in. Because this concept is taking the original poster in the wrong direction. Original question was in C#.

You can't always program to an abstract, unless you are willing to assign every method to an interface.

In none of my posts I have told that each and every concrete method implementation has to be declared in an interface or abstract classs. And of course it will be madness to put everything into an interface.

This is exactly what my code example did! The BaseClass interface is used when you cast a DerivedClass as BaseClass. This is one of the basic principles of OO. This is polymorphism.

In your code example you have explicitely down-casted the BaseClass TYPE REFERENCE into a DerivedClass TYPE. This way the DerivedClass specific method is visible for sure, but this is NOT what real polymorphism is.

Polymorphism is executing an operation, without knowing about its specific implementation details in run-time. In OO operation is different from implemented method. Thing defined as a contract is operation and actual implementation is method. Thats why all polymorphic calls are made from a base type and not a derived type. Its always based on implicit up-casting.

Re: Abstract Class & Inheritance

cmay — Wed, 03 May 2006 13:52:04 GMT

biswajitdash:

What you are telling in essence means that "Prgram to the concrete implementation and not the abstract/interface".
The actual principle is - "Always program to an abstract/interface and not an implementation." Thats how polymorphiism is used. Otherwise why does the concept of interface exist?

I am not sure where the disconnect here is.

You can't always program to an abstract, unless you are willing to assign every method to an interface. What if Employee inherits from Person? Employee has a "givePayRaise" method. How are you going to "program to the abstract" and be able to execute that method? You can't, unless you go nuts and make every class implement an interface for no reason.

Polymorphism is used by allowing you to treate CONCRETE (or even abstract types, so long as they extend from another class) implementations as more simple GENERIC objects / interfaces.

This is exactly what my code example did! The BaseClass interface is used when you cast a DerivedClass as BaseClass. This is one of the basic principles of OO. This is polymorphism.

I really don't know where you see a problem with this. You can never call "givePayRaise" off a Person object unless that Person is really an Employee. The Person interface doesn't have "givePayRaise". It is this that you were trying to do in your first code example.

"Prgram to the concrete implementation and not the abstract/interface". Unless you NEED to program against the concrete implementation as I showed above (givePayRaise), then you HAVE to program against the concrete implementation. My code example shows you can program to the abstract/interface if you want and it works just fine.

"Always program to an abstract/interface and not an implementation." Thats how polymorphiism is used. Otherwise why does the concept of interface exist? Any code you write against the BaseClass will work just fine if you use DerivedClass. THAT is how polymorphism works. If you are suggesting that the concept of interfaces exists so that you never have to work with a concrete class, then I would disagree with your way of programming. Implementing interfaces allows a class to be used polymorphically in multiple cases, are are very important in languages like C#/Vb.Net/Java, that don't support multiple inheritance.

If you want to take the position (I would strongly disagree with it) that you need to have every class implement an interface so you can ALWAYS program against an interface or abstract base class, then I would first say that I disagree with that philosophy, and second that you can STILL do that just fine with my code example: you can still do that type of design using shadows.

Re: Abstract Class & Inheritance

biswajitdash — Wed, 03 May 2006 07:05:23 GMT

Sorry but your code example is backwards in terms of understanding how polymorphism and LSP works.

Polymorphism works by allowing you to say that a DerivedClass can be used as a BaseClass. But you are trying to use a BaseClass as a DerivedClass. Polymorphism doesn't work in that direction.

What you are telling in essence means that "Prgram to the concrete implementation and not the abstract/interface". Is it? Thats not correct. I guess most in this forum will disagree on what you are telling.

The actual principle is - "Always program to an abstract/interface and not an implementation." Thats how polymorphiism is used. Otherwise why does the concept of interface exist?

Re: Abstract Class & Inheritance

cmay — Wed, 03 May 2006 05:10:22 GMT

biswajitdash:

You don't lose any polymorphism doing this. That is why the method shadows the inherited classes methods.

What TAsunder asked is correct. Look at the following code block to explain the polymorphic scenario better. The VB.NET way of shadowing really does not satisfy any polymorphism. Assume that the classes are written in VB.NET library and referred from a C# client.

' VB.NET Class Library
Public Class BaseClass
    Public Function Add(ByVal i As Integer,
                        ByVal j As Integer) As Integer
        Return i + j
    End Function
End Class

Public Class DerivedClass
    Inherits BaseClass

    Public Shadows Function Add(ByVal i As Integer,
                                ByVal j As Integer,
                                ByVal k As Integer) As Integer
        Return MyBase.Add(i, j) + k
    End Function
End Class

// C# Class Library
public class ClientClass
{
    public static void Main()
    {

        BaseClass b = new BaseClass();
        DerivedClass d = new DerivedClass();
        BaseClass objRef = null;

        // Polymorphic call here. Will work fine.
        objRef = b;
        objRef.Add(1, 2); // Will work.

        // Polymorphic call here. Will fail. Because
        // type BaseClass does not have any Add()
        // method that takes 3 arguments.
        objRef = _d;
        objRef.Add(1, 2, 3); // Will fail.
    }
}

So, a polymorphic call in run-time will fail. Also following shadowing technique in real-life violates LSP at the best. Any design using this must be avoided.

Sorry but your code example is backwards in terms of understanding how polymorphism and LSP works.

Polymorphism works by allowing you to say that a DerivedClass can be used as a BaseClass. But you are trying to use a BaseClass as a DerivedClass. Polymorphism doesn't work in that direction.

Your line of code:
objRef.Add(1, 2, 3); // Will fail.

Of course it will fail. It won't even compile. objRef is a BaseClass. BaseClass doesn't have a method "Add" that takes 3 parameters.

What if DerivedClass defines a method "Subtract". objRef won't have that either. It's the same thing. Base Classes don't know about the classes that inherit from them.

But if you case objRef as a DerivedClass, then you can call Add with 2 or 3 parameters, just as you would expect to.

If what you coded worked (objRef.Add(1,2,3)) then THAT is what would break LSP.

But LSP is not violated. I modified your code a little to show that LSP is not violated, and polymorphism remains fully functional.

See my code example to clear this up:

' VB.NET Class Library

Public Class BaseClass
    Public Function Add(ByVal i As Integer, _
                        ByVal j As Integer) As Integer
        Return i + j
    End Function

    Public Function LSP() As String
        Return "I am LSP compliant"
    End Function
End Class


Public Class DerivedClass
    Inherits BaseClass

    Public Shadows Function Add(ByVal i As Integer, _
                                ByVal j As Integer, _
                                ByVal k As Integer) As Integer
        Return MyBase.Add(i, j) + k
    End Function

    Public Shadows Function LSP() As String
        Return "I am NOT LSP compliant, bad programmer"
    End Function
End Class

static void Main(string[] args)
        {
            
            BaseClass b = new BaseClass();
            DerivedClass d = new DerivedClass();
            BaseClass objRef = null;

            // Polymorphic call here. Will work fine.
            objRef = b;
            objRef.Add(1, 2); // Will work.

            // Polymorphic call here. Will fail. Because 
            // type BaseClass does not have any Add() 
            // method that takes 3 arguments.
            objRef = d;

            
            //objRef.Add(1, 2, 3); // Will fail.
            /**************
             * My Comments: of course this will fail... 
             * It will fail at compile time.  objRef is a BaseClass. 
             * BaseClass doesn't have Add(i,i,i)  */

            // this will work just fine.
            ((DerivedClass)objRef).Add(1, 2, 3);

            // lets make sure LSP is not violated
            Console.WriteLine(testLsp(b));
            Console.WriteLine(testLsp(d));
            Console.WriteLine(testLsp(objRef));
            Console.WriteLine(testLsp((DerivedClass)objRef));
            Console.WriteLine("All passed");
            Console.Read();
        }

        static string testLsp(BaseClass b)
        {
            return b.LSP();
        }

Re: Abstract Class & Inheritance

biswajitdash — Wed, 03 May 2006 04:20:19 GMT

You don't lose any polymorphism doing this. That is why the method shadows the inherited classes methods.

What TAsunder asked is correct. Look at the following code block to explain the polymorphic scenario better. The VB.NET way of shadowing really does not satisfy any polymorphism. Assume that the classes are written in VB.NET library and referred from a C# client.

' VB.NET Class Library
Public Class BaseClass
    Public Function Add(ByVal i As Integer,
                        ByVal j As Integer) As Integer
        Return i + j
    End Function
End Class

Public Class DerivedClass
Inherits BaseClass

    Public Shadows Function Add(ByVal i As Integer,
                                ByVal j As Integer,
                                ByVal k As Integer) As Integer
        Return MyBase.Add(i, j) + k
    End Function
End Class

// C# Class Library
public class ClientClass
{
    public static void Main()
    {

        BaseClass b = new BaseClass();
        DerivedClass d = new DerivedClass();
        BaseClass objRef = null;

        // Polymorphic call here. Will work fine.
        objRef = b;
        objRef.Add(1, 2); // Will work.

        // Polymorphic call here. Will fail. Because
        // type BaseClass does not have any Add()
        // method that takes 3 arguments.
        objRef = _d;
        objRef.Add(1, 2, 3); // Will fail.
    }
}

So, a polymorphic call in run-time will fail. Also following shadowing technique in real-life violates LSP at the best. Any design using this must be avoided.

Re: Abstract Class & Inheritance

cmay — Tue, 02 May 2006 18:57:40 GMT

You don't lose any polymorphism doing this. That is why the method shadows the inherited classes methods.

Obviously I wasn't trying to put a lot of real world relevance into my example with my Add method.

The issue is that there may be times when you want to inherit from a class and have a simliar named method with a different signature, maybe do different things, without breaking anything in the base class.

You don't always have access to the source code to change the class you are inheriting from, and you don't always want to change the base class anyway.

If I use shadows on a method and you pass the object polymorphically as its base class's type, then the base class "Add" method will be available, not the shadows method, so polymorphism is fully available.

Re: Abstract Class & Inheritance

TAsunder — Tue, 02 May 2006 18:42:54 GMT

I don't get it. Why do you want to do this? It makes no sense. Is it just so that when you type the . after the object it shows an add method? It really does not offer you any of the flexibility of polymorphism when you do this. If your base method is to be at all meaningful or useful and not just wasted code to confuse developers, you need to abstract the method parameters too.

Maybe you need an AddParameters class. By default this has no members. In your individual Add() methods you make sure that the class passed in to the Add method is of the minimal type needed (i.e. you need an object that inherits from AddParameters that has an Int).

Re: Abstract Class & Inheritance

cmay — Tue, 02 May 2006 16:22:50 GMT

Maybe I misspoke here.

I tried to do it in C# and it would always show the base interface as well (it indicated that the method was from the base class and not the subclass, but still I couldn't hide that inteface).

In VB.Net you can indeed hid the interface of the base class using Shadows.

Maybe someone else can tell me if there is no way to do this with C#. I figured b/c you could do it in VB you could in C#.

Public Class Base
    Public Function Add(ByVal i As Integer, ByVal n As Integer) As Integer
        Return i + n
    End Function
End Class

Public Class SubClass
    Inherits Base

    Public Shadows Function Add(ByVal i As Integer, ByVal x As Integer, ByVal y As Integer) As Integer
        Return MyBase.Add(i, x) + y
    End Function
End Class

    public abstract class Abst
    {
        public abstract string AbstMethod();

        public  string Add(int i, int n)
        {
            int ret = (i + n);

            return ret.ToString();
        }
    }

    public class Conc : Abst
    {
        public override string AbstMethod()
        {  
            return "Whatever";
        }
        
        public new string Add(int i, int n, int x)
        {
            int basevalue = int.Parse(base.Add(i, n));
            basevalue = basevalue + x;
            return basevalue.ToString();
        }
    }

Re: Abstract Class & Inheritance

djdouma — Tue, 02 May 2006 16:10:34 GMT

Ido, thanks for your comments. Would you be able to provide a code example which follows along the lines of what I originally posted (two methods, Delete & Add, with two Classes implementing Add with two different parameter lists)? I work better with examples

public abstract class BaseObject 
{ 

 public abstract void Add(); 

 public abstract void Delete(int Id); 
} 
public class ChildObject1 : BaseObject 
{ 

 public override void Add(string Name, string Desc) 
 { 
 } 

 public override void Delete(int Id) 
 { 
 } 
} 
public class ChildObject2 : BaseObject 
{ 

 public override void Add(string Name) 
 { 
 } 

 public override void Delete(int Id) 
 { 
 } 
} 
struct TestModule 
{ 

 void Main() 
 { 
   ChildObject1 child1 = new ChildObject1(); 
   child1.add("Testing Child1"); 
   ChildObject2 child2 = new ChildObject2(); 
   child2.add("Testing Child2", "My Description"); 
 } 
}

Re: Abstract Class & Inheritance

idof — Tue, 02 May 2006 15:44:48 GMT

Hi,

As you've been explained, this is not the usual use of an abstract class. BTW, if you wish to do the above, you'd better use interfaces (call it IUpdatableObject for example).

As for the parameters - if you use .net 2.0, you can use generics and declare the parameter type as T.

for example:

interface IUpdatableObject<T>

{

void update(T newData);

}

class Implementor : IUpdatableObject<string>

{

public void update(string newData)

}

If you need to use multiple parameters, just declare a custom class/struct to hold those parameters (which actually makes it a data structure).

Best of luck,

Ido.