I'm familiar with the practical aspects of OOP. Now I'm writing a technical document and I'm questioning my use of terms.
Take this class hierarchy. Each class has zero, one, or more (multiple inheritance) classes it directly derives from. For B, this is A. I'd say that A is B's base class or superclass (interchangeably).
Conversely, a class can have any number of classes directly deriving from it. I'd say that B and C are A's derived classes or subclasses, again interchangeably.
Yet there must also be a term to refer to all classes a class directly or indirectly inherits from. How would you call {A, B} from D's perspective?
And I'm missing another term for all classes directly or indirectly derived from a class. How would you call {B, C, D, E} from A's perspective?
Good questions. In this case, A is the root class, as all other classes inherit from it. All objects descend from A, or are either direct or indirect subclasses of A. The opposite is also true. B is a direct superclass of D and A is an indirect superclass. I suppose you could use the word ancestor as the opposite of descend/descendant, but I haven't seen this before.
Related
For a UML Class Diagram, if a class A has a composition relationship with another class B, does it work like inheritance? I know that the class A cannot exist without class b but does class A inherit the attributes and methods from class B?
Composition over inheritance
In OO design, a common advice is to prefer composition over inheritance. This might mislead to think that there is a relation between these two different concepts:
Inheritance is about a relation between classes.
Composition is a about relations between objects of classes.
Even more misleading: the "composition" used in the general OO literature corresponds in general to a simple UML association and is not to be understood as restrictive as the UML "composition".
Inheritance is about generalisation and specialisation
If class D inherits from B, it means that D specialises a more general concept B:
It has all the properties and operations of B (without need to repeat them in the diagram),
It can have additional properties and operations that are not relevant for B, and
It can perform some operations of B differently.
Any object of class D is also an object of class B for its full lifetime. This is why we speak of a "Is a" relationship.
Naive example (just for the illustration):
Composition is about association of objects of very different classes
If class B "composes" (has a composition association with) C, it means that the B object can be associated with different C objects over its lifetime. Anf that objects of class C :
always belong to a B object that owns it. This is why we sometimes speak of a "has a" relationship;
will not survive its owning B object .
Caution: UML composition is about an exclusive ownership. In the OO literature, the term "composition" often refers to weaker associations without any ownership or even exclusivity.
Naive example (just for the illustration):
Inheritance and composition are two different concepts. If they were the same there would not be the need to have different notation.
Compostion is about lifetime of objects. Composed elements will be destroyed the moment the owner is destroyed. But each instance can (and likely will) be something completely different than the composing object. The well known example is a car: When you shredder a car its composed wheels will be shreddered as well. Only if you detach them beforehand they can live on.
Inheritance means that instances will have operations and attributes on their own defined in the parent class. This works in each single instance. There's no good real worl example for inheritance (genes work different and inherited assets also don't help here).
if a class A has a composition relationship with another class B
Lets suppose you mean A <*>--- B or A <*>---> B rather than the reverse (B <*>--- A or B <*>---> A), because this is not very clear in your question.
class A cannot exist without class b
It is not about classes but about instances of these classes, and B can have instances independently of that composition, so the limited life is not for all instances of B.
does it work like inheritance? does class A inherit the attributes and methods from class B ?
No.
A inherits B means A is a B, this is absolutely not the case having A <*>--- B or A <*>---> B or the reverse.
Then independently of the visibility of the operations you cannot apply the operations of A to the instances of B nor the reverse, except of course if you also have an inheritance more that the composition.
About the attributes of B depending on the way the composition is implemented it is possible they are part of the corresponding instance of A, this is the case for instance in C++ not using a pointer for the composition. But anyway that does not means these attributes of B are attributes of A, to access them it is needed to first access of the instance of B though the compositions, and that also supposes an instance of A has the right to directly access these attributes of B, so they are typically public.
Note also you can have A<*>--->B<*>--->A etc and fortunately that does implies A inherits B and B inherits A which is impossible
I'm trying to understand how inheritance with association work between the superclass and its subclasses. Here are the classes with their relationships:
my question here if I created an object from class C, will it inherit also from class A as below? and why?
No. It won't inherit anything. B inherits from A so C will see a B with operations/attributes inherited from A.
If I (class C) use a cleaning device B that inherited from Sponge (A) I will see/use a soft cleaning device. If B inherited from steel it would be steel wool. If inherting from sand it would be sand paper. All cleaning devices with different usability depending from where they inherit. But I wouldn't change in any way. Only the way I would "clean" things. (I know, a horrible example)
N.B. As #www.admiraalit.nl commented your object diagram does not match the class diagram.
Diamond problem is handled in some OOPS languages (eg. curl) by having the repeatedly inherited class as "shared"? I want to know how this works. Also, I want to know the role played by primary and secondary constructors in solving the diamond problem in these OOPS languages when shared strategy is used.
Suppose there are 4 classes say A,B,C and D. Let the inheritance structure is B and C inherit A and D inherits both B and C. Each class has a variable say A has a, B has b, C has c and D has d. How does the object creation happens for each class?
Citing Wikipedia at https://en.wikipedia.org/wiki/Multiple_inheritance at the Curl
bullet:
Curl allows only classes that are explicitly marked as shared to be
inherited repeatedly. Shared classes must define a secondary
constructor for each regular constructor in the class. The regular
constructor is called the first time the state for the shared class is
initialized through a subclass constructor, and the secondary
constructor will be invoked for all other subclasses.
From here, without knowing Curl and only with the quote above and this, where it is stated that
The object semantics of Curl are similar to those of Java and C++.
Given
A
/ \
B(A) C(A)
\ /
D(B,C)
I imagine (I don't know for sure) that the coder is responsible to disambiguate the problem by specifying the qualified name of the constructor to run, when invoking a parent constructor from the D(B,C) subclass.
It looks like A has to be declared shared, and when D is created, B runs a constructor that calls A (primary) constructor, C runs a constructor that calls A (secondary) constructor. The distinction between primary/secondary constructor call is automatic and transparent to the coder.
As two A constructors are invoked, two A objects are created in memory, that is the A class is shared with two different subclasses, but there is not a single "shared" A object, but two independent ones (see also virtual/nonvirtual inheritance that is somehow related (C++).)
For what I've read for several different languages, it is almost always the coder that disambiguates the diamond problem with qualification. Languages just define different or similar schemes of giving an error, or having a criteria to choose one of the multiple ambiguous definitions, like specific search order in the inheritance chain. Some other languages don't even allow multiple inheritance, but in some of these you are allowed to extend functionality by some ohter means (like interfaces).
From Programming Language Pragmatics, by Scott
A derived class D has all the members—data and subroutines—of its base
class C. As long as D does not hide any of the publicly visible
members of C, it makes sense to allow an object of class D to be used
in any context that expects an object of class C: anything we might
want to do to an object of class C we can also do to an object of
class D. In other words, a derived class that does not hide any
publicly visible members of its base class is a subtype of that base
class.
If D overrides a public method of C,
does the overriding method of D hide the overridden method of C, and
does the overriding disqualifies D from being a subtype of C?
What can make a derived class hide a public method of a base class?
Thanks.
does the overriding method of D hide the overridden method of C
No, overriding is different from hiding, because you are providing a replacement implementation instead of an existing one, not just taking away an implementation without any replacement.
Most object-oriented languages disallow hiding of methods that are designated for overriding (virtual of C++, abstract and virtual of C#). Some languages do not allow hiding at all (Java). This is done precisely to ensure that inheriting D from C models "is-a" relationship.
does the overriding disqualifies D from being a subtype of C?
No, it does not.
does the overriding disqualifies D from being a subtype of C?
It depends. If the method in D breaks the contract that the method in C defines, then yes it would disqualify D from being a subtype. If the D method supports the same contract then it doesn't.
I suggest you read up on the Liskov Substitution Principle. Here is the original article she wrote in 1994. It's quite readable.
http://www.csnell.net/computerscience/Liskov_subtypes.pdf
which one is not an object association a) simple association
b) inheritance
c) Aggregation
d) Association
First you need to know what an association is.
And association in O.O.P defines a relationship between classes of objects that allows one object instance to cause another to perform an action on its behalf (Wikipedia ,2016)
Read more about it here: https://en.wikipedia.org/wiki/Association_(object-oriented_programming)
This means that you can call objects from one class into another and allow it to "mutate" perform some logic/action on behalf of another object.
I think the answer to your question is c) Aggregation. This is because aggregation in used in Unified Modelling Language (UML). This is when one object is Strongly Composed of another. This means it is made-up of many objects. In this, the object isn't taking permission to call that object, it is composed of them which means that it can call them directly.
a) and d) contain the word "Association" already so that shouldn't be the answer.
b) Inheritance is when you extend a parent/super class into a subclass. This is when the superclass contains objects and methods which can be called by the subclass. The difference with the subclass is that it can have it's own unique parameters for the objects (which the superclass doesn't have).