Чому super.super.method (); заборонено на Java?

Я прочитав це питання і подумав, що його легко вирішити (не те, що без нього не вирішити), якби можна було написати:

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

Я не впевнений, чи корисний він у багатьох випадках, але мені цікаво, чому це не так, і чи щось подібне існує в інших мовах.

Як ви думаєте, хлопці?

EDIT: Для уточнення: так, я знаю, що в Java це неможливо, і я його дуже не сумую. Це я нічого не очікував, і я був здивований помилкою компілятора. У мене просто була ідея і я хотів її обговорити.

Це порушує інкапсуляцію. Ви не повинні мати можливість обійти поведінку батьківського класу. Має сенс іноді бути в змозі обійти поведінку власного класу (особливо, в рамках того ж методу), але не поведінку вашого батька. Наприклад, припустимо, у нас є базова "колекція предметів", підклас, що представляє "колекцію червоних предметів", і підклас групи, що представляє "колекцію великих червоних предметів". Має сенс:

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);
    }
}

Це добре - RedItems завжди може бути впевнений, що всі елементи, які він містить, є червоними. Тепер припустимо , що ми були в змозі назвати 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);
    }
}

Тепер ми можемо додати все, що нам подобається, і інваріант в роботі RedItemsзламаний.

Чи має це сенс?

Я думаю, що Джон Скіт має правильну відповідь. Я хотів би лише додати, що ви можете отримати доступ до тіньових змінних із суперкласів надкласових класів шляхом кастингу 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();
        }
}

який виробляє вихід:

х = 3
super.x = 2
((T2) це) .x = 2
((T1) це) .x = 1
((I) це) .x = 0

(приклад з JLS )

Однак це не працює для викликів методів, оскільки виклики методів визначаються на основі типу часу виконання об'єкта.

Я думаю, що наступний код дозволяє в більшості випадків використовувати super.super ... super.method (). (навіть якщо це некрасиво робити це)

Коротко

1. створити тимчасовий екземпляр типу предка
2. скопіюйте значення полів з оригінального об'єкта в тимчасове
3. викликати цільовий метод на тимчасовий об'єкт
4. скопіювати змінені значення назад у вихідний об'єкт

Використання:

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);
    }
}

У мене недостатньо репутації для коментарів, тому я додам це до інших відповідей.

Джон Скіт відповідає чудово, прекрасним прикладом. У Метта Б є пункт: не всі суперкласи мають надповерхівки. Ваш код порушиться, якби ви назвали супер супер, у якого не було супер.

Об'єктно-орієнтоване програмування (якою є Java) - це все про об'єкти, а не функції. Якщо ви хочете програмування, орієнтоване на завдання, виберіть C ++ або щось інше. Якщо ваш об’єкт не входить до його суперкласу, то вам потрібно додати його до "класу бабусь і дідусів", створити новий клас або знайти інший супер, до якого він підходить.

Особисто я визнав це обмеження однією з найбільших сильних сторін Java. Код є дещо жорстким порівняно з іншими мовами, якими я користувався, але я завжди знаю, чого очікувати. У цьому допомагає «проста і знайома» мета Java. На мій погляд, дзвонити в super.super не просто і не звично. Можливо, розробники відчували те саме?

Для цього є вагомі причини. У вас може бути підклас, який має метод, який реалізований неправильно, але батьківський метод реалізований правильно. Оскільки він належить до бібліотеки третьої сторони, можливо, ви не можете / не бажаєте змінювати джерело. У цьому випадку потрібно створити підклас, але замінити один метод для виклику методу super.super.

Як показано на деяких інших плакатах, це можна зробити за допомогою рефлексії, але слід зробити щось подібне

(SuperSuperClass це) .theMethod ();

Я зараз маю справу з цією проблемою - швидке виправлення полягає в копіюванні та вставці методу надкласу в метод підкласу :)

Окрім дуже хороших моментів, які зробили інші, я думаю, є ще одна причина: що робити, якщо у суперкласу немає суперкласу?

Оскільки кожен клас природно розширюється (принаймні) Object, super.whatever()завжди буде посилатися на метод у надкласі. Але що робити, якщо ваш клас тільки поширюється Object- на що б super.superтоді говорилося? Як слід поводитися з такою поведінкою - помилка компілятора, NullPointer тощо?

Я думаю, що головна причина, чому це не дозволено, полягає в тому, що це порушує інкапсуляцію, але це може бути і малою причиною.

Я думаю, якщо ви перезапишете метод і хочете отримати всі версії суперкласового його типу (як, скажімо, для equals версію суперкласу ), то ви завжди завжди хочете спершу викликати пряму версію суперкласу, яка називатиме свою версію надкласового якщо вона хоче .

Я думаю, що лише рідко має сенс (якщо взагалі я не можу придумати випадок, коли він є) викликати версію методу довільного суперкласу. Я не знаю, чи це взагалі можливо на Java. Це можна зробити на C ++:

this->ReallyTheBase::foo();

Здогадуюсь, тому що він використовується не так часто. Єдина причина, яку я міг бачити, використовуючи його, - це те, якщо ваш прямий батько переосмислив певну функціональність і ви намагаєтесь відновити його до оригіналу.

Мені здається, це суперечить принципам ОО, оскільки прямий батько класу повинен бути тісніше пов'язаний з вашим класом, ніж це бабуся і дідусь.

Подивіться на цей проект Github, особливо змінну objectHandle. Цей проект показує, як насправді та точно називати метод діда на онука.

На всякий випадок, коли посилання розірветься, ось код:

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";
        }
    }
}

Щасливе кодування !!!!

Я б поклав тіло методу super.super в інший метод, якщо це можливо

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();
    }
}

Або якщо ви не можете змінити клас супер-супер, ви можете спробувати це:

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;
    }
}

В обох випадках

new ChildClass().toString();

результати до "Я супер супер"

Здавалося б, можна хоча б отримати клас надкласу надкласу, хоча і не обов'язково його екземпляр, використовуючи рефлексію; якщо це може бути корисним, врахуйте Javadoc за адресою 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);

     }
}

запуск: БУДІВНИЙ УСПІШНИЙ (загальний час: 0 секунд)

Виклик super.super.method () має сенс, коли ви не можете змінити код базового класу. Це часто трапляється, коли ви розширюєте наявну бібліотеку.

Спершу запитайте себе, чому ви розширюєте цей клас? Якщо відповідь "тому, що я не можу її змінити", ви можете створити точний пакет і клас у своїй програмі та переписати неслухняний метод або створити делегат:

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() {...}
    ...
}

Наприклад, ви можете створити org.springframework.test.context.junit4.SpringJUnit4ClassRunner клас у вашому додатку, тому цей клас слід завантажувати перед реальним з банку. Потім перепишіть методи або конструктори.

Увага: Це абсолютний хак, і його настійно НЕ рекомендується використовувати, але це РОБОТА! Використання такого підходу небезпечно через можливі проблеми з навантажувачами класу. Також це може спричинити проблеми щоразу, коли ви будете оновлювати бібліотеку, що містить перезаписаний клас.

У мене були такі ситуації, коли архітектура повинна будувати загальну функціональність у загальному CustomBaseClass, який реалізує від імені кількох похідних класів. Однак нам потрібно обійти загальну логіку для конкретного методу для конкретного похідного класу. У таких випадках ми повинні використовувати супер.super.methodX реалізацію.

Ми досягаємо цього, вводячи бульовий член у CustomBaseClass, який може бути використаний для вибіркового відстрочення користувацької реалізації та приведення до виконання рамки за замовчуванням, де бажано.

        ...
        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(...);
                       }
        }

Однак, з хорошими архітектурними принципами, які дотримуються як в рамках, так і в застосуванні, ми могли б уникнути подібних ситуацій легко, використовуючи hasA підхід, а не підхід isA. Але в будь-який час не дуже практично розраховувати на добре продуману архітектуру, а отже, потрібно піти від твердих принципів дизайну та запровадити подібні хаки. Тільки мої 2 копійки ...

@Jon Skeet Приємне пояснення. ІМО, якщо хтось хоче викликати метод super.super, тоді потрібно ігнорувати поведінку безпосереднього батька, але хоче отримати доступ до поведінки батьків. Цього можна досягти за допомогою примірника Of. Як показано нижче коду

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();
    }
}

Ось клас водія,

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

Результат цього буде

In C Class
In A Class

В цьому випадку поведінка printClass класу B буде ігноровано. Я не впевнений, це ідеальна чи хороша практика для досягнення супер.супера, але все-таки це працює.

Якщо ви думаєте, що вам знадобиться суперклас, ви можете посилатися на нього у змінній для цього класу. Наприклад:

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;
  }
}

Слід роздрукувати:

2
1
0

IMO, це чистий спосіб досягти super.super.sayYourName()поведінки на 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);
    }
}

Вихід:

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

Я думаю, це проблема, яка порушує спадковий договір.
Розширюючи клас, ви підкоряєтесь / погоджуєтесь з його поведінкою, особливостями
Під час дзвінка super.super.method()ви хочете розірвати власну угоду про послух.

Ви просто не можете вибрати вишню з суперкласу .

Однак можуть траплятися ситуації, коли ви відчуваєте необхідність дзвонити super.super.method()- зазвичай це поганий знак оформлення, у вашому коді чи в коді, який ви успадковуєте!
Якщо супер та супер суперкласи не вдається відновити ремонт (деякий застарілий код), тоді вибирайте склад над успадкуванням.

Порушення інкапсуляції - це коли ви @Override деякі методи, порушивши інкапсульований код. Методи, розроблені таким чином, що їх не можна перекривати, позначаються остаточними .

У C # ви можете назвати метод будь-якого предка, як це:

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();
    }

Також ви можете це зробити в Delphi:

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

Але на Java ви можете робити таке фокусування лише деякими передачами. Один з можливих способів:

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);
   }
} 

Вихід результату 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

Зробити це просто просто. Наприклад:

Підклас C підкласу B і B А. Наприклад, обидва з трьох мають метод methodName ().

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");
    }

}

Виконати клас C Вихід буде: Клас A Клас 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();
    }
}

Вихід: Надрукований у GrandDad

Ключове слово super - це лише спосіб викликати метод у надкласі. У навчальному посібнику Java: https://docs.oracle.com/javase/tutorial/java/IandI/super.html

Якщо ваш метод переосмислює один із методів його надкласового класу, ви можете викликати метод переосмисленості за допомогою ключового слова super.

Не вірте, що це посилання на супероб'єкт !!! Ні, це лише ключове слово, щоб викликати методи у надкласі.

Ось приклад:

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();
    }
}

Коли ви телефонуєте cat.doSth(), метод doSth()у класі Animalбуде друкувати, thisі це кішка.