Blog About Contact. What's an interface anyway? How do I define an interface? Our application can then contain the following code:. Now say we want to extend the functionality to other file types such as XML. A blueprint tells you how to build something. An interface specifically avoids telling you how to build something.
A blueprint typically includes the internals. But a interface is purely about what is visible on the outside of a class The interface consists of the signatures of methods and values of constants, and also a typically informal "behavioral contract" between classes that implement the interface and others that use it.
In Programming, an interface defines what the behavior a an object will have, but it will not actually specify the behavior. It is a contract, that will guarantee, that a certain class can do something. The Game class requires a secret number. For the sake of testing it, you would like to inject what will be used as a secret number this principle is called Inversion of Control. The game class wants to be "open minded" about what will actually create the random number, therefore it will ask in its constructor for "anything, that has a Generate method".
First, the interface specifies, what operations an object will provide. It just contains what it looks like, but no actual implementation is given. This is just the signature of the method. Conventionally, in C interfaces are prefixed with an I. The classes now implement the IGenerate Interface. This means that the compiler will make sure, that they both have a method, that returns an int and is called Generate. The game now is being called two different object, each of which implementant the correct interface.
Other classes would produce an error upon building the code. A class is commonly seen as a blueprint for an object. An Interface specifies something that a class will need to do, so one could argue that it indeed is just a blueprint for a class, but since a class does not necessarily need an interface, I would argue that this metaphor is breaking.
Think of an interface as a contract. The class that "signs it" will be legally required enforced by the compiler police , to comply to the terms and conditions in the contract. This means that it will have to do, what is specified in the interface. This is all due to the statically typed nature of some OO languages, as it is the case with Java or C. In Python on the other hand, another mechanism is used:. Here, none of the classes implement an interface. Python does not care about that, because the SecretGame class will just try to call whatever object is passed in.
If the object HAS a generate method, everything is fine. This mistake will not be seen at compile time, but at runtime, so possibly when your program is already deployed and running. C would notify you way before you came close to that. The reason this mechanism is used, naively stated, because in OO languages naturally functions aren't first class citizens.
One does not really need the classes at all. In Python, therefore, one could just throw them away and pick the functions on their own:. A lambda is just a function, that was declared "in line, as you go".
A delegate is just the same in C :. Side note: The latter examples were not possible like this up to Java 7. There, Interfaces were your only way of specifying this behavior. Technically, I would describe an interface as a set of ways methods, properties, accessors Semantically, an interface could also contain conventions about what you may or may not do e.
Personally I see an interface like a template. If a interface contains the definition for the methods foo and bar , then you know every class which uses this interface has the methods foo and bar. Let us consider a Man User or an Object wants some work to be done. He will contact a middle man Interface who will be having a contract with the companies real world objects created using implemented classes. Unlike a class, an interface never implements methods; instead, classes that implement the interface implement the methods defined by the interface.
A class can implement multiple interfaces. The bicycle class and its class hierarchy define what a bicycle can and cannot do in terms of its "bicycleness. Programming to an interface means that when you are presented with some programming interface be it a class library, a set of functions, a network protocol or anything else that you keep to using only things guaranteed by the interface. You may have knowledge about the underlying implementation you may have written it , but you should not ever use that knowledge.
For example, say the API presents you with some opaque value which is a "handle" to something internal. Your knowledge might tell you that this handle is really a pointer, and you could dereference it and access some value, which might allow you to easily accomplish some task you want to do.
But the interface doesn't provide you with that option; it's your knowledge of the particular implementation that does. The problem with this is that it creates a strong coupling between your code and the implementation, exactly what the interface was supposed to prevent. Depending on the politics it might either mean that the implementation can no longer be changed, because that would break your code, or that your code is very fragile and keeps breaking on every upgrade or change of the underlying implementation.
A big example of this is programs written for Windows. The WinAPI is an interface, but many people used tricks that worked because of the particular implementation in, say Windows These tricks maybe made their programs faster, or allowed them to do things in less code than would have otherwise been necessary. But these tricks also meant that the program would crash on Windows , because the API was implemented differently there.
If the program was important enough, Microsoft might actually go ahead and add some hack to their implementation so the the program would continue to work, but the cost of that is increased complexity with all the ensuing problems of the Windows code. It also makes life extra-hard for the Wine people, because they try to implement the WinAPI as well, but they can only refer to the documentation for how to do this, which leads to many programs not working as they should because they accidentally or intentionally rely on some implementation detail.
I can only talk about my personal experience, as this has never been formally taught to me either. Your first point is correct. The gained flexibility comes from not being able to accidentally invoke implementation details of the concrete class where they shouldn't be invoked.
When your logger is used in your application, it shouldn't be the concern of the consuming code to set the sysAdminEmail. This property should be set during the logger setup and should the be concealed from the world. If you were coding against the concrete implementation, then you might accidentally set the implementation property when using the logger. Now, your application code is tightly coupled to your logger, and switching to another logger will require first decoupling your code from the original one.
Regarding your second point: Another reason I have seen for coding to an interface is to reduce the complexity of code. It is not uncommon for a single game components to have both 2D and 3D renderable content. Other components may be only 2D and others only 3D. If 2D rendering is done by one module, then it makes sense for it to maintain a collection of I2DRenderable s.
It doesn't matter if the objects in its collection are also I3DRenderable or IUpdateble as other modules will be responsible for treating those aspects of the objects.
Storing the renderable objects as a list of I2DRenderable keeps the complexity of the rendering class low. In this sense, coding to an interface keeps complexity low by isolating concerns.
A Mains electricity plug in an Interface. Yes; that three-pinned thing on the end of the power cord from your TV, radio, vacuum cleaner, washing machine, etc.. Any appliance that has a main plug i.
What each individual appliance does is entirely different. You're not going to get very far cleaning your carpets with the TV and most people don't watch their washing machine for entertainment.
But all of these appliances share the common behaviour of being able to be plugged into a wall socket. That's what Interfaces get you. Unified behaviours that can be carried out by many different Classes of Object, without the need for the complications of Inheritance.
There are perhaps two usages of the word interface being used here. The interface you are mainly referring to in your question is a Java Interface. That is specifically a Java concept, more generally it's a programming language interface. I would say that programming to an interface is a broader concept. The now popular REST APIs that are available for many websites are another example of the broader concept of programming to an interface at a higher level.
By creating a layer in between your code's inner workings and the outside world people on the internet, other programs, even other parts of the same program you can change anything inside your code as long as you don't change what the outside world is expecting, where that is defined by an interface, or contract that you intend to honour.
0コメント