Class vs Interface
No, the interface is not a class.
An interface is a collection of method signatures and possibly properties that all refer to the same idea. For example, the IList interface will have methods for indexing, inserting, and getting the cardinality. However, it does not specify implementation details. The list interface can be implemented as a linked list, or a wrapped array, or whatever, as long as it defines these methods in the interface.
A class is a template from which the actual object is created. Classes are a collection of method signatures as well as implementations of those methods.
No, an interface is not a class as it just defines a specific contract, and a class defines all the behavior of an object.
Commenter SquareCog points out exactly that the above is not entirely true. Since classes can be subclassed and methods overridden, the relationship between the class and the actual behavior of the object becomes somewhat complicated. I'm just going to convey this problem by saying that classes are separate entities. You can read the source code for the class and see what behavior this class covers. However, at run time, objects are of types instead of classes. Types are the entire inheritance tree instead of a separate class, and thus type behavior can be defined for several different classes. Fortunately, this does not change the basic conceptual difference that interfaces are contracts that may imply (via names, argument types, etc.) certain implementations, but cannot provide anything.apart from method signatures, while classes define an implementation, even if it is not the actual implementation used at runtime.
source to share
From a logical point of view, they are very similar. As others have noted, ABC 1 with only public abstract members would be almost the same target as an interface.
When you move on to nuts and bolts, they have a number of important differences.
- A class can only inherit from one base class, but it can implement many interfaces.
- A value type already derived from ValueType cannot inherit from ABC, but it can implement an interface.
- The class can contain fields and static members. The interface can't.
- A class can contain an implementation, an interface cannot.
- A class can have private and protected members; an interface cannot.
- Abstract ABC members are always virtual. A class can implement an interface with non-virtual members.
1: Abstract base class
source to share
Java interface is not a class; it is a declaration of methods to be executed by the classes; description of abilities, if you like. Abstract classes in Java are an interesting halfway point between the correct classes and interfaces, as they define the methods available, but also provide some default implementations.
The fundamental difference between an abstract class and an interface in Java is that you can only extend one class; you can implement multiple interfaces. An abstract class describes what you are; the interface describes what you can do . What you also define what you can do, but has a much stronger meaning.
source to share
In general, an interface is a type that a class can implement to indicate that a class exposes behavior through a set of methods. For example, .Net has an ICollection
interface that contains methods for interacting with a collection.
In C ++, an interface is a class where each method is abstract.
In Java and .Net, interfaces are independent types, not related to classes.
In any case, classes can implement interfaces.
source to share
It is useful to think of .NET as having three "safe" type types in .net: interfaces, classes, and value types (there are also things like pointers, etc., but that's another story) and three main context classes can be used: storage locations, heap objects, and general limits.
Heap objects can be of any type, but all heap objects behave like class objects. Interface-type heap objects are rare; they are usually not created inside .net, but can be generated by code designed to work with old object models. Class type heap objects contain one store for each field; heaps of value type objects contain a single store whose type is the value type.
The storage location can also be of any type, but the value storage type is different from others. The storage location of the class type or interface type contains a reference to the class. The storage location of the value type contains either a value primitive (byte, integer, char, floating point, etc.) or also contains a storage location for each field of the value type (so, for example, storage location type Point
contains two storage locations of type Int32
, each containing a signed 32-bit integer primitive).
Generic constraints can also be of any type, but constraints on interface types do not constrain the parameter of a constrained type itself as a class type, interface type, or value type. A declared method void Foo<T>(T param) where T:IWowzo
can be called with a parameter of a class type, interface type, or value type. If the procedure is called with a parameter of a value type, then param
any other storage locations declared as a type T
will be stored as value types. If a procedure is called with a parameter of a class type or an integer type, then param
any other storage locations declared as a type T
will be stored as class references. It is important to note that if T
itself is an interface ( IWozo
or derivative) type, thenparam
will be passed as a reference to a heap object and will behave like one regardless of whether the type of the instance object is a class object or a value type. If struct Bar
implements IWowzo
, and myBar
is a type variable Bar
, the call Foo<Bar>(myBar)
can give different semantics from Foo<IWowzo>(myBar)
; in the former case, the parameter will behave like a value type, and in the latter case, it will behave like a class type.
source to share