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.

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.

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.

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

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.

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.

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.

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!