Tłumaczenie override method, shadow, hide, etc

1

Myślałem, że tłumaczenie tych słów w kontekście programowania jest jednoznaczne, ale po dyskusji z @somekind wychodzi na to, że nie. Wynurzyłem się ze sprawdzaniem słowników, ale to było przedwczesne, bo słowniki polsko-angielskie często podają wiele tłumaczeń (kilka, czy nawet kilkanaście) dla jednego hasła i w ten sposób można nagiąć tłumaczenie w każdą stronę. Tymczasem w IT potrzebna jest precyzja, więc jeśli ktoś używa słowa "przesłanianie" to powinno to być jednoznaczne.

Tłumaczenie "method overriding" na "nadpisywanie metod" jest np w https://pl.wikipedia.org/wiki/Nadpisywanie_metod i https://pl.wikibooks.org/wiki/C%2B%2B/Funkcje_wirtualne .
Strony https://pl.wikipedia.org/wiki/Przes%C5%82anianie i https://en.wikipedia.org/wiki/Variable_shadowing są w Wikipedii połączone jako wersje językowe, więc to wskazuja na to, że "przesłanianie" to "variable shadowing".
Artykuł https://dzone.com/articles/va[...]-shadowing-and-hiding-in-java jest o tyle fajny, że pokazuje naraz wszystkie 3 rzeczy (method overriding, variable shadowing i variable hiding) i pokazuje między nimi różnice. Jedną z różnic jest to, że nadpisywanie wymaga zgodności sygnatur (metody muszą być override compatible), natomiast przesłanianie czy ukrywanie może wiązać się z zupełną zmianą typu.

Jeśli chodzi o Javę to:

  • przesłonięte (variable shadowing) czy ukryte (variable hiding) pola można odsłonić / odkryć bez uciekania się do refleksji (refleksją można zrobić bardzo dużo rzeczy, więc takie zabawy się nie liczą)
    • odsłanianie jest proste, np w Javowym idiomie z konstruktora this.cośtam = cośtam użyłem this. by odsłonić pole cośtam z obiektu, bo jest zasłonięte parametrem cośtam z konstruktora
    • odkrywanie też jest proste. Jeśli mam class Parent { String x; } oraz class Child extends Parent { int x; } oraz referencję Child ref = ... to mogę zrobić np ((Parent) ref).x = "" + ref.x
  • nadpisywanie metody z klasy Parent w klasie Child oznacza, że do nie mogę na obiekcie klasy Child odpalić implementacji tej metody z klasy Parent. Nie da się w miejscu wywołania metody na obiekcie odwrócić nadpisania.

Jak tłumaczycie te pojęcia sami i z jakimi tłumaczeniami się spotykacie?

0
public class Parent {

    int x = 10;

    void hello() {

        System.out.println("Parent here");
    }
}
public class Child extends Parent {

    int x = 101;

    public static void main(String[] args) {

        Child child = new Child();
        System.out.println("Child : " + child.getChildValue());
        System.out.println("Parent : " + child.getParentValue());

        new Child().foo();
    }

    void hello() {

        System.out.println("Child here");
    }

    private void foo() {

        hello();
        super.hello();
    }

    int getParentValue() {

        return super.x;
    }

    int getChildValue() {

        return x;
    }
}

Child : 101
Parent : 10
Child here
Parent here

2

Ja tam różnicy między shadow a hide w przypadku metod nie widzę.

I generalnie zgadzam się, że tłumaczenie "override" na "nadpisywanie" i rozróżnianie tego od "przesłaniania" ma więcej sensu językowego. Ale spójrzmy na wyniki z pierwszej strony Google:
https://strefainzyniera.pl/artykul/942/przeslanianie-metod
https://1024kb.pl/rekrutacja/[...]rzeciazanie-vs-przeslanianie/
https://skillstest.pl/library/question/123
https://www.samouczekprogrami[...]/dziedziczenie-w-jezyku-java/
http://jsystems.pl/blog/artykul.html?id=25

Wynika z tego, że "nadpisywanie" i "przesłanianie" są powszechnie traktowane jako synonimy. (Być może dlatego, że w Javie chyba nie da się przesłonić/ukryć metody.)

0

I generalnie zgadzam się, że tłumaczenie "override" na "nadpisywanie" i rozróżnianie tego od "przesłaniania" ma więcej sensu językowego. Ale spójrzmy na wyniki z pierwszej strony Google:

"Nadpisywanie metod" daje 103k wyników. "Przesłanianie metod" daje 41k wyników. Może dalego, że jestem za VPNem.

Problem prawdopodobnie zaczął się od kulawego tłumaczenia np książek Caya Horstmanna. Przytoczę to co napisałem w komentarzach:

Znalazłem stronę tłumacza i nawet jest na niej słownik. Jednak tłumaczenia są dość dziwne. overriding tłumaczy jako przesłanianie: http://shebang.pl/stp/overriding/ a shadowing jako zastępowanie: http://shebang.pl/stp/shadowing . Abstrahując od tłumaczenia, shadowing u niego ma błędną definicję. Nie ma też tłumaczenia dla variable hiding.

Bardzo przydałby się kompleksowy i spójny słownik, a nie coś co miesza pojęciami i jest niekompletne.

Być może dlatego, że w Javie chyba nie da się przesłonić/ukryć metody.

W Javie metody niestatyczne da się tylko nadpisać (tzn override) albo przeciążyć (tzn overload). Pola niestatyczne można za to ukryć (tzn variable hiding).

Ja tam różnicy między shadow a hide w przypadku metod nie widzę.

Różnica zdecydowanie jest. Załóżmy, że mamy metody niestatyczne i niewirtualne. Jeśli podklasa ma metodę o takiej samej syganturze co nadklasa to mamy ukrywanie (tzn hiding). Jeśli klasa wewnętrzna ma metodę o takiej samej sygnaturze co klasa zewnętrzna to mamy przesłanianie (tzn shadowing). Przesłanianie można osiągnąć też na inne sposoby, bo na wiele sposobów można osiągnąć zagnieżdżone zasięgi. Ukrywanie (z tego co mi teraz wiadomo) ma natomiast nierozerwalny związek z dziedziczeniem.

0

W Parent

int x = 123;
    void hello() {
int x = 456;
        System.out.println("Parent here");
    }

W Child

  @Override
    void hello() {

        System.out.println("Child here");
    }

albo zapisane bez @Override

    void hello() {

        System.out.println("Child here");
    }

Przesłanianie? Nadpisywanie?

Inny przykład

public class Parent {

    int x = 10;
    int y = 555;

    void hello() {

        System.out.println("Parent here");
    }

    private class Aunt {

        int x = 333;
        y = 999;

        void hello() {

            System.out.println("Aunt here");
        }

    }
}

Jakby wrzucić w internety to dostaniemy mozaikę sprzecznych się odpowiedzi

Java używa @Override dla subklasy, Dla klasy wewnętrznej metoda o tej samej sygnaturze nie może mieć annotacji @Override.
Jeszcze JavaScript i hoisting jakby było mało.

https://programming.guide/jav[...]adowing-hiding-obscuring.html
Na przykład obscuring.

Czy nazwanie zmiennej String jest OK?
Póki nie wywołamy instancji System,in albo System.out jest OK.
Programista używa obscuring albo masz ochotę wytłumaczyć mu dobitnie żeby jednak tego nie robił? :)

BTW gdyby nie ten wątek nie wpadłbym nawet na String System = "Foo Bar";.

0

W Javie adnotacja @Override służy tylko do sterowania komunikatami kompilatora. Nie ma wpływu na działanie programu, bo nie ląduje nawet w bajtkodzie.

https://programming.guide/jav[...]adowing-hiding-obscuring.html

Na przykład obscuring.

To "obscuring" wygląda mi na przypadek szczególny mechanizmu "shadowing".

0
   public boolean equals(Parent p) {

        if (this == p) return true;

        return x == p.x;
    }

    @Override
    public boolean equals(Object o) {

        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        Parent parent = (Parent) o;

        return x == parent.x;
    }

Dla mnie informacja @Override jak i inne annotations służą do sterowania tego najsłabszego elementu całego procesu, siedzącego przed monitorem czyli mnie.

import net.jcip.annotations.GuardedBy;
import net.jcip.annotations.ThreadSafe;

@ThreadSafe
public final class Counter {

    @GuardedBy("this")
    private long value = 0L;

    public synchronized long getValue() {

        return value;
    }

    public synchronized long increment() {

        return ++value;
    }
}

Jest @Override, to przyjmuję że overrided
Jest @ThreadSafe & @GuardedBy("intrinsic lock") to info dla mnie , (i konfiguracji IntelliJ, żeby zaczęło używać JCIP annotations) = na czym synchronizuję. Zapomnę synchronized przy metodzie to na mnie IntelliJ nakrzyczy. Oczywiście skompiluje się bez problemu.
Jest np. @Data by Lombok to info że jej bezargumentowy konstruktor i getters/setters jak pan pojo przykazał.

Dla mnie annotacje mają być pomocne, nie będę się z nimi spierać. Jest @Override w określonych sytuacjach to będę używać słowa override nawet gdyby było oficjalne zestawienie pojęć a w nim inny opis tej sytuacji.

Na szczęście nie muszę wchodzić w tematy tłumaczeń i szukania odpowiednich definicji. Współczuję zadania. Grząski temat.

0

Adnotacje @Override z Javowego stdliba i @Data z Lomboka działają zupełnie inaczej. Jak już napisałem, @Override jest całkowicie opcjonalne (można z tego całkowicie zrezygnować i kod będzie działał tak samo) i steruje tylko komunikatami kompilatora, ale już @Data z Lomboka ma kluczowy wpływ na wygenerowany kod. Używanie adnotacji @Override jest generalnie zalecane.

0

Specjalnie dałem te 3 przykłady, z Java Concurrency in Practice, Lombok i equals. Każdy działa na swoim podwórku i robi swoje, mimo że mówimy annotation @... (trzymam się tylko Javy bez frameworków)
Dalej w małpki nie chcę się już wgłębiać bo nie jestem ich fanem.

0
Wibowit napisał(a):

Problem prawdopodobnie zaczął się od kulawego tłumaczenia np książek Caya Horstmanna. Przytoczę to co napisałem w komentarzach:

No czyli trzeba powiesić tłumacza. ;) (I nie czytać tłumaczeń.)

Różnica zdecydowanie jest. Załóżmy, że mamy metody niestatyczne i niewirtualne. Jeśli podklasa ma metodę o takiej samej syganturze co nadklasa to mamy ukrywanie (tzn hiding). Jeśli klasa wewnętrzna ma metodę o takiej samej sygnaturze co klasa zewnętrzna to mamy przesłanianie (tzn shadowing).

No tak, masz rację. Jakoś nie pomysłałem o takim przypadku - rzadko zagnieżdżam klasy, a przesłonięcie metody w taki sposób chyba mi się nigdy nie zdarzyło. Jakoś cięzko sobie wyobrazić praktyczne zastosowanie do tego.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0