I have a question that nobody in my department is able to answer. It came to me while using the Class Designer to stub out our data access layer of our application. The question is:
If I create an abstract worker class as such:
public abstract class MyClass
{
public abstract void MyMethod(DataEntityAbstract Entity);
}
Then try the following in its derived class:
public class ThisClass : MyClass
{
// ThieDataEntity is derived from DataEntityAbstract class
public override void MyMethod(ThisDataEntity Entity)
{
// Do Something
}
}
Visual Studio 2005 will throw a compilation error. Why
I mean, polymorphism and inheritance allows us to declare a method using an abstract as a parameter. This allows the method to accept not only the abstract parameter which was declared, but any object derived from that abstract. It¡¯s the cornerstone of OOP.
So why can we not use these principles when declaring an abstract method I¡¯m sure you¡¯re probably asking yourself ¡°Why would you need to ¡± Maybe this will answer:
I need to create an abstract worker class, having helper methods as well as abstract methods. These abstract methods will expect a specific entity to be passed when they are called on the derived class, however the abstract class does not have foreknowledge as to WHICH specific entity will be required. Only that it will be derived from a known abstract class:
public abstract void ProcessData(EntityBase Entity);
It will be the responsibility of the derived class to specify WHICH specific entity:
public override void ProcessData(SQLEntity Entity)
{
//Do Something
}
The method on the derived worker class will only accept the SQLEntity, and will not allow use of any other entity which is derived from EntityBase (i.e. OracleEntity, AccessEntity, etc). The constraint exists because the derived worker class is to be used for SQL Server only, and thus only wants the SQLEntity entity!
Granted, I could always check the type and do a cast (or throw an exception), but why The principles of OOP should allow this.. right
DotNetTex