Сегодняшняя тема намного менее предписывающая, чем наши предыдущие две главы, где в контрактах, которым мы должны были следовать, были очень математически обоснованные принципы. Сегодня все гораздо проще. Метод toString() . Как Эффективная Java указывает, Объект дает нам реализацию этого метода по умолчанию но это довольно бесполезно, особенно когда вы пытаетесь отлаживать и вас просто встречают чем-то вроде Животное@23a5b2 . В документации для toString() даже говорится, что “Рекомендуется, чтобы все подклассы переопределяли этот метод”. Ну, все классы являются подклассами Объекта таким образом, это должно означать, что рекомендуется, чтобы все классы переопределяли этот метод.
По моему опыту, одним из основных применений метода toString является помощь в отладке. Независимо от того, переопределяете ли вы метод toString или нет, разработчики попытаются использовать метод toString для отладки. Существует искусство знать, сколько данных объектов нужно предоставить с помощью метода toString . Вы должны попытаться предоставить как можно больше информации с помощью этого метода, но очевидно, что большой объект может быть не в состоянии практически предоставить всю эту информацию. В этих случаях мы должны просто использовать наше суждение, чтобы определить, какие поля являются наиболее полезными.
Необходимо принять решение о том, следует ли документировать формат, в котором будет возвращен метод. С таким контрактом пользователи вашего класса могут ожидать, что будет возвращено, и могут использовать его ожидаемыми способами. Если вы определяете контракт, может быть хорошей идеей также предоставить статический фабричный метод, который принимает строковое представление и создает объект (это, конечно, было бы невозможно, если бы не все данные были предоставлены с помощью метода toString , см. Выше). Конечно, недостатком указания формата является то, что вы будете придерживаться этого формата на всю жизнь и, таким образом, потеряете гибкость.
Еще один пункт, который также следует иметь в виду, – предоставить все данные в методе toString также с помощью обычных геттеров. Чего мы хотим избежать, так это заставить разработчика анализировать выходные данные метода toString , чтобы получить необходимую им информацию. Это будет не только неэффективно, но и подвержено ошибкам.
Иногда переопределение метода toString может быть пропущено, например, в перечислениях и служебных классах.
В очередной раз мы находим место, где Ломбок может помочь нам преодолеть шаблонность. Ломбок @toString аннотация имеет очень специфический формат. Это довольно солидный формат, который предоставляет информацию простым способом. Определенно могут быть лучшие форматы для конкретного контекста, но он использует хорошее значение по умолчанию.
К счастью, эта глава была немного проще, чем наши предыдущие главы. Переопределение метода toString – одна из тех мелочей, которая не привлекает особого внимания но это мелочи, которые имеют значение.
Оригинал: “https://dev.to/kylec32/effective-java-tuesday-override-tostring-14n7”