Interface

Interface




Interface (computing)

Page issues
In computing, an interface is a shared boundary across which two or more separate components of a computer system exchange information. The exchange can be betweensoftware, computer hardware, peripheraldevices, humans and combinations of these. Some computer hardware devices, such as atouchscreen, can both send and receive data through the interface, while others such as a mouse or microphone may only provide an interface to send data to a given system.[1]

Hardware interfacesEdit

Hardware interfaces exist in many of the components, such as the various buses,storage devices, other I/O devices, etc. A hardware interface is described by the mechanical, electrical and logical signals at the interface and the protocol for sequencing them (sometimes called signaling).[2] A standard interface, such as SCSI, decouples the design and introduction of computing hardware, such as I/O devices, from the design and introduction of other components of a computing system, thereby allowing users and manufacturers great flexibility in the implementation of computing systems.[2]Hardware interfaces can be parallel with several electrical connections carrying parts of the data simultaneously, or serial where data is sent one bit at a time.

Software InterfacesEdit

A software interface may refer to a wide range of different types of interface at different "levels": an operating system may interface with pieces of hardware.Applications or programs running on the operating system may need to interact viastreams, and in object oriented programs, objects within an application may need to interact via methods.

Software interfaces in practiceEdit

A key principle of design is to prohibit access to all resources by default, allowing access only through well-defined entry points, i.e. interfaces.[3] Software interfaces provide access to computer resources (such as memory, CPU, storage, etc.) of the underlying computer system; direct access (i.e. not through well designed interfaces) to such resources by software can have major ramifications—sometimes disastrous ones—for functionality and stability.
Interfaces between software components can provide: constants, data types, types ofprocedures, exception specifications andmethod signatures. Sometimes, publicvariables are also defined as part of an interface.
The interface of a software module A is deliberately defined separately from theimplementation of that module. The latter contains the actual code of the procedures and methods described in the interface, as well as other "private" variables, procedures, etc. Another software module B, for example the client to A, that interacts with A is forced to do so only through the published interface. One practical advantage of this arrangement is that replacing the implementation of A by another implementation of the same interface should not cause B to fail—how A internally meets the requirements of the interface is not relevant to B, which is only concerned with the specifications of the interface. (See alsoLiskov substitution principle.)

Software interfaces in object-oriented languagesEdit

In object-oriented languages, the terminterface is often used to define an abstract type that contains no data or code, but defines behaviors as method signatures. Aclass having code and data for all the methods corresponding to that interface is said to implement that interface.[4]Furthermore, a class can implement multiple interfaces, and hence can be of different types at the same time.[5]
An interface is thus a type definition; anywhere an object can be exchanged (for example, in a function or method call) the typeof the object to be exchanged can be defined in terms of its interface rather than specifying a particular class. This approach means that any class that implements that interface can be used. For example, a dummy implementation may be used to allow development to progress before the final implementation is available. In another case, a fake or mock implementation may be substituted during testing. Such stubimplementations are replaced by real code later in the development process.
Usually a method defined in an interface contains no code and thus cannot itself be called; it must be implemented by non-abstract code to be run when it is invoked. An interface called "Stack" might define two methods: push() and pop(). It can be implemented in different ways, for example, FastStack and GenericStack—the first being fast, working with a stack of fixed size, and the second using a data structure that can be resized, but at the cost of somewhat lower speed.
Though interfaces can contain many methods they may contain only one or even none at all. For example, the Java language defines the interface Readable that has the single read() method; various implementations are used for different purposes, including BufferedReader, FileReader, InputStreamReader, PipedReader, and StringReader. Marker interfaces likeSerializable contain no methods at all and serve to provide run-time information to generic processing using Reflection.[6]

Programming to the interfaceEdit

The use of interfaces allows for a programming style called programming to the interface. The idea behind this approach is to base programming logic on the interfaces of the objects used, rather than on internal implementation details. Programming to the interface reduces dependency on implementation specifics and makes code more reusable.[7]
Pushing this idea to the extreme, inversion of control leaves the context to inject the code with the specific implementations of the interface that will be used to perform the work.

User interfacesEdit

A user interface is a point of interaction between a computer and humans; it includes any number of modalities of interaction (such as graphics, sound, position, movement, etc.) where data is transferred between the user and the computer system.

See alsoEdit



Virtual inheritance

For inheritance of virtual functions, seevirtual function.
Virtual inheritance is a C++ technique that ensures only one copy of a base class's member variables are inherited by grandchild derived classes.
                X
               / \
              /   \
     virtual /     \ virtual
            A       B
             \     /
              \   /
               \ /
                C

Without virtual inheritance, if classes A and Bboth inherit from class X, and class C inherits from classes A and B, then class C will contain two copies of X's member variables: one via A, and one via B. These will be accessible independently, using scope resolution.
Instead, if classes A and B inherit virtually from class X, then objects of class C will contain only one set of the member variables from class X.
This feature is most useful for multiple inheritance, as it makes the virtual base a common subobject for the deriving class and all classes that are derived from it. This can be used to avoid the diamond problem by clarifying ambiguity over which ancestor class to use, as from the perspective of the deriving class (C in the example above) the virtual base (X) acts as though it were the direct base class of C, not a class derived indirectly through its base (A).[1][2]
It is used when inheritance represents restriction of a set rather than composition of parts. In C++, a base class intended to be common throughout the hierarchy is denoted as virtual with the virtual keyword.
Consider the following class hierarchy.
class Animal {
 public:
  virtual ~Animal() { }
  virtual void eat();
};

class Mammal : public Animal {
 public:
  virtual void breathe();
};

class WingedAnimal : public Animal {
 public:
  virtual void flap();
};

// A bat is a winged mammal
class Bat : public Mammal, public WingedAnimal {
};

Bat bat;
As declared above, a call to bat.eat() is ambiguous because there are two Animal(indirect) base classes in Bat, so any Bat object has two different Animalbase class subobjects. So an attempt to directly bind a reference to the Animalsubobject of a Bat object would fail, since the binding is inherently ambiguous:
Bat b;
Animal &a = b; // error: which Animal subobject should a Bat cast into, 
               // a Mammal::Animal or a WingedAnimal::Animal?
To disambiguate, one would have to explicitly convert bat to either base class subobject:
Bat b;
Animal &mammal = static_cast<Mammal&> (b); 
Animal &winged = static_cast<WingedAnimal&> (b);
In order to call eat(), the same disambiguation, or explicit qualification is needed: static_cast<Mammal&>(bat).eat() or static_cast<WingedAnimal&>(bat).eat() or alternatively bat.Mammal::eat() and bat.WingedAnimal::eat(). Explicit qualification not only uses an easier, uniform syntax for both pointers and objects but also allows for static dispatch, so it would arguably be the preferable method.
In this case, the double inheritance of Animal is probably unwanted, as we want to model that the relation (Bat is an Animal) exists only once; that a Bat is aMammal and is a WingedAnimal does not imply that it is an Animal twice: an Animal base class corresponds to a contract that Bat implements (the "is a" relationship above really means "implements the requirements of"), and a Bat only implements the Animal contract once. The real world meaning of "is a only once" is that Bat should have only one way of implementing eat(), not two different ways, depending on whether the Mammalview of the Bat is eating, or the WingedAnimal view of the Bat. (In the first code example we see that eat() is not overridden in either Mammal or WingedAnimal, so the two Animalsubobjects will actually behave the same, but this is just a degenerate case, and that does not make a difference from the C++ point of view.)
This situation is sometimes referred to asdiamond inheritance (see Diamond problem) because the inheritance diagram is in the shape of a diamond. Virtual inheritance can help to solve this problem.

The solutionEdit

We can re-declare our classes as follows:
class Animal {
 public:
  virtual ~Animal() { }
  virtual void eat();
};

// Two classes virtually inheriting Animal:
class Mammal : public virtual Animal {
 public:
  virtual void breathe();
};

class WingedAnimal : public virtual Animal {
 public:
  virtual void flap();
};

// A bat is still a winged mammal
class Bat : public Mammal, public WingedAnimal {
};
The Animal portion of Bat::WingedAnimal is now the same Animal instance as the one used by Bat::Mammal, which is to say that a Bat has only one, shared, Animalinstance in its representation and so a call to Bat::eat() is unambiguous. Additionally, a direct cast from Bat to Animal is also unambiguous, now that there exists only one Animal instance which Bat could be converted to.
The ability to share a single instance of the Animal parent between Mammal and WingedAnimal is enabled by recording the memory offset between the Mammal or WingedAnimal members and those of the base Animal within the derived class. However this offset can in the general case only be known at runtime, thus Bat must become (vpointer, Mammal, vpointer, WingedAnimal, Bat, Animal). There are two vtable pointers, one per inheritance hierarchy that virtually inherits Animal. In this example, one for Mammal and one for WingedAnimal. The object size has therefore increased by two pointers, but now there is only one Animal and no ambiguity. All objects of type Bat will use the same vpointers, but each Bat object will contain its own uniqueAnimal object. If another class inherits from Mammal, such as Squirrel, then the vpointer in the Mammal part of Squirrel will generally be different to the vpointer in the Mammal part of Batthough they may happen to be the same should the Squirrel class be the same size as Bat.

Comments

Popular posts from this blog

Truecaller

Capacitors

Microwaves