Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>Q1. As interfaces are having only abstract methods (no code) so how can we say that if we are implementing any interface then it is inheritance ? We are not using its code.</p> </blockquote> <p>Unfortunately, in colloquial usage, the word <code>inheritance</code> is still frequently used when a class implements an interface, although <code>interface implementation</code> would be a preferable term - IMO, the term <code>inheritance</code> should strictly be used with inheritance of a concrete or abstract class. In languages like C++ and C#, the same syntax (i.e. <code>Subclass : Superclass</code> and <code>Class : Interface</code>) is used for both class inheritance and interface implementation, which may have contributed to the spread of the misuse of the word <code>inheritance</code> with interfaces. Java has different syntax for <code>extend</code>ing a class as opposed to <code>implement</code>ing an interface, which is a good thing.</p> <blockquote> <p>Q2 If implementing an interface is not inheritance then How interfaces are used to achieve multiple inheritance ?</p> </blockquote> <p>You can achieve the 'effect' of multiple inheritance through composition - by implementing multiple interfaces on a class, and then providing implementations for all methods, properties and events required of all the interfaces on the class. One common technique of doing this with concrete classes is by doing 'has-a' (composition) relationships with classes which implement the external interfaces by 'wiring up' the implementation to each of the internal class implementations. (Languages such as C++ do support multiple concrete inheritance directly, but which creates other potential issues like the diamond problem).</p> <blockquote> <p>Q3 Anyhow what is the benefit of using Interfaces ? They are not having any code. We need to write code again and again in all classes we implement it.</p> </blockquote> <p>Interfaces allow existing classes (e.g. frameworks) to interact with your new classes without having ever 'seen' them before, because of the ability to communicate through a known interface. Think of an interface as a contract. By implementing this interface on a class, you are contractually bound to meet the obligations required of it, and once this contract is implemented, then your class should be able to be used interchangeably with any other code which consumes the interface.</p> <blockquote> <p>Real World Example</p> </blockquote> <p>A 'real world' example would be the legislation and convention (interface) surrounding an electrical wall socket in a particular country. Each electrical appliance plugged into the socket needs to meet the specifications (contract) that the authorities have defined for the socket, e.g. the positioning of the line, neutral and earth wires, the position and colouring of the on / off switch, and the conformance the the electrical voltage, frequency and maximum current that will be supplied through the <code>interface</code> when it is switched on.</p> <p>The benefit of decoupling the interface (i.e. a standard wall socket) rather than just soldering wires together is that you can plug (and unplug) a fan, a kettle, a double-adapter, or some new appliance to be invented next year into it, even though this appliance didn't exist when the interface was designed. Why? Because it will <em>conform</em> to the requirements of the interface.</p> <blockquote> <p>Why use interfaces?</p> </blockquote> <p>Interfaces are great for loose coupling of classes, and are one of the mainstay's of Uncle Bob's <a href="http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29" rel="nofollow noreferrer">SOLID</a> paradigm, especially the <code>Dependency Inversion Principle</code> and <code>Interface Segregation Principles</code>.</p> <p>Simply put, by ensuring that dependencies between classes are coupled only on interfaces (abstractions), and not on other concrete classes, it allows the dependency to be substituted with any other class implementation which meets the requirements of the interface.</p> <p>In testing, stubs and mocks of dependencies can be used to unit test each class, and the interaction the class has with the dependency can be 'spyed' upon.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload