I'm learning about design patterns and in examples of code I've seen a convention where the abstract class declares a method, for example:
public abstract class ServiceBase {
...
public virtual object GetSomething();
and then
protected abstract object DoGetSomething();
My question is on why these two methods exist, since they appear to serve the same purpose. Is this so that the base class GetSomething() method logic cannot be overridden by inherited classes? But then again, the method is marked virtual, so it can be overridden anyway. What is the usefulness here in requiring derived class implementers to implement the abstract method when the virtual method can be called anyway?
One common reason is to put standard handling around the abstract method. For example, perhaps the abstract method can only be called in certain circumstance -- say, after the splines have been reticulated. In that case, it makes sense to check _areSplinesReticulated in one place -- the public GetSomething method -- rather than requiring every implementation of the abstract method to perform its own checking. Or maybe GetSomething is 90% boilerplate but requires a bit of additional logic or a crucial piece of information that only derived classes can supply.
This is a form of the Template Method pattern.
A non-virtual GetSomething means every derived class gets the standard handling and only gets to participate via their custom version of DoGetSomething. If GetSomething is virtual, that means derived classes can bypass the standard handling if they want to. Either of these is a viable strategy depending on whether the standard GetSomething handling is integral to the class logic (e.g. invariants) or whether the base class wants to grant maximum flexibility to derived classes.
I've not seen the version you describe where "GetSomething()" is virtual, but I've seen (and written) classes like this:
public abstract class Foo
{
protected abstract void DoBar();
public void Bar()
{
// do stuff that has to happen regardless of how
// DoBar() has been implemented in the derived
// class
DoBar();
// do other stuff
}
}
Because "Bar" isn't virtual (and I suppose you could also seal it just to make sure) you have a chance to "inject" code before and after the "DoBar" method is called. It's quite handy.
Related
I would like to know how could I create the implementation of an abstract method in all the specific classes that inherit from him.
I need it because I have an abstract class, I create one abstract method on it, but there is around 50 specific class to implement this method, and will be so boring implement one by one (even with the ctrl + . shortcut).
You can right-click on every class and select Implement Abstract Class which will create an empty metmber-body doing nothing but throw an NotImplementedException.
However I can´t see any reason why you should do that. If your method should have a default-implementation it should not be abstract in base-classd but virtual:
abstract class MyBaseClass {
virtual void DoSomething()
{
// do nothing
}
}
class Derived : MyBaseClass {
override void DoSomething()
{
Console.WriteLine();
}
}
You do not have to implement the method on all derived classes now. So as long as you´re testing (or for whatever weird reason you need this) you can stay on your default implementaion whereas when releasing the software you force every class to implement the member by chaning modifier from virtual to abstract and delete the method-body.
If I understand your problem correctly, you can follow the pattern of the adapters for Java event listeners.
They are an intermediate class sitting above the abstract class (interface in Java), providing a more or less meaningful (actually, empty) default implementation for all abstract functions. Your classes inherit (either just for now, or forever) from this adapter, overriding only some of the functions.
If all your classes inherit from this adapter as a permanent solution it is probably questionable why you had the abstract class to begin with. Defining an interface with no implementation makes sense only in order to avoid the restrictions concerning multiple inheritance in Java and C#. If the base class has some implementations anyway, you can as well provide a default for the remaining abstract methods, too. If that is undesired because in production code inheritors must be forced to implement their own methods, because there is no reasonable default, one could actually disable the implementing code with conditional translation (and, for example, make it dependent on a DEBUG or TEST flag during compilation).
I have a MustInherit class with some MustOveride Methods in it. When i inherit form that class, I automatically get the MustOveride Methods or properties.
My question is, I want to be able, to inherit from a class, get my MustOveride functions and methods, but then with some code already in it. I've once seen a .net class that did it, when I inherited from that class, I got the methods, with some comments in it.
Does anybody have an idea what i mean? (It a bit hard to describe ;-) )
I think what you described is known as Template Method Pattern:
public abstract class MyClass
{
public void SomeMethod()
{
// code
MustInherit();
// code
}
protected abstract void MustInherit();
}
Create a method which will not be overridden SomeMethod in this sample and stuff all common code into this class. Then create an abstract method which must be overridden.
If you want to provide a default implementation, so the method must not be overridden but can be use the virtual keyword.
public abstract class MyClass
{
public void SomeMethod()
{
// code
MustInherit();
// code
}
protected virtual void CanInherit()
{
// default implementation
}
}
I assume, you want to do have the following:
When you inherit from that abstract base class, you want to have those abstract methods already partly implemented in your class.
This is not possible out of the box. It could be achieved with some templating, but that has nothing to do with C# or VB.NET but with the IDE used.
The only thing you can do is to create that method as virtual (C# - I don't know how it is called in VB.NET) in the base class and call the base implementation in the derived class.
An Abstract class for you service :)
If you need that consumer of your abstract class ovverides some methods for sure then mark them as abstract too. If you need just to provide possibility of ovveriding you methods but this is not definitely necessary then mark them as virtual.
With the virtual keyword you are not forced to implement the inherited method, then it will use the default implementation of the base class. In that way, you kind of inherit all the code from the base method.
Otherwise, you can implement you own derived version of the method, and somewhere in it call the base class' version of method : base.MethodName(...);. That allow you to kind of inherit all the code from the base method once again, but this time with additional code before and after which is specific to your derived class.
Otherwise, you can make your base class' method such that it uses delegates in its code and call it here and there. Thus the fundamental functioning of the base class' method remain the same for all the derived classes, but each derived class provides its own delegates to adjust some detail key blocks of code in the base class' method.
Otherwise, if you want to see partially implemented methods with comments here and there like Add your code here, it's typically a matter of code generated by an external tool like Visual Studio or another IDE and has nothing to do with the language itself.
But as you see there are plenty of possibilities, depending of you you want precisely...
I just learned about the Template Method pattern in this answer to a question about ensuring that methods in base classes are always called by child classes.
Part of the answer talks about base classes vs no-op classes:
(The decision about whether to make it
a no-op or abstract is usually fairly
obvious - does the base class make
sense on its own, as a concrete
class?)
What is a no-op class?
It isn't the class that is no-op, but the implementation of the method.
The answer debates the decision of making the method in the base class abstract (thereby forcing derived classes to implement it, even if they want to have it do absolutely nothing) versus implementing it as a "no-op" (i.e. with an empty method body).
If doing nothing is a sensible default, then the base class might implement this method as a no-op so that derived classes are bothered to override only if they actually want something different to happen.
If doing nothing is not sensible, then it makes sense for the method to be abstract.
no-op is short for no-operation, that is, a method that does nothing:
public void MyNoOp()
{
}
Or from the linked question:
public override void Update()
{
//no-op, does nothing
}
I was looking at some code in an abstract class:
public virtual void CountX(){}
public virtual void DoCalculation() { ...code}
Why should I declare an empty virtual method in an abstract class if it is not mandatory to override it in derived types?
Because if the default behaviour is to do nothing, but derived classes might want to do something. It's a perfectly valid structure.
It allows your base code to call it. You tend to see similar designs when there is "BeforeXXX" and "AfterXXX" code, at the base class this code is empty, but the method needs to be there to compile. In derived classes, this code is optional, but needs to be virtual to be overridden.
The fact that it is in an abstract class shouldn't confuse its behaviour.
An example:
abstract class Base
{
public void ProcessMessages(IMessage[] messages)
{
PreProcess(messages);
// Process.
PostProcess(messages);
}
public virtual void PreProcess(IMessage[] messages)
{
// Base class does nothing.
}
public virtual void PostProcess(IMessage[] messages)
{
// Base class does nothing.
}
}
class Derived : Base
{
public override void PostProcess(IMessage[] messages)
{
// Do something, log or whatever.
}
// Don't want to bother with pre-process.
}
If these methods (Pre, Post) were abstract, then all derived classes would need to implement them (likely as empty methods) - code litter that can be removed using empty virtual methods at the base.
As #Adam told you, there are many cases in which it makes sense. When you create an abstract class, it's because you want to create a common interface for all classes deriving from that one; however, at that level of inheritance you won't have enough information to be able to create working code for that method.
For example, if you create the class Figure, with the getArea() method, you won't be able to write code that is going to correctly calculate the area for all figures. You'll have to wait to write the code for Rectangle, or Circle (both deriving from Figure), in order to be able to write working code for them.
If it is MANDATORY to override and no default logics could be written in base class, than virtuality is wrong and method should be abstract. If the default action is to do nothing, than as Adam mentioned, making empty virtual method in base class is perfectly valid structure
When you declare the method as abstract, the inherited class has to override that method (provide an implementation). It is mandatory.
When the method is declared as virtual, the inheritor can override the method and provide an implementation other than the default.
From a design perspective this smells bad and indicates that the implementation of the design is in an immature state. If a method is not required by every class that derives a particular base class then by definition it does not belong in the base class. You will usually discover that this method is used by particular derivations of the base class and that indicates a new interface or layer of abstraction in your inheritance hierarchy.
I've stumbled upon this "feature" of C# - the base class that implements interface methods does not have to derive from it.
Example:
public interface IContract
{
void Func();
}
// Note that Base does **not** derive from IContract
public abstract class Base
{
public void Func()
{
Console.WriteLine("Base.Func");
}
}
// Note that Derived does *not* provide implementation for IContract
public class Derived : Base, IContract
{
}
What happens is that Derived magically picks-up a public method, Base.Func, and decides that it will implement IContract.Func.
What is the reason behind this magic?
IMHO: this "quasi-implementation" feature is very-unintuitive and make code-inspection much harder. What do you think?
The reason is that your comment is simply incorrect:
// Note that Derived does not provide implementation for IContract
Sure it does. Follow the logic through.
Derived is required to provide a public member corresponding to each member of IContract.
All inheritable members of a base class are also members of a derived class; that's the definition of inheritance.
Therefore Derived provides an implementation for IContract; its inherited member is a member that fulfills the requirement
Therefore, no error.
this feature is very-unintuitive and make code-inspection much harder. What do you think?
I think you shouldn't use the feature if you don't like it. If you find it confusing and weird to read code that uses this feature then encourage your coworkers who use this feature to stop doing so.
How is this feature different from any other feature where a method from a base class is used from a derived class? There are a number of different ways in which a method from a base class may be used or mentioned in a derived class -- method calls, overrides, method group conversions, and so on.
Furthermore, this is relatively speaking a simple, straightforward case. If you really want to complain about confusing interface semantics in C#, I'd spend my time complaining about interface reimplementation semantics. That's the one that really seems to bake people's noodles. I always have to look that thing up in the spec to make sure I'm getting the semantics right.
Why do you think that this is strange and unnatural? Every public member of base class is also a public member of derived class. So there is no contradiction here. Anyhow you can implement interface explicitely if you like.