Say we are having multiple interfaces on a class
Class1: IInterface1, Interface2 {}
In cases we want to dependency inject implementation of these into seperate classes using IInterface1/IInterface2
Class Foo1(IInterface1 interface1) {}
Class Foo2(IInterface2 interface2) {}
We would have registrations for both of these interfaces in the container
container.Register<IInterface1,Class1>();
container.Register<IInterface2,Class1>();
Currently what I do is read the interfaces from the class type information and register the interfaces that are on them to the class.(using reflection). There is no convention here though
How are such scenarios usually handled. Any specific naming conventions that we can use for these scenarios or is it enough to register interface's by reading the class type information?
Related
When should I use an abstract class vs a regular class? More specifically, I'm trying to understand when constructor parameters should be preferred over abstract members.
For example:
sealed trait Client
abstract class BaseService {
def client: Client
}
class Service extends BaseService {
val client = ???
}
vs
sealed trait Client
class BaseService(client: Client) {}
class Service extends BaseService(client = ???)
As far as I can tell, both are valid.
As #Luis Miguel said, use abstract classes when you want to declare a common set of methods that need to be implemented by the sub-classes and/or share some limited functionality that will be used by all child classes.
Below, I'm listing some reasons why I considered you should pass your dependencies to the constructor rather than defining them in your classes/base-classes.
Use dependency injection
(IMHO) It is better to give the constructor the dependencies it needs to function properly AKA dependency injection.
Avoid tight coupling
When you declare a dependency inside your class or in your constructor, you are tightly coupling your Service with that specific implementation of the dependency, which is not ideal and is considered an antipattern.
Program to interfaces, not implementations
Injecting the dependencies gives you greater flexibility as you are not coupled to a specific implementation. This is true as long as your code relies on an interface/trait/abstract-class (consequently avoiding tight coupling).
When your class relies on an interface/trait/abstract-class can be very powerful as you can be passing a mock, a no-op, or different strategies of the client. So make sure you "Program to interfaces, not implementations".
What is the difference between a Plain Class Vs Abstract Class Vs Interfaces. Kindly, explain the same using snippets and demo.
Class:
It is a class without any abstract members. You can instantiate normal Class where as you cant instantiate Interface and Abstract class; you can just inherit from Abstract and Interface. Inherit from it (unless the class is sealed), use its methods, override those methods, etc.
Abstract Class:
May/mayn't contain Implementations; At least one member will not be implemented. A Class may inherit from a single Base class; multiple inheritance not allowed. Members have access modifiers May contain fields, properties, constructors, destructors, methods, events and indexers.
Interface:
Does not contain Implementations Interface can inherit from a number of interfaces(Multiple inheritance supported) Members are automatically public May contain properties, methods, events and indexers
In C++ I can make interface and class declarations. However, in contrast to C# the interface here is very likely to be a class so why is it there ?
interface Interface {
};
And
class Class {
};
As has been mentioned in comments, standard C++ does not support an "interface" construct directly. This is an extension from some vendors.
Other languages do (e.g Java).
The equivalent in standard C++ is an abstract base class, which does not have data members.
class SomeInterface
{
public:
virtual ~SomeInterface() = 0;
virtual void SomeAction(int flag) = 0;
};
Inheriting from such a class forces the derived class to override/implement all virtual functions, otherwise they cannot be instantiated.
Generally speaking, an abstract base class without data members can often get away without having non-trivial constructors (since the class has no members to initialise).
Unlike other languages that do support an interface construct, the abstract base class permits;
Having data members in the base class. (In which case constructors, destructors, assignment operators, etc may need to be defined to manage those members)
Having some members pure virtual and some not
Providing implementations of pure virtual methods (which must be explicitly overridden by derived class, but the base class version can be called)
Among my two processes' functionality, there is a common function to merge files. I need not going to insist any of the processes to have some methods as interface does. And, also the two processes are independent. So, is it fine I just go with an Abstract class and have the implementation in that abstract class itself? Also I do not need any abstract method.
Inheritance is used when there is IS-A relation between subclass and the base class. I don't think it is the case here. You didn't specify the language, but from your profile I guess you use Java. So if you use an Abstract Class you won't be able to inherit from other, more appropriate class in the future.
Instead of inheritance you can use composition. Which means that you create a regular file merging class which has this method to merge files. And in classes where you want to have this functionality you just instantiate this new file merging class. It lets you inherit from other class in the future.
If you want to inform the world that those classes can merge files (to use polymorphism), and you use Java 8 you can create default method inside an interface and implement this interface without override this default method. But I think composition will be better in this case.
Whenever I create an abstract class I tend to create an interface to go along with it and have other code refer to the interface and not the abstract class. Usually when I don't create an interface to start with I regret it (such as having to override all implimented methods to stub the class for unit testing or later down the line new classes don't need any of the implimentation and override everything also finding themselves unable to extend any other class).
At first I tried to distinguish when to use an interface and when to use an abstract class by considering is-a vs able-to but I still would end up suffering later down the line for not making an interface to start with.
So the question is when is it a good idea to only have an abstract class and no interface at all?
When you wish to "give" some base class functionality to derived classes but when this functionality is not sufficient to instantiate a usable class, then go for abstract classes.
When you wish that some classes completely implement a set of methods (a public contract), then it is a convenient to define such contract with interfaces and enforce them onto classes by making them inherit this interface.
In short:
With abstract classes you give some common base functionality to derived classes. No further actions are necessary unless abstract class has some stubs (which have to be implemented down there).
With interfaces you require derived classes to implement a set of functions and you do not pass along any implementation.
So the question is when is it a good idea to only have an abstract class and no interface at all?
When you do not wish to enforce any public contract (a set of methods/properties defined by an interface).
Also when you do not plan to use certain coding techniques like casting object to an interface type (run-time polymorphism) or limit allowed input (some method argument will only accept object of types which implement certain interfaces).
Well, the main case it is useful to have only an abstract class without any interface is to mark a certain type. It is useful to be able to check if an object "is-a" something. These interface "mark" an objet to be of a certain type. Depending on the language you use, different design patterns apply ...
These sort of abstract classes exist in java. You can also use them in C++ with RTTI.
my2c