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
}
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 have some doubts when to use abstract class and if I need to always code interface. An example:
I have will have series of custom entities, and all of them need to implement SomeMethod() and most of them need to implement AnotherMethod() method.
SomeMethod() will be entity specific, each entity will have different code.
AnotherMethod() is implemented by most, but not all, and the code is the same for all.
How is this modeled? My idea is that each new entity must implement SomeMethod() and is able to use AnotherMethod().
Thanks,
Goran
AnotherMethod should likely be implemented in an abstract class so you don't repeat the code all over the place.
If SomeMethod is related functionaloty, it could be left in the same abstract class without an implementation, forcing children to implement it. If the functionality is not related to AnotherMethod, you could put it in its own interface.
You're right, for SomeMethod(), using abstract parent class with abstract method is a good idea. You can also use interfaces, depending on the meaning of the method. For example, if different classes represent different animals and the method is Move(Coordinate destination), an abstract parent class is better. If, on the other hand, different classes have nothing in common and the method is SerializeToJSON(), you should better use interfaces.
If AnotherMethod() is implemented by some of the classes, again, you can use an abstract parent class (with a non-abstract protected/public method). Of course, don't inherit from this parent the classes which do not have to implement AnotherMethod().
A big difference between interfaces and abstract classes is that the abstract class can have some implementation where the interface is strictly a contract and data type. In the examples you give, you could use an interface to require the implementation of both SomeMethod and AnotherMethod but you wouldn't be able to write any code for AnotherMethod since the interface would just have a method signature.
In an abstract class you could define SomeMethod as abstract and therefore require an implementation from classes which inherit from it but you could also create the implementation of AnotherMethod and have a single implmentation since you say that it will be the same for a lot of your classes.
A good situation to think of replacing inheritance with aggregation.
I'd extract AnotherMethod() to other class, say, AnotherMethodRunner, and add a getAnotherMethodRunner() to a base interface. If AnotherMethod() is a property of derived class, it will have one, if not - it will return null or Null Object.
I personally usually take a nonempty abstract base class as a call to more precise interface extraction.
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.
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.