Я только что наткнулся на это StringBuilder .equals Java, где java StringBuilder не имеет реализации Equals(). Однако в C# я заметил, что существует реализация Equals() для класса StringBuilder. Мне особенно хотелось бы знать, как это обрабатывается на C# и почему не на Java.StringBuilder Equals in C# и Java
StringBuilder.equals() фактически существует, но он не сравнивает строки. С точки зрения Java это правильный подход. StringBuilder s mutate, это их цель, что делает два разных объекта StringBuilder не равными по определению. Большинство новых API Java следуют подходу, который equal() реализован для неизменяемых или конечных классов, хотя есть исключения. С другой стороны, классы Mutable, как правило, просто наследуют Object.equals(), который полагается на идентификатор объекта.
По меньшей мере две причины этого. Одна из них - способность правильно использовать объекты в структурах данных на основе хэша, то есть как значение в HashSet, или ключ в HashMap. Хотя это зависит от Object.hashCode(), оно влияет на Object.equals(), потому что hashCode должно быть стабильным по времени жизни объекта, если оно должно использоваться как запись в структуре данных на основе хеша, и equals() определяется как согласованный с hashCode().
Другим является то, что Object.equals() определяется как симметричный, а неосторожное переопределение Object.equals() может нарушить эту симметрию.
В целом, на Java, Object.equals() не следует понимать как равенство ценности, а как равенство в соответствии с природой экземпляров.
Различные рамки используют разные подходы - чтобы выяснить, почему они были разработаны таким образом, вам, вероятно, придется спросить команды, которые их разработали. Равенство изменчивых типов может быть полезным, но оно также может быть бесполезным. –
В java StringBuilder.toString() имеет equals() для сравнения строкового значения – Jaskey