Tại sao super.super.method (); không được phép trong Java?

Tôi đọc câu hỏi này và nghĩ rằng nó sẽ dễ dàng được giải quyết (không phải là nó không thể giải quyết được nếu không có) nếu người ta có thể viết:

@Override
public String toString() {
    return super.super.toString();
}

Tôi không chắc nó có hữu ích trong nhiều trường hợp không, nhưng tôi tự hỏi tại sao nó không và nếu một cái gì đó như thế này tồn tại trong các ngôn ngữ khác.

các bạn nghĩ sao?

EDIT: Để làm rõ: vâng tôi biết, điều đó là không thể trong Java và tôi không thực sự bỏ lỡ nó. Điều này không có gì tôi mong đợi để làm việc và đã ngạc nhiên khi gặp lỗi trình biên dịch. Tôi chỉ có ý tưởng và muốn thảo luận về nó.

Nó vi phạm đóng gói. Bạn không thể bỏ qua hành vi của lớp cha. Nó làm cho tinh thần để thỉnh thoảng có thể bỏ qua của bạn riêng hành vi lớp học của (đặc biệt là từ bên trong cùng một phương pháp) nhưng không phải cha mẹ của bạn của. Ví dụ: giả sử chúng ta có một "bộ sưu tập vật phẩm" cơ bản, một lớp con đại diện cho "một bộ sưu tập các vật phẩm màu đỏ" và một lớp con đại diện cho "một bộ sưu tập các vật phẩm lớn màu đỏ". Nó có ý nghĩa để có:

public class Items
{
    public void add(Item item) { ... }
}

public class RedItems extends Items
{
    @Override
    public void add(Item item)
    {
        if (!item.isRed())
        {
            throw new NotRedItemException();
        }
        super.add(item);
    }
}

public class BigRedItems extends RedItems
{
    @Override
    public void add(Item item)
    {
        if (!item.isBig())
        {
            throw new NotBigItemException();
        }
        super.add(item);
    }
}

Điều đó tốt - RedItems luôn có thể tự tin rằng các vật phẩm chứa trong đó đều có màu đỏ. Bây giờ giả sử chúng ta đã có thể gọi super.super.add ():

public class NaughtyItems extends RedItems
{
    @Override
    public void add(Item item)
    {
        // I don't care if it's red or not. Take that, RedItems!
        super.super.add(item);
    }
}

Bây giờ chúng tôi có thể thêm bất cứ điều gì chúng tôi thích, và bất biến trong đó RedItemsbị phá vỡ.

Điều đó có ý nghĩa?

Tôi nghĩ Jon Skeet có câu trả lời đúng. Tôi chỉ muốn thêm rằng bạn có thể truy cập các biến bị bóng từ các siêu lớp của siêu lớp bằng cách truyền this:

interface I { int x = 0; }
class T1 implements I { int x = 1; }
class T2 extends T1 { int x = 2; }
class T3 extends T2 {
        int x = 3;
        void test() {
                System.out.println("x=\t\t"          + x);
                System.out.println("super.x=\t\t"    + super.x);
                System.out.println("((T2)this).x=\t" + ((T2)this).x);
                System.out.println("((T1)this).x=\t" + ((T1)this).x);
                System.out.println("((I)this).x=\t"  + ((I)this).x);
        }
}

class Test {
        public static void main(String[] args) {
                new T3().test();
        }
}

tạo ra đầu ra:

x = 3
siêu.x = 2
((T2) này) .x = 2
((T1) này) .x = 1
((Tôi) này) .x = 0

(ví dụ từ JLS )

Tuy nhiên, điều này không hoạt động đối với các cuộc gọi phương thức vì các cuộc gọi phương thức được xác định dựa trên loại thời gian chạy của đối tượng.

Tôi nghĩ rằng đoạn mã sau cho phép sử dụng super.super ... super.method () trong hầu hết các trường hợp. (ngay cả khi nó cố gắng làm điều đó)

Nói ngắn gọn

1. tạo ví dụ tạm thời của kiểu tổ tiên
2. sao chép giá trị của các trường từ đối tượng ban đầu sang tạm thời
3. gọi phương thức đích trên đối tượng tạm thời
4. sao chép các giá trị đã sửa đổi trở lại đối tượng ban đầu

Sử dụng :

public class A {
   public void doThat() { ... }
}

public class B extends A {
   public void doThat() { /* don't call super.doThat() */ }
}

public class C extends B {
   public void doThat() {
      Magic.exec(A.class, this, "doThat");
   }
}


public class Magic {
    public static <Type, ChieldType extends Type> void exec(Class<Type> oneSuperType, ChieldType instance,
            String methodOfParentToExec) {
        try {
            Type type = oneSuperType.newInstance();
            shareVars(oneSuperType, instance, type);
            oneSuperType.getMethod(methodOfParentToExec).invoke(type);
            shareVars(oneSuperType, type, instance);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
    private static <Type, SourceType extends Type, TargetType extends Type> void shareVars(Class<Type> clazz,
            SourceType source, TargetType target) throws IllegalArgumentException, IllegalAccessException {
        Class<?> loop = clazz;
        do {
            for (Field f : loop.getDeclaredFields()) {
                if (!f.isAccessible()) {
                    f.setAccessible(true);
                }
                f.set(target, f.get(source));
            }
            loop = loop.getSuperclass();
        } while (loop != Object.class);
    }
}

Tôi không có đủ danh tiếng để bình luận vì vậy tôi sẽ thêm câu này vào các câu trả lời khác.

Jon Skeet trả lời xuất sắc, với một ví dụ đẹp. Matt B có một điểm: không phải tất cả các siêu xe đều có supers. Mã của bạn sẽ bị hỏng nếu bạn gọi là siêu của một siêu không có siêu.

Lập trình hướng đối tượng (mà Java là) là tất cả về các đối tượng, không phải các hàm. Nếu bạn muốn lập trình theo định hướng nhiệm vụ, chọn C ++ hoặc một cái gì đó khác. Nếu đối tượng của bạn không phù hợp với siêu hạng của nó, thì bạn cần thêm nó vào "lớp ông bà", tạo một lớp mới hoặc tìm một siêu khác mà nó phù hợp.

Cá nhân tôi đã thấy giới hạn này là một trong những thế mạnh lớn nhất của Java. Mã có phần cứng nhắc so với các ngôn ngữ khác mà tôi đã sử dụng, nhưng tôi luôn biết những gì mong đợi. Điều này giúp với mục tiêu "đơn giản và quen thuộc" của Java. Trong suy nghĩ của tôi, gọi super.super không đơn giản hay quen thuộc. Có lẽ các nhà phát triển cảm thấy như vậy?

Có một số lý do tốt để làm điều này. Bạn có thể có một lớp con có một phương thức được triển khai không chính xác, nhưng phương thức cha được thực hiện đúng. Vì nó thuộc về thư viện của bên thứ ba, bạn có thể không thể / không muốn thay đổi nguồn. Trong trường hợp này, bạn muốn tạo một lớp con nhưng ghi đè một phương thức để gọi phương thức super.super.

Như được hiển thị bởi một số áp phích khác, có thể thực hiện điều này thông qua sự phản chiếu, nhưng nó có thể làm một cái gì đó như

(SuperSuperClass this) .theMethod ();

Tôi đang xử lý vấn đề này ngay bây giờ - cách khắc phục nhanh là sao chép và dán phương thức siêu lớp vào phương thức lớp con :)

Ngoài những điểm rất tốt mà những người khác đã đưa ra, tôi nghĩ còn có một lý do khác: nếu siêu lớp không có siêu lớp thì sao?

Vì mỗi lớp tự nhiên mở rộng (ít nhất) Object, super.whatever()sẽ luôn luôn đề cập đến một phương thức trong siêu lớp. Nhưng nếu lớp học của bạn chỉ kéo dài Object- những gì sẽsuper.super sau đó đề cập đến điều gì? Hành vi đó nên được xử lý như thế nào - lỗi trình biên dịch, NullPulum, v.v?

Tôi nghĩ lý do chính tại sao điều này không được phép là vì nó vi phạm đóng gói, nhưng đây cũng có thể là một lý do nhỏ.

Tôi nghĩ rằng nếu bạn ghi đè lên một phương thức và muốn tất cả các phiên bản siêu hạng của nó (như, nói cho equals ), thì bạn hầu như luôn muốn gọi phiên bản siêu lớp trực tiếp, trước tiên người ta sẽ gọi phiên bản siêu lớp của nó. .

Tôi nghĩ rằng nó chỉ hiếm khi có ý nghĩa (nếu có. Tôi không thể nghĩ ra trường hợp nào) để gọi một phiên bản siêu lớp tùy ý của một phương thức. Tôi không biết nếu điều đó là có thể trong Java. Nó có thể được thực hiện trong C ++:

this->ReallyTheBase::foo();

Theo phỏng đoán, bởi vì nó không được sử dụng thường xuyên. Lý do duy nhất tôi có thể thấy khi sử dụng nó là nếu cha mẹ trực tiếp của bạn đã ghi đè một số chức năng và bạn đang cố gắng khôi phục nó trở lại ban đầu.

Tôi dường như chống lại các nguyên tắc OO, vì phụ huynh trực tiếp của lớp nên có liên quan chặt chẽ hơn với lớp của bạn hơn là ông bà.

Nhìn vào dự án Github này , đặc biệt là biến objectHandle. Dự án này cho thấy làm thế nào để thực sự và gọi chính xác phương pháp ông bà trên một đứa cháu.

Chỉ trong trường hợp liên kết bị hỏng, đây là mã:

import lombok.val;
import org.junit.Assert;
import org.junit.Test;

import java.lang.invoke.*;

/*
Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.
Please don't actually do this... :P
*/
public class ImplLookupTest {
    private MethodHandles.Lookup getImplLookup() throws NoSuchFieldException, IllegalAccessException {
        val field = MethodHandles.Lookup.class.getDeclaredField("IMPL_LOOKUP");
        field.setAccessible(true);
        return (MethodHandles.Lookup) field.get(null);
    }

    @Test
    public void test() throws Throwable {
        val lookup = getImplLookup();
        val baseHandle = lookup.findSpecial(Base.class, "toString",
            MethodType.methodType(String.class),
            Sub.class);
        val objectHandle = lookup.findSpecial(Object.class, "toString",
            MethodType.methodType(String.class),
            // Must use Base.class here for this reference to call Object's toString
            Base.class);
        val sub = new Sub();
        Assert.assertEquals("Sub", sub.toString());
        Assert.assertEquals("Base", baseHandle.invoke(sub));
        Assert.assertEquals(toString(sub), objectHandle.invoke(sub));
    }

    private static String toString(Object o) {
        return o.getClass().getName() + "@" + Integer.toHexString(o.hashCode());
    }

    public class Sub extends Base {
        @Override
        public String toString() {
            return "Sub";
        }
    }

    public class Base {
        @Override
        public String toString() {
            return "Base";
        }
    }
}

Chúc mừng mã hóa !!!!

Tôi sẽ đặt thân phương thức super.super vào một phương thức khác, nếu có thể

class SuperSuperClass {
    public String toString() {
        return DescribeMe();
    }

    protected String DescribeMe() {
        return "I am super super";
    }
}

class SuperClass extends SuperSuperClass {
    public String toString() {
        return "I am super";
    }
}

class ChildClass extends SuperClass {
    public String toString() {
        return DescribeMe();
    }
}

Hoặc nếu bạn không thể thay đổi siêu siêu hạng, bạn có thể thử điều này:

class SuperSuperClass {
    public String toString() {
        return "I am super super";
    }
}

class SuperClass extends SuperSuperClass {
    public String toString() {
        return DescribeMe(super.toString());
    }

    protected String DescribeMe(string fromSuper) {
        return "I am super";
    }
}

class ChildClass extends SuperClass {
    protected String DescribeMe(string fromSuper) {
        return fromSuper;
    }
}

Trong cả hai trường hợp,

new ChildClass().toString();

kết quả cho "Tôi siêu siêu"

Ít nhất có vẻ như có thể có được lớp siêu lớp của siêu lớp, mặc dù không nhất thiết phải là trường hợp của nó, sử dụng sự phản chiếu; nếu điều này có thể hữu ích, vui lòng xem xét Javadoc tại http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#getSuperclass ()

public class A {

     @Override
     public String toString() {
          return "A";
     }

}


public class B extends A {

     @Override
     public String toString() {
          return "B";
     }

}

public class C extends B {

     @Override
     public String toString() {
          return "C";
     }

}


public class D extends C {

     @Override
     public String toString() {
          String result = "";
          try {
                result = this.getClass().getSuperclass().getSuperclass().getSuperclass().newInstance().toString();
          } catch (InstantiationException ex) {
                Logger.getLogger(D.class.getName()).log(Level.SEVERE, null, ex);
          } catch (IllegalAccessException ex) {
                Logger.getLogger(D.class.getName()).log(Level.SEVERE, null, ex);
          }
          return result;
     }

}

public class Main {

     public static void main(String... args) {
          D d = new D();
          System.out.println(d);

     }
}

chạy: THÀNH CÔNG BUILD (tổng thời gian: 0 giây)

Việc gọi super.super.method () có ý nghĩa khi bạn không thể thay đổi mã của lớp cơ sở. Điều này thường xảy ra khi bạn đang mở rộng một thư viện hiện có.

Hãy tự hỏi mình trước, tại sao bạn lại mở rộng lớp học đó? Nếu câu trả lời là "vì tôi không thể thay đổi nó" thì bạn có thể tạo gói và lớp chính xác trong ứng dụng của mình và viết lại phương thức nghịch ngợm hoặc tạo đại biểu:

package com.company.application;

public class OneYouWantExtend extends OneThatContainsDesiredMethod {

    // one way is to rewrite method() to call super.method() only or 
    // to doStuff() and then call super.method()

    public void method() {
        if (isDoStuff()) {
            // do stuff
        }
        super.method();
    }

    protected abstract boolean isDoStuff();


    // second way is to define methodDelegate() that will call hidden super.method()

    public void methodDelegate() {
        super.method();
    }
    ...
}

public class OneThatContainsDesiredMethod {

    public void method() {...}
    ...
}

Chẳng hạn, bạn có thể tạo lớp org.springframework.test.context.junit4.SpringJUnit4ClassRunner trong ứng dụng của mình để lớp này được tải trước lớp thực từ jar. Sau đó viết lại phương thức hoặc constructor.

Chú ý: Đây là bản hack tuyệt đối và không nên sử dụng nhưng nó HOẠT ĐỘNG! Sử dụng phương pháp này là nguy hiểm vì các vấn đề có thể xảy ra với trình nạp lớp. Ngoài ra, điều này có thể gây ra sự cố mỗi lần bạn sẽ cập nhật thư viện chứa lớp bị ghi đè.

Tôi đã có những tình huống như thế này khi kiến ​​trúc xây dựng chức năng chung trong CustomBaseClass chung, thực hiện thay mặt cho một số lớp dẫn xuất. Tuy nhiên, chúng ta cần phá vỡ logic chung cho phương thức cụ thể cho một lớp dẫn xuất cụ thể. Trong những trường hợp như vậy, chúng ta phải sử dụng triển khai super.super.methodX.

Chúng tôi đạt được điều này bằng cách giới thiệu một thành viên boolean trong CustomBaseClass, có thể được sử dụng để trì hoãn có chọn lọc việc thực hiện tùy chỉnh và mang lại triển khai khung mặc định khi muốn.

        ...
        FrameworkBaseClass (....) extends...
        {
           methodA(...){...}
           methodB(...){...}
        ...
           methodX(...)
        ...
           methodN(...){...}

        }
        /* CustomBaseClass overrides default framework functionality for benefit of several derived classes.*/
        CustomBaseClass(...) extends FrameworkBaseClass 
        {
        private boolean skipMethodX=false; 
        /* implement accessors isSkipMethodX() and setSkipMethodX(boolean)*/

           methodA(...){...}
           methodB(...){...}
        ...
           methodN(...){...}

           methodX(...){
                  if (isSkipMethodX()) {
                       setSKipMethodX(false);
                       super.methodX(...);
                       return;
                       }
                   ... //common method logic
            }
        }

        DerivedClass1(...) extends CustomBaseClass
        DerivedClass2(...) extends CustomBaseClass 
        ...
        DerivedClassN(...) extends CustomBaseClass...

        DerivedClassX(...) extends CustomBaseClass...
        {
           methodX(...){
                  super.setSKipMethodX(true);
                  super.methodX(...);
                       }
        }

Tuy nhiên, với các nguyên tắc kiến ​​trúc tốt được tuân theo trong khung cũng như ứng dụng, chúng ta có thể tránh được các tình huống như vậy một cách dễ dàng, bằng cách sử dụng phương pháp hasA, thay vì phương pháp isA. Nhưng tại mọi thời điểm, nó không thực tế để mong đợi kiến ​​trúc được thiết kế tốt, và do đó cần phải thoát khỏi các nguyên tắc thiết kế vững chắc và giới thiệu các bản hack như thế này. Chỉ 2 xu của tôi ...

@Jon Skeet Giải thích hay. IMO nếu ai đó muốn gọi phương thức super.super thì người ta phải muốn bỏ qua hành vi của cha mẹ ngay lập tức, nhưng muốn truy cập vào hành vi cha mẹ lớn. Điều này có thể đạt được thông qua ví dụ. Như mã dưới đây

public class A {
    protected void printClass() {
        System.out.println("In A Class");
    }
}

public class B extends A {

    @Override
    protected void printClass() {
        if (!(this instanceof C)) {
            System.out.println("In B Class");
        }
        super.printClass();
    }
}

public class C extends B {
    @Override
    protected void printClass() {
        System.out.println("In C Class");
        super.printClass();
    }
}

Đây là lớp tài xế,

public class Driver {
    public static void main(String[] args) {
        C c = new C();
        c.printClass();
    }
}

Đầu ra của điều này sẽ là

In C Class
In A Class

Hành vi printClass lớp B sẽ bị bỏ qua trong trường hợp này. Tôi không chắc chắn về việc đây là một thực hành lý tưởng hay tốt để đạt được super.super, nhưng nó vẫn hoạt động.

Nếu bạn nghĩ rằng bạn sẽ cần siêu lớp, bạn có thể tham chiếu nó trong một biến cho lớp đó. Ví dụ:

public class Foo
{
  public int getNumber()
  {
    return 0;
  }
}

public class SuperFoo extends Foo
{
  public static Foo superClass = new Foo();
  public int getNumber()
  {
    return 1;
  }
}

public class UltraFoo extends Foo
{
  public static void main(String[] args)
  {
    System.out.println(new UltraFoo.getNumber());
    System.out.println(new SuperFoo().getNumber());
    System.out.println(new SuperFoo().superClass.getNumber());
  }
  public int getNumber()
  {
    return 2;
  }
}

Nên in ra:

2
1
0

IMO, đó là một cách rõ ràng để đạt được super.super.sayYourName()hành vi trong Java.

public class GrandMa {  
    public void sayYourName(){  
        System.out.println("Grandma Fedora");  
    }  
}  

public class Mama extends GrandMa {  
    public void sayYourName(boolean lie){  
        if(lie){   
            super.sayYourName();  
        }else {  
            System.out.println("Mama Stephanida");  
        }  
    }  
}  

public class Daughter extends Mama {  
    public void sayYourName(boolean lie){  
        if(lie){   
            super.sayYourName(lie);  
        }else {  
            System.out.println("Little girl Masha");  
        }  
    }  
}  

public class TestDaughter {
    public static void main(String[] args){
        Daughter d = new Daughter();

        System.out.print("Request to lie: d.sayYourName(true) returns ");
        d.sayYourName(true);
        System.out.print("Request not to lie: d.sayYourName(false) returns ");
        d.sayYourName(false);
    }
}

Đầu ra:

Request to lie: d.sayYourName(true) returns Grandma Fedora
Request not to lie: d.sayYourName(false) returns Little girl Masha

Tôi nghĩ rằng đây là một vấn đề phá vỡ thỏa thuận thừa kế.
Bằng cách mở rộng một lớp bạn tuân theo / đồng ý hành vi của nó, các tính năng
Trong khi gọi super.super.method(), bạn muốn phá vỡ thỏa thuận vâng lời của chính mình.

Bạn không thể chọn anh đào từ siêu hạng .

Tuy nhiên, có thể xảy ra tình huống khi bạn cảm thấy cần phải gọi super.super.method()- thường là một dấu hiệu thiết kế xấu, trong mã của bạn hoặc trong mã bạn thừa kế!
Nếu siêu và siêu siêu lớp không thể được refactored (một số mã di sản), sau đó lựa chọn cho các thành phần trên thừa kế.

Phá vỡ đóng gói là khi bạn @Override một số phương thức bằng cách phá mã được đóng gói. Các phương thức được thiết kế để không bị ghi đè được đánh dấu cuối cùng .

Trong C #, bạn có thể gọi một phương thức của bất kỳ tổ tiên nào như thế này:

public class A
    internal virtual void foo()
...
public class B : A
    public new void foo()
...
public class C : B
    public new void foo() {
       (this as A).foo();
    }

Ngoài ra, bạn có thể làm điều này trong Delphi:

type
   A=class
      procedure foo;
      ...
   B=class(A)
     procedure foo; override;
     ...
   C=class(B)
     procedure foo; override;
     ...
A(objC).foo();

Nhưng trong Java, bạn có thể thực hiện việc tập trung như vậy chỉ bằng một số thiết bị. Một cách có thể là:

class A {               
   int y=10;            

   void foo(Class X) throws Exception {  
      if(X!=A.class)
         throw new Exception("Incorrect parameter of "+this.getClass().getName()+".foo("+X.getName()+")");
      y++;
      System.out.printf("A.foo(%s): y=%d\n",X.getName(),y);
   }
   void foo() throws Exception { 
      System.out.printf("A.foo()\n");
      this.foo(this.getClass()); 
   }
}

class B extends A {     
   int y=20;            

   @Override
   void foo(Class X) throws Exception { 
      if(X==B.class) { 
         y++; 
         System.out.printf("B.foo(%s): y=%d\n",X.getName(),y);
      } else { 
         System.out.printf("B.foo(%s) calls B.super.foo(%s)\n",X.getName(),X.getName());
         super.foo(X);
      } 
   }
}

class C extends B {     
   int y=30;            

   @Override
   void foo(Class X) throws Exception { 
      if(X==C.class) { 
         y++; 
         System.out.printf("C.foo(%s): y=%d\n",X.getName(),y);
      } else { 
         System.out.printf("C.foo(%s) calls C.super.foo(%s)\n",X.getName(),X.getName());
         super.foo(X);
      } 
   }

   void DoIt() {
      try {
         System.out.printf("DoIt: foo():\n");
         foo();         
         Show();

         System.out.printf("DoIt: foo(B):\n");
         foo(B.class);  
         Show();

         System.out.printf("DoIt: foo(A):\n");
         foo(A.class);  
         Show();
      } catch(Exception e) {
         //...
      }
   }

   void Show() {
      System.out.printf("Show: A.y=%d, B.y=%d, C.y=%d\n\n", ((A)this).y, ((B)this).y, ((C)this).y);
   }
} 

kết quả đầu ra objC.DoIt ():

DoIt: foo():
A.foo()
C.foo(C): y=31
Show: A.y=10, B.y=20, C.y=31

DoIt: foo(B):
C.foo(B) calls C.super.foo(B)
B.foo(B): y=21
Show: A.y=10, B.y=21, C.y=31

DoIt: foo(A):
C.foo(A) calls C.super.foo(A)
B.foo(A) calls B.super.foo(A)
A.foo(A): y=11
Show: A.y=11, B.y=21, C.y=31

Nó chỉ đơn giản là dễ dàng để làm. Ví dụ:

Lớp con C của lớp con B và B của A. Cả ba đều có phương thức methodName () chẳng hạn.

public abstract class A {

    public void methodName() {
        System.out.println("Class A");
    }

}

public class B extends A {

    public void methodName() {
        super.methodName();
        System.out.println("Class B");
    }

    // Will call the super methodName
    public void hackSuper() {
        super.methodName();
    }

}

public class C extends B {

    public static void main(String[] args) {
        A a = new C();
        a.methodName();
    }

    @Override
    public void methodName() {
        /*super.methodName();*/
        hackSuper();
        System.out.println("Class C");
    }

}

Chạy lớp C Kết quả sẽ là: Lớp A Lớp C

Thay vì đầu ra: Class A Class B Class C

public class SubSubClass extends SubClass {

    @Override
    public void print() {
        super.superPrint();
    }

    public static void main(String[] args) {
        new SubSubClass().print();
    }
}

class SuperClass {

    public void print() {
        System.out.println("Printed in the GrandDad");
    }
}

class SubClass extends SuperClass {

    public void superPrint() {
        super.print();
    }
}

Đầu ra: In trong GrandDad

Siêu từ khóa chỉ là một cách để gọi phương thức trong siêu lớp. Trong hướng dẫn Java: https://docs.oracle.com/javase/tutorial/java/IandI/super.html

Nếu phương thức của bạn ghi đè một trong các phương thức của lớp cha, bạn có thể gọi phương thức được ghi đè thông qua việc sử dụng siêu từ khóa.

Đừng tin rằng đó là một tài liệu tham khảo về siêu đối tượng !!! Không, nó chỉ là một từ khóa để gọi các phương thức trong siêu lớp.

Đây là một ví dụ:

class Animal {
    public void doSth() {
        System.out.println(this);   // It's a Cat! Not an animal!
        System.out.println("Animal do sth.");
    }
}

class Cat extends Animal {
    public void doSth() {
        System.out.println(this);
        System.out.println("Cat do sth.");
        super.doSth();
    }
}

Khi bạn gọi cat.doSth(), phương thức doSth()trong lớp Animalsẽ in thisvà đó là một con mèo.