I usually make a base class abstract to give the signal this is a base class - you cannot instantiate me! even if there are no abstract methods in it.
Furthermore, I always make the base class constructor protected, although there's no real functional need to do that - I just want to make another point that this is a base class - you cannot instantiate me!
Am I jumping through hoops in doing that? What do you do?
It seems a reasonable thing to do, yes. There'll be no functional difference between the constructor being public or being protected, but making it protected gives a clearer indication of the intended use.
I'm not sure that you should set the class as abstract if there are no abstract methods. If it has a full implementation of the functionality that is expected of the classes derived from it, why not let it be instantiated and used as is? If this is just a way to share functionality across a range of classes then a composition based design may be more appropriate ie. have each 'derived' class reference this class rather than derive from it.
Is there a particular scenario you have in mind where this is could be an appropriate design?
Edit
The only scenario I have found where an abstract class with no abstract methods makes sense is when the abstract class is partially implementing and interface. The derived classes are required to complete the implementation.
Link to example (edit: site gone, This blog post seems to be a copy of the content)
In an abstract class, there's no difference between a public or protected constructor. As a matter of fact, I believe the compiler should give a warning or error when defining the constructor of an abstract class as public. Too bad it doesn't.
Related
So far in my application all the abstract classes I have do get inherited by some child class.
However, now I came at a point that I have a class that I never want to be instiatiated, however this class will also not be inherited by any other class in my application. My question now is if it still good practice to turn this class abstract just for the sake of preventing instantiation?
If you want to prevent a class from being instantiated, you should make it static.
An abstract class that cannot be inherited doesn't really make sense.
I think the question is why you want to prevent their instantiation. The idea of abstract class is to have a "general" class to be used as a base of other ones.
If you want to do that, that is correct, if this is not the idea, then you have to use another approach.
Static class are not a good idea either, they like as "global variables" but you can use them anyway if you take care.
My suggestion is to rethink what you want to do and to use the correct approach. Perhaps you need to organize them using interfaces.
I have some user controls which I want to specify properties and methods for.
They inherit from a base class, because they all have properties such as "Foo" and "Bar", and the reason I used a base class is so that I dont have to manually implement all of these properties in each derived class.
However, I want to have a method that is only in the derived classes, not in the base class, as the base class doesn't know how to "do" the method, so I am thinking of using an interface for this. If i put it in the base class, I have to define some body to return a value (which would be invalid), and always make sure that the overriding method is not calling the base. method
Is the right way to go about this to use both the base class and an interface to expose the method? It seems very round-about, but every way i think about doing it seems wrong...
Let me know if the question is not clear, it's probably a dumb question but I want to do this right.
EDIT : Thanks to all the people with your excellent abstract suggestions, but this breaks the designer. If abstract was not a selectable option, what would you do?
Alternatively you could define the method as 'abstract' in the base class, which will not require the class to implement it. For example:
abstract class A
{
public abstract void B();
}
Of course this will force your base class to be abstract as well, but it sounds like this would work just fine for you.
See Abstract methods on MSDN.
Update
Since abstract is not an option for you due to designer issues, you could just define the method as part of your base class, and have it throw a NotImplementedException if it is called directly from the base class:
void DerivMethod()
{
// Must be implemented by derived class
throw new NotImplementedException();
}
Otherwise, using an interface would be fine, especially if the above leaves a bad taste in your mouth...
You should make your base class an Abstract class. Then the base class can implement the Interface by marking the method abstract.
http://msdn.microsoft.com/en-us/library/aa664435(VS.71).aspx
Mark the method as abstract in your base class. You'll be forced to implement it in the derived classes, but the base class will not need to have a method definition.
I agree with with others, but making your user control abstract has some issues for the designer. The designer will often not display the abstract user control.
I would implement the interface methods in the base class. You can throw a NotImplemented exception or Assert.Fail in the methods if you want to make sure the inheritors are overriding these methods properly.
Declare the function signature in the base class and use the "abstract" modifier.
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.
All members of an Interface are public by default. But there are some properties in my interface that I want to be used as private members of some subclasses that implement my interface. Is this something that can and is done or am I way off basis here. I'm working on using more Interfaces in my architecture these days so I'm not that well versed yet.
The point of interfaces is that they provide a contract that other objects can use to communicate with your object. If you change a member which is declared as public in an interface to private then you're not fulfilling the contract - another object may need to read that property / call that method, and you must allow them to.
An interface will never have private members as an interface is for "interfacing" between two objects. Your internal private members don't matter to it as long as you hold up your end of the contract.
Going on your question, and your use of the word "subclass", I don't think you've fully understood Interfaces yet.
I know you've probably heard this a million times but, an Interface describes what an object DOES, and a Class is HOW it does it. A Class IMPLEMENTS, an interface, it does not INHERIT from it.
So, if you want, have an Interface for you base Class, or for your SubClasses, but your question makes me think you're thinking about a base Class (Abstract Class), not an Interface.
Does that make sense?
As interface does not has an Access Modifier, if you still want your method private in the class which is implementing that interface, you can Implement that interface EXPLICITLY.
In that way your class methods will be Private.
You have to fully understand what interfaces are. In fact there are just descriptions of the expectations that outside world could have about the class members. It do not creates the member, it just informs that specified class have specified method to use in public scope. So, as you can see by interface you could only describe public members.
On the other hand if you want to declare some private members that are fixed or virtual you can use classic inheritance with the abstract base class. In this case you will make all methods that you want to implement in subclasses as abstract, and implement methods that you want to be defined in base class.
Hope this helps.. Regards
Interfaces are only good for public access. Internally, it would be strange for an object to refer to itself through an interface.
If you want to have private variables that you force an implementation of, you want to use an abstract class, and mark them as protected.
Think a little about this - and you understand that this can not be done:
Interfaces are like a contact. all the public fields of the interface are parts of the contact.
So, you can't hide them in a subclass... What would happen if someone were to upcast your class object to the interface's type ?
You'd probably want to change your design - may be split your interface in to two interfaces?
or and interface and an abstract class? we need more details to know...
In OOP, I see a lot of classes which derive from parent classes, but the parent classes are not marked as abstract. When the class IS marked as abstract, what advantage does this provide?
Thanks
The difference is really pretty pragmatic: an abstract base class is one that is never intended to be instantiated, and so needn't necessarily provide complete implementations. This means the ABC can define a contract for derived classes without implementing the class.
This is convenient in two ways:
you can define abstract objects that don't have the full implementation but make assertions about the whole class. One example of this is to have a DrawItem class with a draw() method that's the base class for Circle, Rectangle, and so on. DrawItem can't know how to draw itself, because it doesn't know what it is.
you can define classes for which you can have two concrete implementations. This shows up in the Proxy pattern, and can also be used to build, for example, mock objects for testing.
It's more common these days for new languages to define interfaces or modules or mixins for these things; it turns out that using ABCs almost always fall into the use cases for those more intuitive concepts.
Paul Haahr has interesting suggestions, such as:
Don't subclass concrete classes
(read the original, I don't want to copy and paste everything;-).
Paul's writing about Java, but I found at least this part of his advice is applicable to most any OO design task (though pragmatically I still occasionally deviate from it in coding, it's alive and well in my design;-), even when I'm going to implement it in C++, Python, or whatever. If, after reading Paul's reasoning, you find yourself agreeing with him, you're going to be using a lot more abstract classes in the future (to allow subclassing;-).
To call a class "abstract" is essentially to communicate to your fellow programmers that it's incomplete: they're expected to write a bit more code to be able to make use of it.
There's actually a parallel with partial application of functions in functional programming here...
An abstract class cannot be instantiated by itself; it must be derived from to be instantiated. Essentially, the abstract definition on a class indicates that it was not intended to be instantiated as itself, and the only way to get an instance of it is to inherit from that class, and instantiate the inherited class.
The fact that the compiler will not allow you to instantiate it?
to give an example of what I think is pertinent:
public abstract class CustomSocket()
{
CustomSocket()
{
}
public abstract void PleaseOverideMe(CustomSocketConnection c)
{
}
}