关于避免对toString（）结果进行解析或基于逻辑的美德

使用Java或我使用过的其他编程语言，我发现有时可以用该语言完成某些事情，但通常不应该这样做。通常，这些误用语言似乎无害，当开发人员首次使用它们时可能有益，但后来同一位开发人员或另一位开发人员遇到了相关的问题，需要克服或改变这些问题。一个示例（也是本博客文章的主题）是使用Java中toString()调用的结果进行逻辑选择或对其内容进行解析。

在2010年，我用Java语言编写了toString（）注意事项，当toString()方法可明确用于类时以及当它们包含该类对象的相关公共状态时，我通常会首选它。我仍然有这种感觉。但是，我希望toString()实现足以使人们通过记录的语句或调试器读取对象的内容，而不是要由代码或脚本解析的内容。使用toString()方法返回的String进行任何类型的条件或逻辑处理都非常脆弱。同样，解析toString()返回的String以获取有关实例状态的详细信息也是脆弱的。我警告过（甚至是无意间）要求开发人员在前面提到的博客文章中解析toString()结果。

开发人员可能出于多种原因选择更改toString()的生成的String，包括将现有字段添加到以前可能未表示过的输出中，将更多数据添加到已经表示过的现有字段中，为新添加的字段添加文本，删除不再在课程中的字段的表示形式或出于美学原因更改格式。开发人员还可以更改toString()生成的String拼写和语法问题。如果toString()提供的String仅由人类在日志消息中分析对象的状态时使用，则这些更改不太可能成为问题，除非它们删除了实质信息。但是，如果代码依赖于整个String或为某些字段解析String ，则可以通过这些类型的更改轻松地将其破坏。

出于说明目的，请考虑以下Movie类的初始版本：

package dustin.examples.strings;/*** Motion Picture, Version 1.*/
public class Movie
{private String movieTitle;public Movie(final String newMovieTitle){this.movieTitle = newMovieTitle;}public String getMovieTitle(){return this.movieTitle;}@Overridepublic String toString(){return this.movieTitle;}
}

在这个简单且有些人为的示例中，只有一个属性，因此类的toString()仅仅返回该类的单个String属性作为类的表示形式并不罕见。

下一个代码清单包含一个不幸的决定（第22-23行），该决定基于Movie类的toString()方法的逻辑。

/*** This is a contrived class filled with some ill-advised use* of the {@link Movie#toString()} method.*/
public class FavoriteMoviesFilter
{private final static List<Movie> someFavoriteMovies;static{final ArrayList<Movie> tempMovies = new ArrayList<>();tempMovies.add(new Movie("Rear Window"));tempMovies.add(new Movie("Pink Panther"));tempMovies.add(new Movie("Ocean's Eleven"));tempMovies.add(new Movie("Ghostbusters"));tempMovies.add(new Movie("Taken"));someFavoriteMovies = Collections.unmodifiableList(tempMovies);}public static boolean isMovieFavorite(final String candidateMovieTitle){return someFavoriteMovies.stream().anyMatch(movie -> movie.toString().equals(candidateMovieTitle));}
}

尽管有多个电影共用同一标题，但是尽管存在一些潜在的问题，该代码似乎仍然可以工作一段时间。但是，即使在遇到这些问题之前，如果开发人员确定他或她想将Movie.toString()表示形式的格式更改为下一个显示的内容，则可能会意识到在相等性检查中使用toString()的风险。代码清单。

@Override
public String toString()
{return "Movie: " + this.movieTitle;
}

也许更改了Movie.toString()返回值，以使提供的String与Movie类的实例相关联更加清楚。不管进行更改的原因如何，以前列出的在影片标题上使用相等性的代码现在都已损坏。该代码需要更改为使用contains而不是equals ，如下面的代码清单所示。

public static boolean isMovieFavorite(final String candidateMovieTitle)
{return someFavoriteMovies.stream().anyMatch(movie -> movie.toString().contains(candidateMovieTitle));
}

当意识到Movie类需要更多信息来使电影与众不同时，开发人员可以将发行年份添加到movie类中。接下来显示新的Movie类。

package dustin.examples.strings;/*** Motion Picture, Version 2.*/
public class Movie
{private String movieTitle;private int releaseYear;public Movie(final String newMovieTitle, final int newReleaseYear){this.movieTitle = newMovieTitle;this.releaseYear = newReleaseYear;}public String getMovieTitle(){return this.movieTitle;}public int getReleaseYear(){return this.releaseYear;}@Overridepublic String toString(){return "Movie: " + this.movieTitle;}
}

添加发行年份有助于区分名称相同的电影。这也有助于将翻拍与原作区分开。但是，无论电影发行的年份如何，使用Movie类查找收藏夹的代码仍将显示所有具有相同标题的电影。换句话说，1960年版的《 海洋十一人》 （目前对IMDB评分为6.6 ）将与2001版的《 海洋十一人》 （目前对IMDB评分为7.8 ）一起成为最受欢迎的游戏，尽管我更喜欢较新的版本。同样，1988年提出为电视版后窗（的5.6评级目前IMDB ）将返回为收藏旁边的1954年版后窗（执导的阿尔弗雷德·希区柯克，主演詹姆斯·斯图尔特和格蕾丝·凯莉，以及额定8.5目前在IMDB中），尽管我更喜欢旧版本。

我认为toString()实现通常应包含对象的所有公共可用细节。但是，即使将Movie的toString()方法增强为包括发行年份，客户端代码仍然不会基于年份进行区分，因为它仅对电影标题执行contain 。

@Override
public String toString()
{return "Movie: " + this.movieTitle + " (" + this.releaseYear + ")";
}

上面的代码显示了添加到Movie的toString()实现中的发行年份。下面的代码显示了如何更改客户以正确遵守发布年份。

public static boolean isMovieFavorite(final String candidateMovieTitle,final int candidateReleaseYear)
{return someFavoriteMovies.stream().anyMatch(movie ->   movie.toString().contains(candidateMovieTitle)&& movie.getReleaseYear() == candidateReleaseYear);
}

我想情况下它是一个解析一个好主意，这是很难toString()上的结果，方法或基础条件或其他逻辑toString()方法。在我考虑的几乎所有示例中，都有更好的方法。在上面的示例中，最好向Movie添加equals() （和hashCode() ）方法，然后对Movie实例使用相等性检查，而不要使用单个属性。如果确实需要比较各个属性（例如，在不需要对象相等且只需要一个或两个字段相等的情况下），则可以使用适当的getXXX方法。

作为一名开发人员，如果我希望类的用户（通常会最终包括我自己）不需要解析toString()结果或依赖于某个结果，则需要确保我的类使toString()提供任何有用的信息toString()可从其他易于访问且更编程友好的资源中获得，例如“获取”方法以及相等性和比较方法。如果开发人员不想通过公共API公开某些数据，则很可能开发人员也可能真的不想在返回的toString()结果中公开数据。 Joshua Bloch （ Effective Java）以粗体强调该文本：“…提供对toString()返回值中包含的所有信息的编程访问。”

在Effective Java中 ，Bloch还包括有关toString()方法是否应具有其提供的String表示形式的公告格式的讨论。他指出，这种表示形式（如果进行广告宣传的话）必须是从那时起一直使用的，如果它是一个广泛使用的类，那么它将避免我在本文中演示的运行时中断的类型。他还建议，如果不能保证格式保持不变，则Javadoc也应包含与此相关的声明。总的来说，由于Javadoc和其他注释通常比我想要的更被忽略，并且由于所宣传的toString()表示形式具有“永久性”，因此我宁愿不依赖于toString()提供客户端所需的特定格式，而是提供一种专用于客户可以调用的方法。这使我可以灵活地在类更改时更改toString() 。

JDK中的示例说明了我的首选方法，还说明了将特定格式指定为toString()的早期版本的危险。 BigDecimal的toString（）表示在JDK 1.4.2和Java SE 5之间进行了更改，如“ J2SE 5.0中的不兼容性（自1.4.2起） ”所述：“ J2SE 5.0 BigDecimal的toString()方法的行为与早期版本不同版本。” BigDecimal.toString() 1.4.2版本的Javadoc只是在方法概述中声明：“返回此BigDecimal的字符串表示形式。使用Character.forDigit（int，int）提供的数字到字符的映射。前导减号用于表示符号，小数点右边的位数用于表示刻度。（该表示法与（String）构造函数兼容。）” Java SE 5和更高版本中BigDecimal.toString（）的相同方法概述文档更加详细。这样冗长的描述，我这里不再赘述。

当BigDecimal.toString()是与Java SE 5改变，其他的方法被引入本不同String表示： toEngineeringString（）和toPlainString（）。新引入的方法toPlainString()提供了JDK 1.4.2提供的BigDecimal的toString() 。我倾向于提供提供特定String表示形式和格式的方法，因为这些方法可以具有其名称中描述的格式的细节，并且Javadoc注释以及对类的更改和添加不会像对它们产生影响那样对这些方法产生影响一般的toString()方法。

有一些简单的类可能适合原始实现的toString()方法将一劳永逸地修复且“永远不会”改变的情况。那些可能是解析返回字符串或在基础逻辑候选String ，但即使在这种情况下，我更喜欢提供一种具有广告和有保证的格式的另一种方法和离开toString()表示一些灵活性变化。拥有多余的方法没什么大不了的，因为尽管它们返回相同的内容，但多余的方法可以仅仅是调用toString的单行方法。然后，如果toString()确实发生了更改，则可以将调用方法的实现更改为以前提供的toString() ，并且该额外方法的任何用户都不会看到任何更改。

当将toString()结果解析为逻辑或基于toString()调用的结果逻辑时，最有可能在将特定方法视为客户访问特定数据的最简单方法时进行。最好通过其他特定的公共可用方法来使数据可用，并且类和API设计人员可以通过确保toString()提供的String中甚至可能有用的任何数据也可以通过编程访问的特定替代方法来提供帮助。方法。简而言之，我的首选是将toString()一种方法，以查看有关表示形式中实例的一般信息，该实例可能会发生更改，并为表示形式中的特定数据段提供特定的方法，这些数据的更改可能性较小且更容易以编程方式访问决策并基于可能需要特定于格式的解析的大型String进行决策。