Skocz do zawartości
  • 👋 Witaj na MPCForum!

    Przeglądasz forum jako gość, co oznacza, że wiele świetnych funkcji jest jeszcze przed Tobą! 😎

    • Pełny dostęp do działów i ukrytych treści
    • Możliwość pisania i odpowiadania w tematach
    • System prywatnych wiadomości
    • Zbieranie reputacji i rozwijanie swojego profilu
    • Członkostwo w jednej z największych społeczności graczy

    👉 Dołączenie zajmie Ci mniej niż minutę – a zyskasz znacznie więcej!

    Zarejestruj się teraz

Przeciązanie metod


Rekomendowane odpowiedzi

Opublikowano

K, dajmy np podstawowy System.out tam jest pierdylion przeciążonych metod np:

 

System.out.println(char);

​System.out.println(String);

​System.out.println(Object);

 

Każda metoda nie różni się nazwą tylko parametrem jaki przyjmuje, dlatego jest przeciążona. 

Po polskiemu to brzmi troche groźnie jakoby nie należało tego używać, co nie jest do końca prawdą.

 

dajmy na to masz klase i w tej klasie zmienną i metodę która zwraca zmieną w zależności od podanego parametru

class c

int i;

int getI(String string) return getI(string.lenght);

int getI(int lenght) return i*lenght;

 

I teraz wyjaśnienie. Nie zawsze musisz używać tylko jednego typu parametru do wyciągnięcia zmiennej bądź odczytania czegoś, niekiedy potrzebujemy takiej hierarchii by nasz kod był bardziej elastyczny a zarazem czytelny.

 

Troche inny kod do zobrazowania:

public boolean findPath(Position start, Position end, boolean checkForObstacles, ATLocalPath pathHolder) {

     //kod

    }

    public boolean findPath(Position start, Position end, ATLocalPath holder) {
        return findPath(start, end, true, holder);
    }

    public boolean findPath(Position target, ATLocalPath holder) {
        return findPath(script.myPosition(), target, holder);
    }

    public boolean findPath(Position start, Position end) {
        return findPath(start, end, pathHolder);
    }

    public boolean findPath(Position target) {
        return findPath(script.myPosition(), target, pathHolder);
    }
  

Metoda najwyżej jest metodą główną tzn posiada wszystkie możliwe argumenty które potrzeba do wyszukania ścieżki od a do b, czy powinna sprawdzać przeszkody oraz gdzie powinna przechować znalezioną ścieżkę.

 

Metoda niżej została pozbawiona parametru sprawdzania przeszkód oraz został on zainicjowany jako true w wywołaniu metody bazowej, true dlatego ponieważ najwięcej razy w kodzie używa się właśnie tej wartości, więc aby zmniejszyć objętość kodu ogólnego skracamy sobie o parametr.

 

Następna metoda została znowuż pozbawiona parametru a mianowicie pozycji startowej, pozycja startowa została zainicjowana jako aktualna pozycja gracza, bo analogicznie do poprzedniego parametru jest on najbardziej używanym w kodzie podczas wywoływania. 

 

Kolejna metoda została pozbawiona parametru przechowującego naszą ścieżkę, ale to nie oznacza że będzie ona nullem, gdyż utworzyliśmy sobię zmienną finalną (nie widać) w klasie która ową ścieżkę wyszukuje, dlaczego? dlatego, że znowu w większości przypadków nie potrzebujemy takiego śmiecia jak zmienna lokalna która będzie nam przechowywać wyszukaną ścieżkę więc podczas chodzenia po odpowiednim wywołaniu metody po prostu wydobędziemy ją z klasy szukającej.

 

I tak doszliśmy do momentu gdy mamy metodę z jednym parametrem, a praktycznie robiącej to samo tylko bez zbędnych pierdół (aktualnie wywołania tej metody przekraczają 70% wszystkich z tej klasy, więc jest ona królem jeśli można tak to ująć). A tylko jeśli klient zachce sobie wyszukać ścieżkę i przechować ją gdzie indziej bądź wyszukać ścieżkę od jakichkolwiek innych punktów z pomocą przyjdą mu pozostałe metody.

 

W ten oto sposób kod jest elastyczny a zarazem wywołania są krótsze.

Opublikowano

Jak po przeczytaniu rozdzialu/artykulu o tym jest to dla ciebie trudne to zrezygnuj z programowania

Ja też tego kiedyś nie rozumiałem, a teraz jestem w stanie to wytłumaczyć.

Przeciążanie metod to nie jest tylko to co piszą w tutkach dla osób startujących z programowaniem, to zagadnienie sięga po optymalizacje czytelności poprzez refaktoryzację kodu, nie jest to tak proste zagadnienie jak się spojrzy w głąb. Prosta jest teoria, a w praktyce trzeba wiedzieć gdzie można zastosować i czy to będzie się opłacać ._.

Zarchiwizowany

Ten temat przebywa obecnie w archiwum. Dodawanie nowych odpowiedzi zostało zablokowane.

×
×
  • Dodaj nową pozycję...