According to Adaic, an interface in Ada is defined as
a "tagged type with no components and no concrete operations". It can be used for multiple inheritance.
In contrast, an abstract type is a tagged type intended for use as an ancestor of other types, but which is not allowed to have objects of its own.
Is the essential difference between both just the multiple inheritance feature of the interface? Can the types otherwise be used interchangeably?
An interface cannot have any components, and all operations for one must be abstract. An abstract tagged type may have components and may have non-abstract operations.
A concrete type may extend multiple interfaces, but may only extend a single tagged type.
"IMHO, Interfaces are worthless."
Randy Brukardt, ARG member and ARM editor
Related
I have a class "Vertex" with 4 attributes and a class "Vertex_" with one attribute. The one attribute in Vertex_ is also in Vertex. Is it a good design to keep the two classes or is it better to program just the class Vertex, although there will be 3 variables, which are not used, when I instantiate an object which needs just the one attribute?
Class Vertex_ is actually somewhat a duplicate of Class Vertex.
I would suggest using inheritance and having Class Vertex inherit the attribute from the parent Class Vertex_ while having the 3 other attributes Class Vertex_ does not have.
TL;DR
This is a question that deserves a very long answer.There are two reasons for inheritance and the reason for doing it can depend on the language being used. One reason is for code reuse. Without knowing anything else about your situation, it would seem you are inheriting simply to reuse an attribute (but I suspect there could be more you will be reusing). But, there are other ways of getting code reuse without inheritance, for example containment, which is often a better way.
A powerful feature of object-oriented programming is the ability to substitute one type of object for another. When a message is sent to that object, the correct method implementation is invoked according the actual type of object receiving the message. This is one type of polymorphism. But in some languages the ability to substitute one object for another is constrained. In Java I can only substitute an instance of class B for an instance of class A if B is a descendant of A. So inheritance becomes important in Java to support polymorphism.
But what does it mean to be able to substitute a B instance for an A instance? Will it work? Class A has established a contract stating what each of its methods requires before you can successfully call it and at the same time states what each method promises to deliver. Will the methods of class B live up to that contract? If not, you really cannot substitute a B for an A and expect the program to run correctly. B may be a subclass of A but it is not a subtype of A (see Liskov substitution principle]).
In a language such as Python, inheritance is not required for polymorphism and coders are more apt to use it as code-reuse mechanism. Nevertheless, some people feel that subclassing should only be used to express subtyping. So, if Vertex_ is only using one of the four attributes it has inherited, I am doubtful that an instance of Vertex_ could be safely substituted for an instance of Vertex. I would not do the inheritance unless the language were C++ and then I would use private inheritance.
It's said in the documentation that
In native JS types, all concrete definitions must have = js.native as body. Any other body will be handled as if it were = js.native, and a warning will be emitted. (In Scala.js 1.0.0, this will become an error.)
And that's correct. However I found that I can omit body at all (thus making definition abstract) and there is no warning and generated js seems to be the same as with js.native body.
So my question is: what's the difference between abstract definitions and concrete definitions with js.native body?
The difference is that an abstract definition is abstract, and, well, a concrete definition (with = js.native) is concrete, from Scala's type system point of view.
But then what? From the use site of the class or trait, is doesn't make a difference. This is similar to normal Scala (or Java): when using a method, it doesn't matter whether it is abstract or not.
So the real difference is on the definition site. In theory, choosing abstract or concrete boils down to this criterium:
Does this method have an actual implementation in JavaScript code (not only a documented contract)? If yes, it should be concrete; if not, it should be abstract.
Practically and pragmatically, note that an abstract method can only appear in an abstract class or a trait, and must be implemented in a subclass/subtrait.
In terms of facade, in a native class, most methods should be concrete (if not all). That is because in JS, classes usually have concrete methods. In fact, abstract methods do not even exist in JS. The only reasonable case of defining an abstract method in a native class is if the "contract/documentation" of that class stipulates than a) it should be subclassed and b) subclasses should implement a particular method (not implemented in the superclass). This documented contract is as close as JS can get to abstract methods.
In JS traits, methods should usually be abstract (and the traits themselves be #ScalaJSDefined rather than #js.native). That is because traits/interfaces themselves do not even exist in JS. They only exist by their documented contract, which specifies what methods must/will be implemented by classes that satisfy this interface.
The only reasonable use case for concrete methods in (#js.native) JS traits is for DRYness. If several classes of a native API implement the same (large) set of methods, it can be reasonable to gather those methods in a native trait. In order not to have to repeat their definitions in all classes, they can be made concrete in the trait (if they were abstract, the classes would need to provided a concrete version to satisfy the contract). Note that such traits cannot be extended by non-native (#ScalaJSDefined) JS classes.
In the cases where you don't want to figure out the above "theoretical" criterium, use the following rule of thumb:
Is the method in a native JS class? If yes, it is almost certainly concrete.
Is it in a JS trait? If yes, it is almost certainly abstract (and the trait should be #ScalaJSDefined).
I was converting text to ASCII number in Powershell and having trouble with ToByte(). When I looked at the methods for string, I see that some of them show up with an interface prefix, whilst most don't.
Can anyone tell me the difference between these defintions? Why ToByte() starts with IConvertible, but PadLeft() doesn't? Any why ToString() has both of these notations?
Because those methods with the interface name are Explicit Interface Implementations.
If a class implements two interfaces that contain a member with the
same signature, then implementing that member on the class will cause
both interfaces to use that member as their implementation.
If the two interface members do not perform the same function,
however, this can lead to an incorrect implementation of one or both
of the interfaces. It is possible to implement an interface member
explicitly—creating a class member that is only called through the
interface, and is specific to that interface. This is accomplished by
naming the class member with the name of the interface and a period.
Explicit implementation is also used to resolve cases where two
interfaces each declare different members of the same name such as a
property and a method.
You can also see this listed in the String class documentation under Explicit Interface Implementations.
The Scala API lists something called Abstract Value Members under some classes and traits. What are these things and how do they differ from what the API lists as Concrete Values Members?
An abstract value has a name and a type but no value. This value has to be provided by a concrete val definition in a subclass. In contrast, concrete value members do have a name, type and value defined. It is as simple as that. Scala' abstraction mechanisms are more general than Java's.
I think it is covered in the link provided by #I.K. http://www.artima.com/pins1ed/abstract-members.html
Abstract Value Members are simple abstract members, i.e. members that don't have a value. Note that they are NOT necessarily vals but defs are included as well.
Whenever I create an abstract class I tend to create an interface to go along with it and have other code refer to the interface and not the abstract class. Usually when I don't create an interface to start with I regret it (such as having to override all implimented methods to stub the class for unit testing or later down the line new classes don't need any of the implimentation and override everything also finding themselves unable to extend any other class).
At first I tried to distinguish when to use an interface and when to use an abstract class by considering is-a vs able-to but I still would end up suffering later down the line for not making an interface to start with.
So the question is when is it a good idea to only have an abstract class and no interface at all?
When you wish to "give" some base class functionality to derived classes but when this functionality is not sufficient to instantiate a usable class, then go for abstract classes.
When you wish that some classes completely implement a set of methods (a public contract), then it is a convenient to define such contract with interfaces and enforce them onto classes by making them inherit this interface.
In short:
With abstract classes you give some common base functionality to derived classes. No further actions are necessary unless abstract class has some stubs (which have to be implemented down there).
With interfaces you require derived classes to implement a set of functions and you do not pass along any implementation.
So the question is when is it a good idea to only have an abstract class and no interface at all?
When you do not wish to enforce any public contract (a set of methods/properties defined by an interface).
Also when you do not plan to use certain coding techniques like casting object to an interface type (run-time polymorphism) or limit allowed input (some method argument will only accept object of types which implement certain interfaces).
Well, the main case it is useful to have only an abstract class without any interface is to mark a certain type. It is useful to be able to check if an object "is-a" something. These interface "mark" an objet to be of a certain type. Depending on the language you use, different design patterns apply ...
These sort of abstract classes exist in java. You can also use them in C++ with RTTI.
my2c