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
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.
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?
In OOP we don't want coupling of classes. If I want to use an instance of class b within class a I can use dependency injection.
However if I want to use static methods of class b within class a I dont see any option but to "require" or "import" class b in the class a class file. This ends up with coupling between the classes - going against OOP principles. But the alternative is to rewrite the static method of class b as a static method in class a - going against the DRY principle. What is the right way?
This question was flagged as a possible duplicate of How to use Dependency Injection with Static Methods? but I feel that my question is asking from a more generic perspective on using another class' static methods. The think the question and accepted answer in the possible duplicate is more specific to a use case, but would not apply for example to a mere utility static method in the external class. My question aims to seek answer from a general oop perspective.
There are a variety options here and the specific use case is important in deciding what you may want to do. So, the big three would be...
Migrate the static method off Class B and into a shared library class, which is purely a holder for static methods and is never instantiated (in Java you'd make the constructor private and the class final). Then both class A and class B can access the method without depending on each other and without violating the DRY principle and the dependency on the library class is no better nor worse than relying on a static method defined on the same class.
If you're talking about a static method which is really something that best lives on class B then you can hide that method call behind some kind of a provider instance which is dependency injected into class A, with the provider implementation simply calling the static method on B. If you wanted to be really evil then the provider could also be injected into instances of B, but that would probably be overkill.
The static method can be changed to be an instance method on a new class which is dependency injected into both A and B. Sometimes this has a side-benefit of allowing you to hide some state in the instance rather than having to pass parameters into an otherwise stateless method.
Note that static methods in general cause problems in OO terms so only really the third options is a 'clean' one that really decouples classes and properly allow for coding to interfaces.
I have a few questions for you wise people involving OO design with Interfaces and abstract base classes. Consider the following scenario:
I have an abstract bass class "DataObjectBase" and a derived class "UserDataObject." I also have an interface "IDataObject." The interface of course exposes all of the public methods and properties that my Data Objects must expose, and you can probably guess that the abstract base implements the methods and properties common to all Data Objects.
My question is, if the abstract bass class DataObjectBase implements everything specified in the interface IDataObject, should the interface be declared on the base class, or on the derived classes(s)?
In C# interfaces declared on the base class are implicity applied to the derived classes, but is this the best practice? It seems to me that implementing the interface on the base class makes it less obvious that the derived class implements the interface, but then again requires the Interface to be specified for each derived class.
Additionally, if the base class was NOT abstract, would the reccomendation change?
A second sub-question: If the base class implements all of the methods/properties of the IDataObject interface, is the interface even needed? The base class typename can simply be used in place of the interface name, ie:
private DataObjectBase _dataObject;
private IDataObject _dataObject;
In the above example (where again the base implements everything exposed by the interface) both can be assigned the same derived types. Personally I always use the interface in these situations, but I am intrested in hearing peoples thoughts.
Thanks in advance.
My way of thinking about such problems is to consider the different people reading the code, the "roles" if you like. Also consider the overall maintainability of the system.
First there is some code expecting to use the Interface. It's written in terms of the interface, the author has (should have) no interest in the implementation. That's why we provide the Interface class. From that perspective the Abstract Base Class is just one of many possible implementation hierarchies. Don't tell this role about implementation details. Keep the Interface.
Then we have the role who is designing an implementation. They come up with one possible approach and discover some variations, so they want to pull common code together. Abstract Base Class - fill in the common stuff here, let detailed implementers fill in the gaps. Help them by providing abstract methods saying "your code goes here". Note that these methods need not only be the ones in the Interface. Also note that this Abstract Base Class might even implement more that one Interface! (eg. It's CleverThingWorker but also a IntermediateWorkPersister.)
Then we have the role who actually do the fine detailed implementation. Fill in the gaps here. Dead easy to understand. In this case you don't even need to consider the Interface as such. Your job is to make that abstract class concrete.
Bottom line ... I use both Interfaces and Base classes. You put the Interface on the Base Class. We don't add value by adding it to the implementation class.
If your user classes will always inherit from one base class, then you don't need the interface. If there is a possibility that you will have classes that match the interface but are not derived from the base class, then use the interface.
As for the interface being hidden in the base class and hence not immediately visible in the user class, this is normal and can be dealt withg by the compiler. This is also where good naming conventions come in - your UserDataObject has a name that matches IDataObject, as does DataObjectBase. You could add a comment to the class file that says it inherits from IDataObject, but it will be visible that it inherits from DataObjectBase, which in turn looks like it inherits from IDataObject by its name.
The other thing that needs to be mentioned is that the use of interfaces makes it easier to implement automated tests.
Say, for example, that one of the methods of the interface is supposed to throw a exception - such as 'DatabaseConnectionLostException' - and you want to test client code to check that it behaves correctly in such a situation.
It is a simple matter to provide an implementation of the interface that throws the exception, allowing the test to be written.
If you used the abstract base class instead of the interface, this operation would be quite a bit trickier (OK, you can use Mocks, but the interface solution is much cleaner)
Is multiple inheritance possible in VB .Net? If so, what is the syntax?
Short answer: No
Slightly longer answer: Yes, if you inherit multiple interfaces, and a single base class. Since this is usually the reason for MI (you want to implement multiple interfaces), it's usually enough. However, in those rare instances where "real" MI is useful, .NET prevents you from doing it.
It's possible in a restricted manner in VB.Net in the same way that it is in C#: via Interfaces. Since an interface works out to essentially a pure-abstract base class, you can inherit from as many of those as you need and from one real class.
As far as I know VB.net does not support multiple inheritance in general but you can reach a kind of multiple inheritance by working with interfaces (using “Implements” instead of “Inherits”):
Public Class ClassName
Implements BaseInterface1, BaseInterface2
End Class
That works fine for classes but I’d like to have an interface inheriting some base interfaces. Something like that:
Public Interface InterfaceName
Implements BaseInterface1, BaseInterface2
End Interface
But the “Implements” keyword is not allowed for interfaces (what makes sense, of course). I tried to use a kind of abstract class which I know from Java:
Public MustInherit Class InterfaceName
Implements BaseInterface1, BaseInterface2
End Class
But now I need to implement the defined methods from BaseInterface1 and BaseInterface2 within the InterfaceName class. But as InterfaceName should be an interface, too, I don’t want to have to implement these methods within that class.
In C# you can do that quite easy:
public interface InterfaceName: BaseInterface1, BaseInterface2 {}
Likely what you want to do is really composition or aggregation ( see here for design pattern). Maybe you're defining a behavior. You can always implement an interface SomeInterface in the base class, have a member of type SomeInterface (which lets it be any class that implements SomeInterface and can hence have the code does the implementing), in the members constructor pass a reference to the base class that owns it if necessary (if doing so, try to add another interface to define the callbacks, the base class will implement it and the subclass will have it as the member variable type). Use calls to the member class to implement SomeInterface. This way the code is implemented in another class, which makes it easy to maintain, but you're not doing multiple inheritance.
The idea behind composition is that an engine is not a car but a car has an engine. The car needs an engine, but doesn't need to know how a whole engine unit works, just how to interface with it. So the engine should not inherit from car. But having the car implement the engine is silly. So the car gets an engine as a member of the whole car, but as an object. The car has an engine as part of its composition.
It sounds like what you are doing is more of a behavior, like a duck object that has a quack behavior, but rubber ducks are ducks but do not quack but squeak. So they differ from mallard objects, but both have many other duck features in common. So you want to have a quack interface that each implements differently. But many ducks will quack for this interface, so you don't want to have to write quack for each one. That's where you use composition to implement the quack behavior interface.