Java динамично обвързване и отмяна на метод

Java използва статично обвързване за претоварени методи и динамично обвързване за заменени. Във вашия пример методът equals е претоварен (има различен тип параметър от Object.equals()), така че извиканият метод е обвързан с типа reference по време на компилиране.

Някои дискусии тук

Фактът, че това е методът на равенствата, не е наистина уместен, освен че е често срещана грешка да се претоварва вместо да се отменя, за което вече сте наясно въз основа на вашия отговор на проблема в интервюто.

Редактиране: Добро описание тук също. Този пример показва подобен проблем, свързан вместо това с типа параметър, но причинен от същия проблем.

Вярвам, че ако обвързването беше действително динамично, тогава всеки случай, когато извикващият и параметърът бяха екземпляр на Test, ще доведе до извикването на заменения метод. Така че t3.equals(o1) ще бъде единственият случай, който няма да се отпечата.

Методът equals на Test не заменя метода equals на java.lang.Object. Вижте типа параметър! Класът Test претоварва equals с метод, който приема Test.

Ако методът equals е предназначен за отмяна, той трябва да използва анотацията @Override. Това би причинило грешка при компилиране, за да посочи тази често срещана грешка.

Интересното е, че в кода на Groovy (който може да бъде компилиран във файл на клас), всички извиквания освен едно ще изпълнят оператора за печат. (Този, който сравнява тест с обект, очевидно няма да извика функцията Test.equals(Test).) Това е така, защото groovy ПРАВИ напълно динамично писане. Това е особено интересно, защото няма променливи, които са изрично динамично въведени. Четох на няколко места, че това се смята за вредно, тъй като програмистите очакват Groovy да направи нещото с java.

Java не поддържа ко-вариация в параметри, само в типове връщане.

С други думи, докато вашият върнат тип в отменен метод може да е подтип на това, което е бил в отменения, това не е вярно за параметрите.

Ако вашият параметър за equals в Object е Object, поставянето на equals с нещо друго в подклас ще бъде претоварен, а не отменен метод. Следователно единствената ситуация, в която този метод ще бъде извикан, е когато статичният тип на параметъра е Test, както в случая с T3.

Успех в процеса на интервю за работа! Бих се радвал да бъда интервюиран в компания, която задава този тип въпроси вместо обичайните въпроси за алгоритми/структури от данни, на които преподавам на студентите си.

Мисля, че ключът се крие във факта, че методът equals() не отговаря на стандарта: той приема друг тестов обект, а не обект Object и по този начин не отменя метода equals(). Това означава, че всъщност сте го претоварили само, за да направи нещо специално, когато му е даден Test обект, докато му давате Object обект извиква Object.equals(Object o). Разглеждането на този код през която и да е IDE трябва да ви покаже два метода equals() за Test.

Методът е претоварен вместо отменен. Equals винаги приема обект като параметър.

между другото, имате елемент за това в ефективната Java на Bloch (която трябва да притежавате).

Някои бележки в Динамично обвързване (DD) и Статично обвързване̣̣̣(SB) след известно търсене:

1. Време за изпълнение: (Спр. 1)

• DB: по време на изпълнение
• SB: време на компилатор

2. Използва се за:

• DB: отмяна
• SB: претоварване (статично, лично, окончателно) (Спр. 2)

Справка:

1. Изпълнете средство за преобразуване кой метод предпочитате да използвате
2. Тъй като не може да се замени метод с модификатор static, private или final
3. http://javarevisited.blogspot.com/2012/03/what-is-static-and-dynamic-binding-in.html

Ако се добави друг метод, който замества вместо претоварване, той ще обясни извикването на динамично обвързване по време на изпълнение.

/* Какъв е резултатът от следната програма? */

public class DynamicBinding {
    public boolean equals(Test other) {
        System.out.println("Inside of Test.equals");
        return false;
    }

    @Override
    public boolean equals(Object other) {
        System.out.println("Inside @override: this is dynamic binding");
        return false;
    }

    public static void main(String[] args) {
        Object t1 = new Test();
        Object t2 = new Test();
        Test t3 = new Test();
        Object o1 = new Object();

        int count = 0;
        System.out.println(count++);// prints 0
        t1.equals(t2);
        System.out.println(count++);// prints 1
        t1.equals(t3);
        System.out.println(count++);// prints 2
        t3.equals(o1);
        System.out.println(count++);// prints 3
        t3.equals(t3);
        System.out.println(count++);// prints 4
        t3.equals(t2);
    }
}

Намерих интересна статия за динамично срещу статично свързване. Той идва с част от кода за симулиране на динамично обвързване. Това направи кода ми по-четлив.

https://sites.google.com/site/jeffhartkopf/covariance

Отговорът на въпроса "защо?" така се дефинира езикът Java.

За да цитирам статията в Уикипедия за ковариацията и контравариацията:

Ковариацията на връщания тип е внедрена във версията на езика за програмиране Java J2SE 5.0. Типовете параметри трябва да бъдат абсолютно еднакви (инвариантни) за отмяна на метода, в противен случай методът се претоварва с паралелна дефиниция вместо това.

Другите езици са различни.

Много ясно е, че тук няма концепция за пренебрегване. Това е претоварване на метода. методът Object() на клас Object приема референтен параметър от тип Object, а този equal() метод взема референтен параметър от тип Test.

Ще се опитам да обясня това чрез два примера, които са разширените версии на някои от примерите, на които попаднах онлайн.

public class Test {

    public boolean equals(Test other) {
        System.out.println("Inside of Test.equals");
        return false;
    }

    @Override
    public boolean equals(Object other) {
        System.out.println("Inside of Test.equals ot type Object");
        return false;
    }

    public static void main(String[] args) {
        Object t1 = new Test();
        Object t2 = new Test();
        Test t3 = new Test();
        Object o1 = new Object();

        int count = 0;
        System.out.println(count++); // prints 0
        o1.equals(t2);

        System.out.println("\n" + count++); // prints 1
        o1.equals(t3);

        System.out.println("\n" + count++);// prints 2
        t1.equals(t2);

        System.out.println("\n" + count++);// prints 3
        t1.equals(t3);

        System.out.println("\n" + count++);// prints 4
        t3.equals(o1);

        System.out.println("\n" + count++);// prints 5
        t3.equals(t3);

        System.out.println("\n" + count++);// prints 6
        t3.equals(t2);
    }
}

Тук за редове със стойности на броя 0, 1, 2 и 3; имаме референция на Обект за o1 и t1 на метода equals(). Така по време на компилиране методът equals() от файла Object.class ще бъде ограничен.

Въпреки това, въпреки че препратката на t1 е Object, тя има инициализация на Тестов клас.
Object t1 = new Test();.
Следователно по време на изпълнение той извиква public boolean equals(Object other), което е an

отменен метод

.

Сега, за стойности на броя като 4 и 6, отново е ясно, че t3, който има препратка и инициализация на Test, извиква equals() метод с параметър като препратки към обекти и е

претоварен метод

OK!

Отново, за да разберете по-добре какъв метод ще извика компилаторът, просто щракнете върху метода и Eclipse ще маркира методите от подобен тип, които смята, че ще извика по време на компилиране. Ако не бъде извикан по време на компилиране, тогава тези методи са пример за заместване на метод.