Timeline for Understanding "programming to an interface"
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 20, 2022 at 15:08 | comment | added | Telastyn | @NoChance - people created a lot of useful things with a simple hammer and anvil too. If you don’t use interfaces and your fundamental behaviors change, you have to change all of the implementations anyways. The interface just makes it explicit (in most languages). | |
| Feb 19, 2022 at 10:11 | comment | added | NoChance | What if you need to expand the software capability, and need to add an extra method to the interface....All the classes that implement will need to change to obey the contract....Too much abstraction is harmful and complex. People created a lot of useful software using simple procedural programming. | |
| Jan 8, 2020 at 18:46 | comment | added | Amos Folarin | "Program to the Interface, not the Implementation" or "focus on what your code does not how it does it" Advantage: there the interface is the specification, and by specifying this you can later swap in any implementation of the specification. This indirection decouples the calling class from its object creation from by putting a "factory" middleman delegated to create the object, the way it creates the object is free to change, and the calling class won't be aware of the change in implementation. | |
| Dec 9, 2019 at 5:22 | comment | added | laike9m | Totally agree, Java programmers always relate everything to "class", this is horrible :( | |
| Jul 28, 2019 at 22:03 | comment | added | Kamafeather | All these concepts are good [..] for the very few scenarios where they make sense – I would remove the misleading "very few" from the sentence. Maybe "Hello world"s (that are purely for learning; so OOize it might still make sense) or some frontend project will still hold up; but this is the core of design, and is about the responsibility that one takes when wanting to be a professional developer. Small projects (especially libraries) benefit from good abstraction/design the same as big projects. Imho, "just coding/implementing" won't last long. | |
| Mar 14, 2017 at 13:44 | comment | added | Kyle Johnson | All these concepts are good in a book and for the very few scenarios where they make sense. With that being said, this may not be the best approach depending on your environment and/or application. At the end of the day you want your code to be simple, readable and maintainable. Building an OO version of Hello World with interfaces and abstract classes does not make sense. Don't get caught up in overusing best practices | |
| May 5, 2016 at 7:54 | comment | added | Laiv | @AvivCohn Also JEE specification is a good example. Every provider implements JEE specifications (interfaces or abstractions) its own way. Jboss for sure doesn't works exactly like Weblogic. Neither Weblogic does as Websphere does. However they all does what it's expected from a JEE platform | |
| May 5, 2016 at 7:51 | comment | added | Laiv | @AvivCohn I would suggest SpringFramework as a good example. Everything in Spring can be enhanced or customized by making your own impementation of their interfaces and Springs's main behaivor an features will keep working as expected... Or in case of customizations, as you expected. Programming to an interface is also the best strategy to design integration frameworks. Again Spring does with its spring-integration. At design time, programming to an interface is what we do with UML. Or it's what I would do. Abstract myself from the how it does and get focus on what to do. | |
| May 4, 2016 at 20:56 | comment | added | Stack Exchange Broke The Law | @AvivCohn Yes . | |
| May 4, 2016 at 19:01 | comment | added | JimmyJames | The existence of the 'turbo button': en.wikipedia.org/wiki/Turbo_button is an actual real world example of your floppy disk analogy. | |
| Dec 12, 2015 at 17:39 | comment | added | Deduplicator | @AvivCohn: "programming to an interface instead of a specific implementation" is a basic part of sound programming. And whether you are on the OO bandwagon or not, you should adhere to it. | |
| Mar 14, 2014 at 21:43 | comment | added | Aviv Cohn | Would you say that "programming to an interface, not to an implementation" is a principle that expresses the Abstraction OO principle? | |
| Mar 14, 2014 at 21:20 | comment | added | Telastyn | NO. List/ArrayList is not what I am talking about at all. It's more like providing an Employee object rather than the set of linked tables you use to store an Employee record. Or providing an interface to iterate through songs, and not caring if those songs are shuffled, or on a CD, or streaming from the internet. They're just a sequence of songs. | |
| Mar 14, 2014 at 20:16 | comment | added | Aviv Cohn | My question is: Can you give me more examples for places in real world code where the "programming to an interface" principle takes place? Other than the common example I described in the last comment? | |
| Mar 14, 2014 at 20:12 | comment | added | Aviv Cohn | Thanks for the answer. Judging by what you wrote I think I understand what "programming to an interface" means and what it's benefits are. But I have one question - The most common concrete example for this concept is this: When creating a reference to an object, make the reference type the interface type this object implements (or the superclass this object inherits), instead of making the reference type the object type. (Aka, List myList = new ArrayList() instead of ArrayList myList = new ArrayList(). (Question is in next comment) | |
| Mar 14, 2014 at 12:56 | history | answered | Telastyn | CC BY-SA 3.0 |