(String) czy .toString ()?

Mam metodę z Object oparametrem.

W tej metodzie dokładnie wiem, że istnieje String„o”, które nie jest zerowe. Nie ma potrzeby sprawdzać ani robić czegoś innego. Muszę traktować to dokładnie jak Stringprzedmiot.

Po prostu ciekawy - co jest tańsze - rzuć to Stringlub użyj Object.toString()? A może to samo dotyczy ceny czasu / procesora / pamięci?

Aktualizacja: metoda akceptuje, Objectponieważ jest to implementacja interfejsu. Nie ma możliwości zmiany typu parametru.

I wcale tak nie może być null. Chciałem tylko powiedzieć, że nie muszę go sprawdzać pod kątem wartości zerowej lub pustej. W moim przypadku zawsze jest niepusty ciąg.

rzutowanie na String jest tańsze, ponieważ nie wymaga zewnętrznego wywołania funkcji, a jedynie wewnętrzne sprawdzanie typu.

Użyłbym odlewu. To potwierdza twoją „wiedzę”, że jest to ciąg. Jeśli z jakiegoś powodu skończysz z błędem i ktoś przekaże coś innego niż string, myślę, że lepiej byłoby zgłosić wyjątek (co zrobi rzutowanie) niż kontynuować wykonywanie z błędnymi danymi.

Według Silly performance rozważań: x.toString () vs (String) x

Ostatecznie wyniki są zaskakująco jasne: rzutowanie Object na String jest co najmniej dwa razy szybsze niż wywołanie Object.toString ()

Jeśli wiesz, że Object o jest Stringiem, powiedziałbym, że po prostu rzuć go na String i wymuszaj to w ten sposób. Wywołanie metody toString () na obiekcie, o którym wiesz na pewno, że jest ciągiem, może tylko wprowadzić zamieszanie.

Jeśli Object o może być czymś innym niż String, musisz wywołać toString ().

Nie przejmowałbym się zbytnio wykonaniem, gdyby ta operacja była wykonywana nawet kilka tysięcy razy na sekundę - nie ma żadnej namacalnej różnicy.

Obawiałbym się jednak „znajomości” danych wejściowych. Masz metodę, która akceptuje an Objecti powinieneś ją tak traktować, tj. Nie powinieneś nic wiedzieć o parametrze, poza tym, że jest on zgodny z Objectinterfejsem, który tak się składa, że ​​ma toString()metodę. W tym przypadku zdecydowanie sugerowałbym użycie tej metody zamiast po prostu zakładać cokolwiek.

OTOH, jeśli dane wejściowe to zawsze albo Stringalbo null, po prostu zmień metodę na akceptację Strings i sprawdź jawnie nulls (co i tak powinieneś zrobić, gdy masz do czynienia z nieprymitywami ...)

Zakładając, że typem referencyjnym jest Object, a wszystkie obiekty mają toString (), po prostu wywołaj object.toString (). String.toString () po prostu zwraca to.

• toString () to mniej kodu do wpisania.
• toString () to mniejszy kod bajtowy.
• odlewanie jest kosztowną operacją VS wywołanie polimorficzne.
• obsada może zawieść.
• Użyj String.valueOf (object), który po prostu wywołuje object.toString (), jeśli nie ma wartości null.

Jeśli to, co masz w "o", jest ciągiem, nie ma dużej różnicy (prawdopodobnie rzutowanie jest szybsze, ale jest to kwestia implementacji VM / biblioteki).

Jeśli „o” może nie być Stringiem, ale przypuszczalnie jest to String, to rzutowanie jest tym, czego chcesz (ale powinieneś sprawić, by metoda przyjmowała String zamiast Object).

Jeśli "o" może być dowolnego typu, musisz użyć toString - ale najpierw sprawdź, czy nie ma null.

void foo(final Object o)
{
    final String str;

    // without this you would get a class cast exception
    // be wary of using instanceof though - it is usually the wrong thing to do
    if(o instanceof String)
    {
        str = (String)o;
    }    
}

lub

void foo(final Object o)
{
    final String str;

    // if you are 100% sure that o is not null then you can get rid of the else
    if(o != null)
    {
        str = o.toString();
    }
}

Wolę zakodować ostatni jako:

void foo(final Object o)
{
    final String str;

    if(o == null)
    {
        throw new IllegalArgumentException("o cannot be null");
    }

    str = o.toString();
}

Zauważyłem dziwnie, że rzutowanie było wolniejsze niż wyszukiwanie tabeli vtable sugerowane przez wywołanie tostring.

W o nie może być „łańcucha zerowego”. Jeśli o jest null, nie zawiera łańcucha zerowego, jest po prostu zerowe. Po prostu sprawdź najpierw o zero. Jeśli rzucisz lub wywołasz ToString () na null, nastąpi awaria.