Okay so basically I have the following problem: I'm trying to have an abstract class inherit another abstract class that has an abstract method, but I don't want to implement the abstract method in either of them because a third class inherits from both of them:
public abstract class Command
{
public abstract object execute();
}
public abstract class Binary : Command
{
public abstract object execute(); //the issue is here
}
public class Multiply : Binary
{
public override object execute()
{
//do stuff
}
}
I'm trying to separate binary commands from unary commands but don't want to/can't implement the execute method in either. I thought about having Binary override the abstract method (since it has to), and then just throw a not implemented exception thing. If I make it override, then I must declare a body, but if I make it abstract, then I'm "hiding" the inherited method.
Any thoughts?
You don't need to declare execute() in the Binary class since it's already inherited from Command. Abstract methods don't need to be implemented by other abstract classes - the requirement is passed on to the eventual concrete classes.
public abstract class Command
{
public abstract object execute();
}
public abstract class Binary : Command
{
//the execute object is inherited from the command class.
}
public class Multiply : Binary
{
public override object execute()
{
//do stuff
}
}
Just omit the declaration of execute() in Binary at all. Since Binary is abstract as well, you don't have to implement any abstract methods of its ancestors.
Related
I'm a bit confused at some code I recently came across. Here is a snippet. First of the Abstract Class Definition and then of the Class that inherits from it:
public abstract class BaseClass
{
protected static void MapEntityToModel(string paramOne, List<TypeDef> types)
{
// Some Logic Here
}
protected static void MapModelToEntity(ModelType model, ResultType result)
{
// Some Logic Here
}
}
public class BaseExtension : BaseClass
{
public static ViewModel MapModelToViewModel(Model m)
{
var result = new ViewModel();
// Some Logic Here
return result;
}
public static List<ViewModel> MapModelsToViewModels(List<TModel> models)
{
return models.Select(m => MapModelToViewModel(m)).ToList();
}
public static Model MapViewModelToModel(ViewModel v)
{
var result = new Model();
// Some Logic Here
return result;
}
}
So my understanding and usage of an Abstract Class has always been that any abstract methods within an Abstract Class must be overridden in the inherited Classes. If a method within an Abstract Class is not declared abstract, the derived Class can create an instance of itself within a method and directly call the non-abstract method of the Abstract Class.
But in either case the methods of the Abstract Class are used in the Derived Class. However, given the previous code snippets the Derived Class has no directly mapped signature or usage.
What then is the purpose of the Abstract Class in this particular scenario and why does it compile without error? I obviously am missing some concept of the Abstract Class and its appropriate implementation.
So my understanding and usage of an Abstract Class has always been that any abstract methods within an Abstract Class must be overridden in the inherited Classes
That is true, but the methods are not abstract, they are concrete (and static). Only virtual or abstract instance methods can be overridden.
What then is the purpose of the Abstract Class in this particular scenario and why does it compile without error?
Since the class has no abstract methods or properties I do not see why it is abstract, other than the author doesn't instances created for some reason.
static methods are not part of instances of the class
when you are saying a class is abstract you are saying that you cannot create instances of it.
Abstract on those classes serves no purpose apart from highlighting that creating instances of them is pointless as all methods are static anyway.
Also inheriting from them seems a little pointless as nothing is inherited - all the members are static.
You may as well have only the inherited class and make the base class an empty interface and move the static methods in it into the inherited class (an interface is in effect an abstract class with no method implementations - but you would normally have what are in effect abstract method definitions though)
abstract class a
{
public abstract string look();
public static string lookStatic()
{
return "look";
}
}
class b : a
{
public override string look()
{
return "look member";
}
}
class Program
{
static void Main(string[] args)
{
Console.WriteLine(b.lookStatic());
var test = new b();
Console.WriteLine(test.look());
var c = (a) test;
Console.WriteLine(c.look());
Console.ReadLine();
}
}
Like Interfaces, can an abstract class have only method signatures without implementation? If yes:
How do abstract classes differ from interfaces?
How can another class, which has an abstract class as its base class, implement the body of the base class methods?
An abstract class can contain implementations, but it doesn't have to. This is one thing that makes it different from interfaces.
abstract class classA
{
abstract public void MethodA();
public void MethodB()
{
Console.WriteLine("This is MethodB inside ClassA");
}
}
class classB : classA
{
public override void MethodA()
{
Console.WriteLine("This is MethodA inside class B");
}
}
If you implement a method in the abstract base class and want to be able to override it later, you need to declare the method as virtual.
virtual protected void MethodC(){
//this can be overridden
}
in Java:
q1: The abstract class can contain method definitions AND normal methods while an interface cannot.
q2: from http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html
//this is the abstract class
public abstract class GraphicObject {
abstract void draw();
}
//this is the implementation
class Rectangle extends GraphicObject {
void draw() {
...
}
}
Like Interfaces, can an abstract class have only method signature without implementation? If yes:
Yes, but can also have implementation ...
You can also have method implementation in the abstract class unlike interfaces, but you can not create an instance of an abstract class
Interfaces and Abstract Classes
Abstract Class versus Interface
Like Interfaces, can an abstract class have only method signature without implementation?
Yes. Abstract class can have method implementation.
How it differs from Interface?
Variables declared in an interface is by default final. An abstract class may contain non-final variables.
Members of a interface are public by default. An abstract class can have the usual flavors of class members like private, protected, etc..
Interface is absolutely abstract and cannot be instantiated; An abstract class also cannot be instantiated, but can be invoked if a main() exists.
In comparison with abstract classes, interfaces are slow as it requires extra indirection.
Refer the following links:
http://forums.asp.net/t/1240708.aspx/1
http://java.sys-con.com/node/36250
http://www.codeproject.com/Articles/11155/Abstract-Class-versus-Interface
Interface is a fully abstract class,
Means only signatures, no implementations, no data members.
On the other hand abstract class by defenition needs at least one abstract method.
Also it can have implementations.
And it also can contain data members which will be inherited to its inheritors.
The inheritor needs to implement the abstract method with the same signature in order to implement it
in JAVA Yes,
if you use abstract class this way, then there is no difference between interface and abstract class. what dose abstract class really matter is you can offer common implementation which expect to be inherited by sub class, that's interface is not able to do.
yes, as I said, that abstract class behave the same way as interface, you can just override the methods in sub class
For example:
public abstract class AbstractClassWithoutImplementation {
public abstract String methodA();
}
public class Implementation extends AbstractClassWithoutImplementation {
#Override
public String methodA() {
// TODO Auto-generated method stub
return "Yes";
}
public static void main(String[] args){
Implementation im = new Implementation();
System.out.println(im.methodA());
}
}
An abstract class is a class that cannot be instantiated. It is in between a concrete class (fully implemented) and an interface (not at all implemented).
It can contain regular members (variables, methods etc) that are fully implemented.
It can also contain abstract members that are not implemented. Any member that is not implemented, say a method signature, must be marked abstract.
So to answer your questions:
Like Interfaces, can an abstract class have only method signature without implementation?
Your wording is not clear enough to give a yes or no answer. An abstract class can have implemented methods, and it can have abstract methods that are not implemented which must be marked as abstract. It cannot have methods without implementation unless they are marked abstract.
If yes: How it differs from Interface?
Because it allows implementation of members.
How another class, for which this Abstract Class is acting as a base class, can implement the body of that method?
Simply needs to implement all the abstract members.
public abstract class A
{
public abstract void Test();
}
public class B : A
{
public void Test(){ return; }
}
Like Interfaces, can an abstract class have only method signature without implementation? If yes:
Yes, An abstract class can have all abstract methods even if it has a single abstract method it must be abstract.You can declare a class as abstract even if it doesn't have any abstract method.
How it differs from Interface?
In Interface ALL methods are abstract public bet in Abstract class it is not necessary that .Please read about Interface vs Abstract Class
How another class, for which this Abstract Class is acting as a base class, can implement the body of that method?
If your BaseClass is Abstract and ChildClass is extending Base class you can implement abstract method in ChildClass otherwise make ChildClass abstract also.
public class ChildClass extends BaseClass{
void display(){
/// Your Implementation here
}
}
abstract class BaseClass{
abstract void display();
}
I have written the following code in C#.NET
public interface IWork
{
void func();
}
public abstract class WorkClass
{
public void func()
{
Console.WriteLine("Calling Abstract Class Function");
}
}
public class MyClass:WorkClass,IWork
{
}
On compiling, I didn't get any error. Compiler is not forcing me to implement the method "func();" in "MyClass", which has been derived from the interface "IWork".Latter, I can gracefully create a instance of the class "MyClass" and call the function "func()". Why the compiler is not forcing me to implement the "func()" method in the "MyClass"(which has been derived from "IWork" interface? Is it a flaw in C#?
While reading about this subject, I found I couldn't easily put it all together in my head, so I wrote the following piece of code, which acts as a cheat-sheet for how C# works. Hope it helps someone.
public interface IMyInterface
{
void FunctionA();
void FunctionB();
void FunctionC();
}
public abstract class MyAbstractClass : IMyInterface
{
public void FunctionA()
{
Console.WriteLine( "FunctionA() implemented in abstract class. Cannot be overridden in concrete class." );
}
public virtual void FunctionB()
{
Console.WriteLine( "FunctionB() implemented in abstract class. Can be overridden in concrete class." );
}
public abstract void FunctionC();
}
public class MyConcreteClass : MyAbstractClass, IMyInterface
{
public override void FunctionB()
{
base.FunctionB();
Console.WriteLine( "FunctionB() implemented in abstract class but optionally overridden in concrete class." );
}
public override void FunctionC()
{
Console.WriteLine( "FunctionC() must be implemented in concrete class because abstract class provides no implementation." );
}
}
class Program
{
static void Main( string[] args )
{
IMyInterface foo = new MyConcreteClass();
foo.FunctionA();
foo.FunctionB();
foo.FunctionC();
Console.ReadKey();
}
}
Gives the following output:
FunctionA() implemented in abstract class. Cannot be overridden in concrete class.
FunctionB() implemented in abstract class. Can be overridden in concrete class.
FunctionB() implemented in abstract class but optionally overridden in concrete class.
FunctionC() must be implemented in concrete class because abstract class provides no implementation.
To better understand the concept behind interfaces, I just give you the correct code of your implementation:
public interface IWork{
void func();
}
public abstract class WorkClass,IWork{
public void func(){
Console.WriteLine("Calling Abstract Class Function");
}
}
public class MyClass:WorkClass{
...
}
The basic rule: You need to include the interface always where the implementation is. So if you create a method within an abstract classes and define an interface of this method, you'll need to implement the interface into your abstract class and then all subclasses will automatically implement this interface.
As a matter of fact, interfaces have 2 kind of functions you can use them for:
1) As a "real" interface providing a generic handling of any class implementing the interface, so you can handle several kind of classes just by one interface (without knowing their real class names). While "handling" means: Calling a method.
2) As a help for other (framework) programmers not to mess up with your code. If you want to be sure that an method won't be replaced with another name, you define an interface for your class containing all "must have" method names. Even if the method is called nowhere, your programmer will get an compile error message when he changed the method name.
Now you can easily handle your Myclass just by the interface IWork.
Because the abstract class implements the interface.
If your class MyClass would not inherit from WorkClass you would get an error saying 'MyClass' does not implement interface member 'IWork.func()'.
But you also inherit from WorkClass, which actually implements the methods that the interface requires.
You can mark func() as abstract if you want to force the classes that inherits from it to implement it like this:
public abstract class WorkClass
{
public abstract void func();
}
I tried with the classes above in my solution.
It inherits the abstract class so the derived class have the func() method definition. This is the reason it was not able to show compiled errors.
func() is not marked as abstract in the WorkClass so you don't need to implement it in any classes that derive from WorkClass.
WorkClass implements the IWork interface so you don't need to implement it in MyClass because it inherits func() from WorkClass.
Since the func method in the abstract class is a non-virtual method, so the compiler thinks this method is a implementation of the interface.
When you extend MyClass to WorkClass, the method func() (which has been defined), is inherited.
So, when the interface IWork is implemented, the method 'func()' has already been defined. So, there are no more undefined methods in MyClass.
So, the class MyClass is a concrete class, due to which you are able to create a MyClass object without any compilation errors.
What do I need to do to first run the method in the base class then run the same method in the derived class? Is this a good idea?
I want run common actions in base class and extend it in the derived class in the same method. Is this how it is usually done?
public abstract class MyBase
{
void DoStuff()
{
//some common implementation
}
}
public class MyDerived : MyBase
{
void DoStuff()
{
// DoStuff in the base first
// Then DoStuff in here
}
}
are you talking about something like that?
class base
{
protected virtual void method()
{
// do some stuff in base class, something common for all derived classes
}
}
class derived : base
{
public override void method()
{
base.method(); // call method from base
// do here some more work related to this instance of object
}
}
that's not a bad idea, I do use it a lot when I have some common functionality for all derived classes.
If you want to guarantee that the base class logic is run (and not rely on the derived class being polite), you can do this:
public void Method()
{
//Stuff that should always happen in base class
OnMethod();
}
protected virtual void OnMethod()
{
//Default base class implementation that derived class can either override or extend
}
Use base.TheMethod() to run a method in the base class from a derived class.
If you want to run a method of a derived class from a base class, then you have to cast the base class to the derived class. This means that your class needs to be aware of who is deriving it, which breaks encapsulation and should be avoided.
I have an interface so class writers are forced to implement certain methods. I also want to allow some default implemented methods, so I create a abstract class. The problem is that all classes inherit from the base class so I have some helper functions in there.
I tried to write : IClass in with the abstract base, but I got an error that the base didn't implement the interface. Well of course because I want this abstract and to have the users implement those methods. As a return object if I use base I can't call the interface class methods. If I use the interface I can't access base methods.
How do I make it so I can have these helper classes and force users to implement certain methods?
Make sure methods in the base class have the same name as the interface, and they are public. Also, make them virtual so that subclasses can override them without hiding them.
interface IInterface {
void Do();
void Go();
}
abstract class ClassBase : IInterface {
public virtual void Do() {
// Default behaviour
}
public abstract void Go(); // No default behaviour
}
class ConcreteClass : ClassBase {
public override void Do() {
// Specialised behaviour
}
public override void Go() {
// ...
}
}
Move the interface methods into the abstract class and declare them abstract as well. By this, deriving classes are forced to implement them. If you want default behaviour, use abstract classes, if you want to only have the signature fixed, use an interface. Both concepts don't mix.
Having faced with the same problem recently, I've came up with a somewhat more elegant (to my mind) solution. It looks like:
public interface IInterface
{
void CommonMethod();
void SpecificMethod();
}
public abstract class CommonImpl
{
public void CommonMethod() // note: it isn't even virtual here!
{
Console.WriteLine("CommonImpl.CommonMethod()");
}
}
public class Concrete : CommonImpl, IInterface
{
void SpecificMethod()
{
Console.WriteLine("Concrete.SpecificMethod()");
}
}
Now, according to C# spec (13.4.4. Interface mapping), in the process of mapping IInterface on Concrete class, compiler will look up for CommonMethod in CommonImpl too, and it doesn't even have to be virtual in the base class!
The other significant advantage, compared to Mau's solution, is that you don't have to list every interface member in the abstract base class.