What do we mean when we say "All classes either directly or indirectly inherit from class Object"? What constitutes a class indirectly inheriting the methods declared in its indirect superclass?
Can we say that a class indirectly inherits methods declared in one of it's indirect superclasses, regardless of the fact that the method defined in the superclass may have been overridden whilst propagating down the inheritance hierarchy, thus comments such as the above are based on the fact that the subclass inherits some method with the same signature as that declared in the superclass.
Alternately, can we only ever say that a class indirectly inherits the methods declared in one of it's indirect superclass if and only if the class is inheriting THE method declared in it's indirect superclass, that is the method has not been overridden whilst propagating down the inheritance hierarchy, and the class is inheriting the method with the same implementation as that defined in it's indirect superclass.
By indirectly inheriting, they mean that you extend another class that in itself extends Object. Directly inheriting from Object would mean that you either explicitly stated extends Object on your class signature, or you didn't define another class it should extend (in which case it extends Object directly anyway by definition.)
In terms of specific methods, you only inherit the one that was "last overriden" in the hierarchy. So if I'm inheriting from a class that inherits toString(), I'll only inherit the overriden version, not the original from Object.
Class1 indirectly inherits Class2 when you use "is-a" more than once to describe their relationship (remember that "is-a" relationship is transitive).
Example: a red-apple is-a apple is-a fruit is-a consumable. In this example, red-apple indirectly inherits from fruit and consumable. red-apple directly inherits from apple (only one is-a transition used)
The question about indirect inheritance of class was already answered. So I add on methods.
I think what is important here is the difference between class interface (signatures of available methods, not java mechanism of interfaces) and class behavior - the implementations of available methods. In your question about methods you can say that class indirectly inherits methods regardless of whether they were overridden by intermediate classes, and without any other details it means inheriting interface. To set the context of phrase to behavior meaning you must explicitly state that implementation of method X is taken from class Y.
Related
In Java inheritance, can the expression "overriding an abstract method" be used interchangeably with the expression "implementing an abstract method"?
I came across the following question in the book "OCA Java SE 8 Programmer I Study Guide" in Chapter 5, page 296, question #15:
Q: Which of the following is true about a concrete subclass? (Choose all that apply)
A. A concrete subclass can be declared as abstract.
B. A concrete subclass must implement all inherited abstract methods.
C. A concrete subclass must implement all methods defined in an inherited interface.
D. A concrete subclass cannot be marked as final.
E. Abstract methods cannot be overridden by a concrete subclass.
My answer was B & E. But the book says, the correct answer is only B.
My question is specifically about the option E. The book says, option E is incorrect because abstract methods must be overridden by a concrete subclass. My initial thought was abstract methods must be implemented before being overridden by a subclass. So why is option be incorrect?
Let me explain each points one at a time.
A. A concrete subclass can be declared as abstract.
Ans: Incorrect.
By the definition, concrete classes are those which can be instantiated and this class can also extends the base abstract class.
B. A concrete subclass must implement all inherited abstract methods.
Ans: Correct
If the methods are marked as abstracts in the base class, then the child class extending base class should make sure that all the abstract methods are implemented. You will otherwise get a compile time error.
C. A concrete subclass must implement all methods defined in an inherited interface.
Ans: Incorrect
this is only the case when the concrete subclass has directly implemented the interface by this class itself.
But in this case, base class may have implemented an inherited interface .Hence, its not mandatory for concrete sub-class to implement all methods that are there in base class as a result of inheritance from the interface.
D. A concrete subclass cannot be marked as final.
Ans: Incorrect
If a subclass is marked as final, then this class can no longer be extended by any other available sub-classes. Marking a class with a final keyword is particularly used to achieve Immutability.
With Immutable classes, We can call accessor methods (e.g. getter methods), copy the objects, or pass the objects around — but no method should allow modifying the state of the object. Examples: String, wrapper classes like Float, Integer.etc.
E. Abstract methods cannot be overridden by a concrete subclass.
Ans: Incorrect
By the definition, Abstract methods are methods that are only declared but contains no body or implementation.And since we cannot instantiate abstract class, it is up-to sub classes to provide the implementations for these defined abstract methods.Hence abstract methods are not optional but mandatorily be overridden by a inheriting subclass.
An abstract method is a method that is declared, but contains no implementation.
you can override both abstract and normal methods inside an abstract class.
only methods declared as final cannot be overridden.
We know that by default, every class inherits ultimately from the java.lang.Object class, which is why methods such as toString are readily available to every class. Therefore, a generic class is effectively as follows:
public class Foo extends java.lang.Object {
public Foo() {super(); }
}
However, is it at all possible to create a class which does NOT automatically inherit from the Object class, and thus, has no superclass? And if so, what would be the effect?
We can't write class without having java.lang.object as superclass. Compiler will automatically extend the object class.Only the object class itself and interfaces are the ones which do not extend object class.
No, that is not possible. From the documentation:
Class Object is the root of the class hierarchy. Every class has
Object as a superclass. All objects, including arrays, implement the
methods of this class.
I do not believe that you can have a class that does not inherit Object. Quoting from Object as a Superclass..
The Object class, in the java.lang package, sits at the top of the
class hierarchy tree. Every class is a descendant, direct or indirect,
of the Object class. Every class you use or write inherits the
instance methods of Object. You need not use any of these methods,
but, if you choose to do so, you may need to override them with code
that is specific to your class.
In cases where the inheritance is not explicitly stated, it is implicitly stated. Now, inheritance will obviously not form a cycle. The Object class is the only one which inherits from nobody, it's the top of hierarchy.
Are there any classes that don't inherit Object as SuperClass or maybe have become Obsolete/deprecated?
According to Java Object superclass, java.lang.Object does not extend Object.
Other than that, all classes, i.e.
class ClassName {
//some stuff
}
implicitly extend Object class, if they don't extend any other super-class.
Interfaces, on the other hand, do not extend Object, as Interface, by definition, can not extend Class.
Also, Interfaces can not contain callable methods, nor can objects be instantiated from them. When interfaces are finally implemented, the implementing class will necessarily extend Object (and, no, Object doesn't implement or extend any other entity/class/interface).
According to java.lang.Object javadoc
Class Object is the root of the class hierarchy. Every class has
Object as a superclass. All objects, including arrays, implement the
methods of this class.
So, all objects in Java extends it directly or indirectly.
All Java classes inherit java.lang.Object (directly - by default, or via parents). If some class or method become deprecated with some platform release, it is always reflected in appropriate JavaDoc.
Are there any classes that don't inherit Object as SuperClass
There is exactly one of those, and it is java.lang.Object itself. Also all interfaces.
or maybe have become Obsolete/deprecated?
There are plenty of those. See the Javadoc.
Is java.lang.Object superclass of all the custom class/objects inherited implicitly? I thought java didn't support multiple inheritance. The reason I ask is if I already inherit from another class in my custom class and again java is forcing implicit inheritance of java.lang.Object on top of it, is it not multiple inheritance?
Also, is java.lang.class Class also the superclass for all custom classes/Objects? If not, how in java reflections we can get the type of class for any class passed or call isInstance on any object?
Every class without an explicit superclass inherits from java.lang.Object and every other class inherits from it indirectly because when you go up the inheritance tree, you will finally end at a class without an explicit superclass and then at Object.
java.lang.Class is the superclass of all class objects (not of all objects!), for example of String.class.
Is java.lang.Object superclass of all
the custom class/objects inherited
implicitly?
Minor correction: regarding the following expression:
superclass of all the custom
class/objects
A class A is a superclass of another class B. Objects or instances of B do not have A as their superclass (since they are objects/object instances, not classes themselves.) The most appropriate description is that these objects are instances of class B, which has A as its superclass.
Now, to your question on java.lang.Object. It is the superclass of everything that can be instantiated by the java runtime. That includes both:
classes you write (custom classes), as well as
classes provided by the Java language itself.
I thought java didn't support multiple
inheritance.
It doesn't. It only support single class (or implementation) inheritance (in conjunction with multiple interface (or type) inheritance.
You are confusing inheritance with class hierarchy. Pls see further below.
The reason I ask is if I already
inherit from another class in my
custom class and again java is forcing
implicit inheritance of
java.lang.Object on top of it,
And that's fine with multiple inheritance. Say you have a class B that you wrote inheriting from a class already provided by Java (say class A). So there is a linear, transitive relation as follows:
java.lang.Object > A > B
Where > stands for immediate parent of. Any class inheriting from Object can only have one and only one immediate parent. At no point you'll have a class C for which the following constrain for any two classes A and B does not hold:
forAll A, B { A > B -> forAll C { C >
B <-> C == A } }
Meaning, for all classes A and B such that A is an immediate parent of B, then for all classes C, C can only be an immediate parent of B *if and only if C is itself A.
With single inheritance you can have (theoretically) an infinite inheritance chain A > B > C > ... so long as every class in the chain is preceeded by one and only one immediate parent. As a useful analogy, this resemble the predecessor relationship in natural numbers (0 preceedes 1 preceedes 2 which preceedes 3 ...).
Disclaimer: This is not stuff that you use in day-to-day programming life activities. However, knowing precisely what these things mean under the hood will tremendously help you get through object orientation.
is it not multiple inheritance?
No (see above.) As opposed to single inheritance - explained above - in multiple inheritance you can have multiple immediate parents (as seen in C++).
As we noticed in the definitions above, the transitive inheritance relation '>' is from one class to another. But with multiple inheritance, the relation is from a set of superclasses {A} to a single class {B}:
{A} > B -> forAll a {a in A <-> a > B}
And in C++ where you can have classes without parents, then the set {A} can be the null set. In java, you also have multiple inheritance, but limited to interfaces (or types.)
Also, is java.lang.class Class also
the superclass for all custom
classes/Objects?
No. It will help your learning if you take a visit to the Javadoc manuals which are available online. Look it up. Really.
If not, how in java reflections we can
get the type of class for any class
passed or call isInstance on any
object?
Because instances of java.lang.Class (and all classes used by java reflections) are meta-data descriptors for other classes. This has nothing to do with inheritance. What you are referring to here is known as meta-programming.
Furthermore, java.lang.Class is a final class; ergo, it cannot be the superclass of anything.
The function of java.lang.Class is to be a meta-data provider/descriptor for all instances and subclasses of java.lang.Object (including java.lang.Class itself.) The class field associated to each class (.ie. String.class) is a static, class-level field describing the meta-data associated to that class.
The meta-data contained/described by java.lang.Class contains meta-data accessor objects for methods, constructors and fields. Again, this has nothing to do with inheritance.
Inheritance =/= meta-programming.
Hope it helps.
Everything is an Object, that said you could see the structure as this:
Object
Animal
Cat
and not as this:
Object Animal
Cat
Where Cat extends both, it's not like this last example, but it's Cat that extends Animal which extends Object.
Multiple inheritance means that one class has multiple direct predecessors. If A inherits from B, and B inherits from C, this is not multiple inheritance.
I don't understand the second question ("java.lang.class Class"); you might want to rephrase that to clarify.
Object is the superclass of every other class. When your Child class inherits from your Parent class, it is not the child of Object, but it is still a descendant, because its parent is a descendant of Object.
So if you don't specify a superclass/parent, it will automatically be Object. If you do specify a parent, then Object will still be a superclass, because it is by definition a superclass of the parent class.
Class is not a superclass of each class, but the Object class specifies a means to get each class's Class with the getClass method.
The custom class that you inherit from itself inherits directly or implicitly from Object, so you indirectly inherit from Object. The chain goes YourObject -> MiddleObject -> java.lang.Object. No multiple inheritance necessary.
Multiple inheritance is when you directly inherit from two unrelated classes. For example, if you have a class PoliceDog that inherits directly from both Canine and PoliceOfficer, that would be multiple inheritence.
In that case, it's not multiple inheritence but multi-level
inheritance.
For example, let's say you have a class say, Class Animal,
this class will be extending Object class, by default and extends no
other class.
Also let's assume, you have a class which extends the
Class Animal, say Class Lion. In this case, the Class Lion will not be
directly inheriting the Object Class but since it inherits Class
Animal which inherits Object class, it also indirectly inherits
it.
If class A extends class B and class B has already implemented the Cloneable interface, then is it necessary for class A to declare 'clone() throws CloneNotSupportedException'?
I guess it should not be mandatory, as the property to clone objects of class A would automatically be inherited from class B.
It is necessary to override clone() if class B defines non-primitve mutable member fields. These need to be deep copied explicitly within B.clone(). If B only contains primitive and/or immutable data members, A.clone() will do the job.
For a more detailed explanation, see this earlier answer of mine to a similar question.
If the parent class, and all ancestors, implements its Clone method by calling its parent class' Clone method, all the way up to Object.clone, and if none of the fields added by the subclass hold references to things which should be changeable on one object without affecting the other, then one can simply inherit clone without overriding it. If the parent class implements the clone method as described above but the subclass adds fields that themselves need to be cloned, the best pattern is for the subclass to call base.Clone and then clone the appropriate fields.
If the parent class or any ancestor does not implement its Clone method as described above but instead uses a copy constructor, then the derived class, and all base classes derived from it) must override Clone to do likewise, regardless of whether the base class adds any new fields.
Unfortunately, I know of no nice way to ascertain which category a parent class belongs to. If a parent class supports Clone by calling base.Clone, it would be unfortunate for a derived class to needlessly break the chain by implementing a copy constructor. On the other hand, if the parent class implements Clone as a copy constructor, a base class which does not do so will have broken semantics.