I came across the expression 'subclasses of the containing class' when I read a paper. What does that containing class mean in Java? This is the excerpt from the paper.
Primarily, this entailed three things: (i) studying the implementation of the entity, as well as its usage, to reason about the intent behind the functionality; (ii) performing static dependency analysis on the entity, and any other types, methods, or fields referenced by it, including constants; and (iii) examining the inheritance hierarchy and subclasses of the containing class. This approach took considerable time and effort to apply.
This example has a subclass of the containing class:
class Parent {
class Child {
}
}
class ParentSubclass extends Parent {
void whatever() {
new Child(); // Creates an instance of Parent.Child
}
}
ParentSubclass is a subclass of the containing class of Child. Note that outside of Parent (or its subclasses), new Child() will not work, as you need to have a containing ("outer") class to instantiate a non-static "inner" class.
Things get a bit crazy when you now add a method doSomething to Parent, invoke it in Child but override it in ParentSubclass.
class Parent {
void doSomething() {
System.out.println("Not doing anything");
}
class Child {
void whatever() {
doSomething(); // actually: Parent.this.doSomething()
}
}
}
class ParentSubclass extends Parent {
void doSomething() {
System.out.println("I'm just slacking.");
}
void whatever() {
Child a = new Child(); // Creates an instance of Parent.Child
a.whatever(); // will print "I'm just slacking".
}
}
Situations like this make static code analysis a quite hard problem.
Since I have no access to the paper, this is my best guess: in Java, classes can be related to each other in more than one way: in addition to inheriting from one another, classes can also be nested inside one another.
Here is an example of a class inheriting from the class inside which it is nested:
public class Outer {
public void doSomething() {
// ...does something
}
private static class Inner extends Outer {
public void doSomething() {
// ...does something else
}
}
}
In the example above, Inner inherits from Outer, which serves as its containing class.
Related
I have lots of children to a base class and plan for adding a lot more. I'm lazy. The child creator sets up some basic things that is needed for the super constructor and vice versa. A simple solution from my problem would be the following:
parent {
public parent(){/*some code*/}
public void finalSetup(){/*code that dependent on the fact that the child constructor has run*/}
}
child{
public child(){/*some code;*/ super.finalSetup();}
}
How ever, calling super.finalSetup() on every child is quite the hassle, and if I forget it on one it'll break. That's no good. My question is simple: is there any way to set this up form the parent. As far as my google skills go I haven't been able to find one. Hopefully you guys know something I don't.
Thanks
Consider the Factory pattern to create generic type that extends Parent.
public class Parent {
public Parent(){/*some code*/}
public void finalSetup(){/*code that dependent on the fact that the child constructor has run*/}
public static <T extends Parent> T makeChild(Class <T> klass) {
T child = null;
try {
child = klass.newInstance();
child.finalSetup();
}
catch (InstantiationException| IllegalAccessException ex) {
// somthing went wrong
}
return child;
}
}
and call
Child child = Parent.makeChild(Child.class);
It is useful when:
+ a class can't anticipate the class of objects it must create
+ a class wants its subclasses to specify the fields or objects it creates
+ classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate
This should be what you want, but as already mentioned, it can be not the best idea. You don't need to explicitly call the parent constructor in your subclass if you have a no-argument constructor in your superclass.
abstract class Parent {
Parent() {
/*some code*/
childInit();
finalSetup();
}
void finalSetup() {/*code that dependent on the fact that the child constructor has run*/}
abstract void childInit();
}
class Child extends Parent {
#Override
void childInit() {
/* the code you would put in child's constructor */
}
}
This should do it. The basic idea is to override the before and after methods in your children and in the parent constructor you simply run both and do some initialization in between. Of course this does not save you from forgetting to call the parent constructor.
abstract class Parent {
Parent(){
doBefore();
// some stuff
doAfter();
}
abstract void doBefore();
abstract void doAfter();
}
class Child extends Parent {
Child(){
super();
}
void doBefore(){
// do before stuff
}
void doAfter(){
// do after stuff
}
}
With abstract methods in your parent you can implement any permutation of before / after procedures.
I want to know if it possible to use This() To reffer MotherClass, Calling My motherClass A and executing it from my Child Class B. witch one is correct ?
Class A { A(){ System.out.println("hello");}
Class B extends A { this() ; B(){System.out.println("World");}}
OR
class A {
Class B { this(); B(){System.out.println("World");} }
}
I want when to Call Class B it show Me (HelloWorld);
Sorry for my bad english.
Calling this() is meaningless unless you are calling it in a constructor and which means to call a constructor overload for this current class (if one exists). Please see this tutorial for the details on this. To call a super class's methods, again use the super keyword.
Incidentally, your code still doesn't compile. Please understand that you can't be careless when coding -- the compiler won't let you, and neither should you be when creating and posting code for questions here.
Create a file - parent.java
public class parent {
parent(){
System.out.println("Hello");
}
}
Create another file - child.java
public class child extends parent {
child(){
super();
System.out.println("World");
}
public static void main(String[] args) {
child c = new child();
}
}
==============================
Creating an instance of child class will first call the parent class constructor and then the child class constructor; resulting in the o/p you are looking for.
I was reading through online for the reason as to why multiple inheritance is not allowed in Java and the following example was given to illustrate it:
class A {
public void doSomething() {
}
}
class B {
public void doSomething() {
}
}
class C extends A,B {
}
public static void main(String args) {
C c = new C();
c.doSoemthing(); // compiler doesnt know which doSeomthing to call.
The above example illustrates what we call a diamond problem where by both parent classes have the same method name. when a child class tries to retrieve it, the compiler gets confused.
My question is, how will an interface solve this kind of problem ?
It's not fair to say that multiple inheritance achieved through interfaces in java
Java support only multiple interface inheritance, and java does not support multiple inheritance.
You should see In mixin inheritance, one class is specifically designed to be used as one of the classes in a multiple inheritance scheme.
http://csis.pace.edu/~bergin/patterns/multipleinheritance.html
Lets think about the following code
interface P {
public void doSomething();
}
interface Q {
public void doSomething();
}
class A {
public void doSomething() {
}
}
class B {
public void doSomething() {
}
}
class C implements P,Q {
public void doSomething(){
// implementation
}
}
class D extends A,B { // suppose it is possible
}
now to use object of C you have the implementation of doSomething() in C class. Which is only implemented in C class.
But if you could create an object of D and call doSomething which method should be called? as this method is implemented in both A and B.
Diamond Problem
actually the real diamon problem is
class A {
public void doSomething() {
}
}
class B extends A{
public void doSomething() {
}
}
class C extends A{
public void doSomething() {
}
}
class D extends B,C { // suppose it is possible
// no implementation of doSomething.
}
it is called diamond because of it's diamond shape. Here if you want to do following
D d = new D();
d.doSomething(); // which method should be called now????
From wikipedia here is a nice real time example
For example, in the context of GUI software development, a class
Button may inherit from both classes Rectangle (for appearance) and
Clickable (for functionality/input handling), and classes Rectangle
and Clickable both inherit from the Object class. Now if the equals
method is called for a Button object and there is no such method in
the Button class but there is an overridden equals method in both
Rectangle and Clickable, which method should be eventually called?
The interface does not implement the doSomething() method, so you cannot call an interface method. Interface is a mere signature what methods to implement in the actuall (implementing) class. You would implement the doSomething() in your class C and that would be the method you are calling when invoking B.doSomething() or A.doSomething().
In the case of extending two claasses with two doSomething() methods, they could be having different implementations and you would not know which one is invoked. See this example:
class A {
public void doSomething() {
System.out.println("A");
}
}
class B {
public void doSomething() {
System.out.println("B");
}
}
class C extends A & B { //if this would be an option
}
public static void main(String args) {
C c = new C();
c.doSoemthing(); //Print "A" or "B" ???
}
Conclusion: It's an implementation thing. Interfaces do not offer any implementation for any method, so it's safe to inherit from interfaces having the same method signatures.
Multiple inheritance can inherit member data from many classes as well as all their functions. Multiple interfaces can only inherit function prototypes and they must be implemented by the child class.
An interface has no implementation of the method, and thus they both will be merged into the same method.
In fact, your object promises to implement a method called doSomething, but not tied to specifically one of the interfaces (serves both)
Answer lies in your question itself. In case of interface compiler does not get confused as there is no implementation in your interface. Its your concrete class which will provide the actual implementation .Hence no confusion.
Both classes provide code that the JVM can jump to when the call is made. This is where the ambiguity lies. Same problem with attributes, the compiler might have two attributes with the same name to look into, which will give a similar ambiguity.
An interface will not provide that code. Hence there will be no conflict.
Other languages that support multiple inheritance makes the compiler prohibit these ambiguities when they arise. And resolving them needs to be made ad hoc. I.e.
class C{
public void doSomething(){
// Call (this inferred)
B.doSomething();
// leave A.doSomething() alone.
}
}
I have a parent class which has a method, in the child class I override that parent class's method. In a third class I make an object of child and by using that object I want call the method of parent class. Is it possible to call that parent class method ? If yes, then how?
If you override a parent method in its child, child objects will always use the overridden version. But; you can use the keyword super to call the parent method, inside the body of the child method.
public class PolyTest{
public static void main(String args[]){
new Child().foo();
}
}
class Parent{
public void foo(){
System.out.println("I'm the parent.");
}
}
class Child extends Parent{
#Override
public void foo(){
//super.foo();
System.out.println("I'm the child.");
}
}
This would print:
I'm the child.
Uncomment the commented line and it would print:
I'm the parent.
I'm the child.
You should look for the concept of Polymorphism.
Use the keyword super within the overridden method in the child class to use the parent class method. You can only use the keyword within the overridden method though. The example below will help.
public class Parent {
public int add(int m, int n){
return m+n;
}
}
public class Child extends Parent{
public int add(int m,int n,int o){
return super.add(super.add(m, n),0);
}
}
public class SimpleInheritanceTest {
public static void main(String[] a){
Child child = new Child();
child.add(10, 11);
}
}
The add method in the Child class calls super.add to reuse the addition logic.
First of all, it is a bad design, if you need something like that, it is good idea to refactor, e.g. by renaming the method.
Java allows calling of overriden method using the "super" keyword, but only one level up in the hierarchy, I am not sure, maybe Scala and some other JVM languages support it for any level.
Say the hierarchy is C->B->A with A being the base class.
I think there's more to fixing this than renaming a method. That will work but is that a fix?
One way is to refactor all the functionality common to B and C into D, and let B and C inherit from D: (B,C)->D->A Now the method in B that was hiding A's implementation from C is specific to B and stays there. This allows C to invoke the method in A without any hokery.
NOTE calling parent method via super will only work on parent class,
If your parent is interface, and wants to call the default methods then need to add interfaceName before super like IfscName.super.method();
interface Vehicle {
//Non abstract method
public default void printVehicleTypeName() { //default keyword can be used only in interface.
System.out.println("Vehicle");
}
}
class FordFigo extends FordImpl implements Vehicle, Ford {
#Override
public void printVehicleTypeName() {
System.out.println("Figo");
Vehicle.super.printVehicleTypeName();
}
}
Interface name is needed because same default methods can be available in multiple interface name that this class extends. So explicit call to a method is required.
This question already has answers here:
Closed 13 years ago.
Part of me thinks that this shouldn't be possible (even if it is), but I'll ask anyway.
Given the following class hierarchy (Grandparent and Parent are from a 3rd party and thus, not under my control), how would I override myMethod() in Child such that it bypasses the overridden implementation in Parent and invokes the one in Grandparent?
class Grandparent {
public void myMethod() {
// do stuff
}
}
class Parent extends Grandparent {
#Override public void myMethod() {
super.myMethod();
// do something else
}
}
class Child extends Parent {
#Override public void myMethod() {
// ??? I want to *only* do what Grandparent did here
}
}
Pretend that the Parent class provides a lot of other helpful behavior and is a crucial element of Child's hierarchy (in other words, I'm not looking for "make Child a subclass of Grandparent".
The idea behind inheritance is that each class defines their methods how they need, so you don't need to be inspecting any code.
It seems like you're subclassing here just to re-use code, and that's not the idea of subclassing.
Maybe you should have a helper member to do some of the tasks you need, instead of subclassing, and have both "Child" and "Parent" classes extend "Grandparent".
The main question you need to ask yourself is: "Is Child really a descendant of Parent, Grandparent or neiter?" In other words, for every instance of Child, can I say it's a Parent?
If the answer is no, then you're subclassing wrongly: inheritance is supposed to mean something, not just code re-use (i.e. Ford IS ALSO a Car, not just "Ford" uses "Car" methods).
Assuming that I couldn't touch the code in Parent or Grandparent and assuming that I'm not, as Seb suggested (and as Steve apparently agreed) simply misusing inheritance entirely:
I'd create a local instance of a Grandfather object (or a local class extending Grandfather, if it's abstract) and access its interpretation of myMethod() directly. Of course, depending on how much state information myMethod() is supposed to read and/or manipulate, the amount of work involved could be anything from "easy" to "excruciating".
It's an ugly solution, and, depending on how much state information is accessed, could be brittle as hell. But if Grandfather is reliably stable and/or myMethod() is fairly self-contained, it could work. The devil is in the details, as always.
I definitely agree with Seb that this is re-use, not inheritance. But, hey. Re-use is often a Good Thing.
Not possible.
I would create a final helper method in grandparent instead. And have this method (which is overridden) call that helper.
class Grandparent {
public final void myHelperMethod() {
// do stuff
}
public void myMethod() {
myHelperMethod();
}
}
class Parent extends Grandparent {
#Override public void myMethod() {
super.myMethod();
// do something else
}
}
class Child extends Parent {
#Override public void myMethod() {
// ??? I want to *only* do what Grandparent did here
myHelperMethod();
}
}
Do you have control of the Parent class?
If so, could you add a method (myNewMethod) to the Parent that calls myMethod on Grandparent, and call myNewMethod from Child?
(I'm not a Java person, so don't know if you can only call a method in a superclass from an override of that method in a subclass)
class Grandparent {
public void myMethod() {
myHelperMethod();
}
}
class Parent extends Grandparent {
#Override public void myMethod() {
super.myMethod();
// do something else
}
public final void myNewMethod() {
super.myMethod();
}
}
class Child extends Parent {
#Override public void myMethod() {
// ??? I want to *only* do what Grandparent did here
myNewMethod();
}
}