As of 12/15/2020, I have included additional information on the concept of "types" in TypeScript and similar ideas in other programming languages.
If I'm not mistaken, you may be uncertain about the distinction between an interface and a type.
In object-oriented programming, interfaces do not contain implementations, while types do. This implies that an interface is essentially useless unless a type implements it. Additionally, a type can only extend one other type but can implement multiple interfaces.
But what does this all mean...
Consider having a Car and a User - two vastly different types that may not seem immediately related practically. Some might suggest creating ICar and IUser for them. However, thinking in terms of interfaces this way can lead to confusion. Would it make sense for User to implement ICar or would ICar simply duplicate the functionality of Car? How would another programmer interpret the code?
Imagine wanting both objects to be "Self Describable" and provide information in the same manner. In such a scenario, you would create:
ISelfDescribable {
getSelfDescription();
}
Subsequently, you could do the following:
Car implements ISelfDescribable {
getSelfDescription(return "I am a car!");
}
User implements ISelfDescribable {
getSelfDescription(...provide info differently...);
}
An array containing these objects would look like (imagine how you would achieve this without interfaces):
Array<ISelfDescribable>
Now, you (and any other developer inspecting the code) can be certain that each object in this array, regardless of its concrete type, follows the "behavior" defined by ISelfDesribable. When you think about it, there's actually no need to know the exact type as long as you're implementing the behavior. However, you still need the type to define that behavior.
Suppose someday you decide both objects should be "Insurable." They should both feature a method setInsurancePolicy. You could introduce IInsurable { setInsurancePolicy(policy: Policy) }, then implement it in the relevant types. Now you have objects that are both ISelfDescribable and IInsurable, and you can group those objects under either category in an array.
For me, the pivotal moment came when I grasped this idea: types (and type hierarchies) pertain to concrete entities, while interfaces deal with behaviors that can be shared across various types. There's more complexity to it, but at least you now have an understanding of why one would opt for an interface over a type. They represent distinct concepts in programming, despite their apparent similarities.
(Additional note: Languages like Scala approach interfaces differently. While they acknowledge "behaviors," the ability to implement and override these behaviors expands beyond conventional interface structures. This detail may delve too deeply into academic discussions for this context, but I digress – gotta vanquish all dungeon monsters, not just those tied to quests.)
12/15/2020: TypeScript: Types vs. Interfaces.
When should you choose one over the other? Once again, it hinges on what you intend to convey and how you plan to utilize it.
A "type" serves as the solution for "I require a contract, but it doesn't denote a behavior definition akin to an interface."
This ensures a clear semantic differentiation. An interface signifies a horizontal behavior, whereas a type defines...well, a type.
Furthermore, types offer functional advantages that interfaces lack, as they allow for combination and intersection. In React, it's often advised, "don't use interfaces since they aren't as versatile as types in terms of composition."
Imagine needing to specify a contract for two service calls' payloads. Interface wouldn't suit this purpose; it's reserved for horizontal behaviors. However, a "type" fits perfectly as it delineates the payload structure without prescribing a specific behavior.
And in cases where you must merge definitions from two payload types into one (e.g., for a UI component), language features like union/intersection become straightforward with "type" definitions.
The underlying principle remains intact; interfaces focus on behavioral aspects, while types handle vertical definitions that can be blended in diverse ways.