Timeline for Do I need to use an interface when only one class will ever implement it?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 2, 2024 at 0:55 | comment | added | Mehdi Charife | "Interfaces are a tool for defining contracts between multiple subsystems of your application;" A concrete Java class also defines a contract through its public methods (API) | |
| Jun 1, 2020 at 10:20 | comment | added | Sylvain Rodrigue | @Shishir Gupta This is a common misunderstanding of interface. Many developpers doesn't know that every class has an implicite interface. Creating IMyClass and using it instead of MyClass add no isolation from (implicite) interface changes. | |
| May 2, 2019 at 19:48 | comment | added | Anna Klein | @ShishirGupta I was thinking the same. A good example there would be necessary to help to understand what he exactly means. | |
| Jun 18, 2018 at 18:05 | comment | added | Shishir Gupta | @sacundim If you make class Foo refer directly to class BarImpl, you're strongly committing yourself to change Foo every time you change BarImpl On changing BarImpl, what are the changes that can be avoided in Foo by using interface Bar? Since as long as signatures & functionality of a method doesn't change in BarImpl, Foo won't require change even without interface (the whole purpose of interface). I'm talking about the scenario where only one class i.e. BarImpl implements Bar. For multi class scenario, I understand Dependency Inversion Principle and how it interface is helpful. | |
| Sep 8, 2016 at 7:29 | comment | added | Alexander Derck | This makes it much easier to read the code (instead of asking "what the heck is this code supposed to do" you can ask "how does this code do what it's supposed to do"). Brilliant explanation | |
| Jul 19, 2016 at 14:07 | comment | added | sara | related to what is already written, but it's also great for keeping dirty dependencies out of layers you don't want them in. in you domain entities project, you probably want to be able to reference some kind of abstract repository for said entities. however, that doesn't mean you want a repository implementation in that project, because it will probably reference some DB vendor or some ORM and stuff like that. those things have nothing to do with the domain logic, and so they belong in another project focused on persistance. | |
| Sep 11, 2015 at 23:35 | history | edited | sacundim | CC BY-SA 3.0 | deleted 8 characters in body |
| Aug 1, 2015 at 8:43 | comment | added | Jules | +1 for separate compilation, which is sadly missing from the other answers. If class A uses class B directly, depending on language, A may need recompiling every time B is recompiled. Depend on an interface instead, and it only needs to be recompiled when the interface changes. See Bob Martin's original article on the Interface Segregation Principle for a detailed example in C++ (which is probably the worst language for this problem, but it exists in others too). | |
| Aug 9, 2012 at 1:01 | comment | added | sacundim | And last one: 5. Clients (ideally) shouldn't care how many classes my module has or how many, or even be able to tell. All they should see is a set of types, and some factories or façades to get the ball rolling. I.e., I often see value in encapsulating even what classes your library consists of. | |
| Aug 9, 2012 at 0:56 | comment | added | sacundim | 1. Code organization; having the interface in its own file that has only signatures and documentation comments helps keep code clean. 2. Frameworks that force you to expose methods that you'd rather keep private (e.g., containers that inject dependencies through public setters). 3. Separate compilation, as mentioned already; if class Foo depends on interface Bar then BarImpl can be modified without having to recompile Foo. 4. Finer-grained access control than public/private offers (expose the same class to two clients through different interfaces). | |
| Aug 8, 2012 at 23:50 | comment | added | Matthew Finlay | If the class is only performing one role (ie would only have one interface defined for it), then why not do this via public/private methods? | |
| Aug 8, 2012 at 9:05 | comment | added | Fabio Fracassi | I would upvote this much more than once, if I could. IMO the best answer to this question. | |
| Aug 7, 2012 at 18:07 | history | edited | sacundim | CC BY-SA 3.0 | added 319 characters in body |
| Aug 7, 2012 at 18:00 | history | answered | sacundim | CC BY-SA 3.0 |