This question is asked by an interviewer in one of my interviews.
we can avoid creating instance of the class by using private constructor then we cannot inherit that class
Well you can use the private constructor, but that does not make your class abstract.
It just means that other classes cannot create a new instance of your class.
But your class can still call its own constructor through a static method, therefore creating a new instance of itself.
If you don't want a class to be instanciated at all, never ever, use the Abstract keyword...
If you want to use an object only in the "inheritance-hierachy" you need the protected-keyword (see also for access modifiers in general https://msdn.microsoft.com/en-Us/library/wxh6fsc7.aspx)
If you want to have an abstract behaviour, whats the reason for not take abstract keyword?
Related
I have a public abstract class which I want other classes in the module to extend, but I do not want to to be extendible externally.
I am aware I could make it sealed, but it has many subclasses and would be cumbersome to have them all in the same file. How can this be achieved?
You can define its constructor as internal. Subclasses must call the superclass' constructor, so only files that can see that constructor will be able to subclass your class.
You can make it sealed, but declare just one internal (and not sealed) subclass in the same file. Then other classes in the module can see and extend the internal subclass, and so your original class.
Note that classes which extend subclasses of a sealed class (indirect inheritors) can be placed anywhere, not necessarily in the same file.
EDIT: the drawback is that the extending classes must also be internal (or even less visible). Louis Wasserman's solution avoids this and is simpler.
In C# 8.0 we have a new feature where we can provide a default method implementation in Interfaces which can also be overridden by its implementing classes as well.
We used to have Abstract classes with instance methods to provide a common functionality for all of its implementing classes.
Now can I replace those Abstract classes who are having Instance methods with Interfaces who are having Default method implementations from C# 8.0 on wards?
No, abstract classes still have their place. In particular, abstract classes can declare fields (often via automatically implemented properties these days), which interfaces still can't. They can also define constructors, and perform validation in them.
Here's an example of something you couldn't do with an interface:
public abstract class NamedObject
{
public string Name { get; }
protected NamedObject(string name) =>
Name = name ?? throw new ArgumentNullException(nameof(name));
// Abstract methods here
}
Obviously it wouldn't really be called NamedObject - there'd be a business-specific reason for it to be abstract, which would determine the name. But the behaviour here is behaviour that can't be put in an interface.
You can in most cases but probably you shouldn't. The default functionality in the interfaces is there to solve another problem.
It's there for when you can't change an existing class, if for example is in some other project/ibrary and you want to extend the functionality without changing all the code with an abstract class..
Maybe it does make sense to have as an Abstract class? An object that has behavior but does not make sense on its own and must be extended should be better modeled by a class. If you have the Car class with behavior, then you can have the length private member which applied to all cars. Private members are not part of the interfaces.
I was going through the differences between Interface versus Abstract class on MSDN but got some confusion on below difference:
If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface
I have confusion on this line
on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface**
Could you help explain?
methodes you write in the interface you should obligatory put it in your class Which implements in the iterface
and the abstract class is the opposit of interface the methodes you put in class abstract you can use it in your class or not.
An abstract base class is a class whose sole intent is to be derived. An interface is the set of public methods of a concrete class.
While they differ very little in actual functionality, I like to think of interfaces as an adjective while an abstract class is a noun. For the classic instance of an animal, an interface is used do describe attributes, like pet-able, friendly, dangerous. On the other hand, an abstract class would describe the thing itself more narrowly, like canine, feline or human.
Not to sound like a koan, but just wondering if there are definite rules about classes and objects. I used to think classes as blueprints, and objects as the creation from them. But if a combination of blueprints creates another blueprint, does the latter blueprint become an object as well?
Your question seems a bit philosophical... :) "object" and "instance" are quite synonymous in OOP.
If I understood your question correctly, your doubt is: "an object is still an object also if created by another class that is not the same that define its type?"
The answer is "yes", an instance is an object created following the "model" defined by its class, but for many reasons you could instantiate a class in an indirect way, for example a static method (factory method of a factory class, for example) and not directly using new statement.
If you want to see some come, an easy example in Java could be:
public class MyClass {
public MyClass(){}
}
public class MyClassFactory{
public getInstance(){
return new MyClass();
}
}
In this case the instance is not returned directly by MyClass, but from its factory class. however it's an object as well...
In just about every OO environment I know, an instance is the same as an object.
It doesn't matter whether the object/instance is created by the client (such as with new) or by the class (such as with singletons or factories).
If you're talking about blueprints in the context of classes, then creating blueprints from blueprints is inheritance, not instantiation.
I'm looking at a VB.NET class (that I didn't write) that is declared MustInherit (abstract in C#, I believe) that has three methods, all of which are defined as Shared (static in C#). There are no properties or fields in the class - only the three methods. From an OO perspective, does this make any sense?
My thinking is no, because by making it MustInherit, you're essentially saying you can't create an instance of this class - you must inherit from it and create an instance of the derived class. But since all the methods are shared, you'll never actually create an instance of the parent class anyway, so the MustInherit does no good. You might as well not mark it MustInherit and just inherit from it whenever you want.
Is there a situation where creating a class this way makes sense?
As others have said, it sounds like they really wanted a C# static class. VB's equivalent to "static" is "shared", but you can't mark classes "shared" in VB. The difference is that someone could inherit from this class and then create an instance. C# static classes are sealed.
What they should have done is use a Module. A VB Module and C# static class are virtually identical: members are associated with the type rather than an instance and you cannot inherit from them.
From an OO perspective, this doesn't make a lot of sense.
However, VB doesn't have a way to flag a class as Shared, like C# does. In C#, you'd likely flag this class as a static class - the MustInherit was most likely added to try to prevent people from creating an instance of it, even though it's basically a static class.
In C# a class can be declared as static (= Shared), and I think VB.NET doesn't allow that, so as a workaround it is marked abstract (MustInherit) so that it's never instantiated