- 🐻 Русский / Russian
-
Вопросы
When should i create interface?
Hello sir,
Does every class has interface? We are following such technique when i have behavior which use for only one client just create interface.It is due to only write unit test case.
Is it right approach to create interface for every behavior ?
Please suggest me the best practice to create interface.In refactoring i found the interface need to create when same behavior use by more then one client.
Thanks
Ответ
Hello Mahendra,
The main purpose of interfaces is to establish a "contract" between parts of your program—it's the way for client code to say "In this method I need any objects which can do this, this and that (described in interface). I don't really care about the class of that object, as long as it does what I need."
Let's see how this can be helpful using the analogy from real life:
You inherited a bar from your grandpa. There works a bartender named Joe. Some day Joe got drunk on the job and you decided to fire him. But there's a gotcha, only Joe knows how to handle the bar. You don't know how to replace him, because you don't know what potential candidate should be capable of doing.
So, your bar (client code) is coupled to the concrete class (Joe). In such case, you could only replace Joe with his son (subclass), who used to help Joe before and learned the ropes. But he's alcoholic too (inherited the behavior from Joe), so you have to think of something else.
Finally, you asked around and managed to write a job description for a bartender position (created the interface). And suddenly it seems that you can fill the position with anyone, who's capable of doing things listed in that document—be that experienced bartender or a part-time student.
Irony aside, here's how I decide whether or not I need an interface in particular situation:
- Would I need to replace this class in some client code with some other class in the future?
- Or do I have to provide some extension point for other people using this code, so that they could pass their own classes instead of default one?
If the answer is yes (for any of above), I create the interface and link the client code to the interface rather to a concrete class.
If the answer is no, I don't create interface and tie the code to a class. But even if in the future it turns out that I actually need some flexibility, I can use the Extract Interface refactoring to create a common interface.
Please note, that like any real life contract, interfaces create the burden of bureaucracy. Plus, the complexity: you create several entities (interface + class) instead of just one (a class). That's why I would not suggest creating interfaces for each class in the program.
Hope this makes sense!
Сервис поддержки клиентов работает на платформе UserEcho
Hello Mahendra,
The main purpose of interfaces is to establish a "contract" between parts of your program—it's the way for client code to say "In this method I need any objects which can do this, this and that (described in interface). I don't really care about the class of that object, as long as it does what I need."
Let's see how this can be helpful using the analogy from real life:
You inherited a bar from your grandpa. There works a bartender named Joe. Some day Joe got drunk on the job and you decided to fire him. But there's a gotcha, only Joe knows how to handle the bar. You don't know how to replace him, because you don't know what potential candidate should be capable of doing.
So, your bar (client code) is coupled to the concrete class (Joe). In such case, you could only replace Joe with his son (subclass), who used to help Joe before and learned the ropes. But he's alcoholic too (inherited the behavior from Joe), so you have to think of something else.
Finally, you asked around and managed to write a job description for a bartender position (created the interface). And suddenly it seems that you can fill the position with anyone, who's capable of doing things listed in that document—be that experienced bartender or a part-time student.
Irony aside, here's how I decide whether or not I need an interface in particular situation:
If the answer is yes (for any of above), I create the interface and link the client code to the interface rather to a concrete class.
If the answer is no, I don't create interface and tie the code to a class. But even if in the future it turns out that I actually need some flexibility, I can use the Extract Interface refactoring to create a common interface.
Please note, that like any real life contract, interfaces create the burden of bureaucracy. Plus, the complexity: you create several entities (interface + class) instead of just one (a class). That's why I would not suggest creating interfaces for each class in the program.
Hope this makes sense!