도입
코딩테스트를 준비하면서 Map의 contains 메소드를 사용하여 String을 비교하였다. 그런데 이번에는 무심코 StringBuilder를 비교하였는데 String과 달리 같은 문자로 이루어진 문자열이라도 다른 값으로 인식되었다. 물론 당연하지만 순간적으로 헷갈렸고 간단하게 이에 대한 내용을 글로 정리해보기로 하였다.
내용
String vs StringBuilder
String 클래스와 StringBuilder 클래스의 차이는 Java를 주언어로 사용하고 있는 사람이라면 대부분 알고 있는 사실이다. 때문에 여기서는 간단하게만 짚고 넘어가보자.
특히, 코딩테스트에서 String 클래스 대신 StringBuilder를 쓰는 것은 아주 중요하다.
왜?
시간단축이 되기 때문이다.
String에 새로운 문자열을 더하거나 빼는 등 문자열에 변화를 주는 경우 기존의 String 객체를 삭제하고 새로운 String 인스턴스를 생성한다. 삭제와 생성이 반복되는 과정 속에서 overhead가 심해진다.
반면, StringBuilder나 StringBuffer의 경우 가변성을 가지기 때문에 동일 객체 내에서 문자열 변경이 가능하다.
@Override equals()
그렇다면, 계속 StringBuilder나 StringBuffer를 사용하면 되지 않을까? 가변성에 특화된 API를 잘 갖춘 StringBuilder를 쓸 수 없는 상황이 언제일까?
바로, 동등성 비교 상황이다.
String 은 StringBuilder(또는 StringBuffer)와 달리 equals()를 '오버라이딩'하고 있다.
원래 기본적으로 equals() 메소드는 주소를 비교한다. 즉, 주소값이 같은 객체만 동일하다고 생각한다. 하지만, 우리가 원하는 문자열의 '같음'은 주로 문자열을 구성하는 '문자'가 같은지이지 객체 주소가 같은지가 아니다. 때문에 String은 equals()를 오버라이드하여 주소가 같은 경우는 물론이고 문자가 같은 경우도 true 값을 반환하도록 한다.
위 사진은 Java String 클래스 내부에 구현된 equals() 오버라이드 메소드이다. 두 번째 if문을 보면 코드가 동일한 경우에 대한 구현을 따로 처리해준 것을 알 수 있다.
반면, StringBuilder와 StringBuffer는 따로 equals()가 오버라이드 되어있지 않아서 여느 객체들과 마찬가지로 직접 오버라이드해서 구현해 해주어야한다.
결론
StringBuilder, StringBuffer는 동등성 비교를 위해
- equals()를 새로 재정의해서 구현해주기
- 객체를 String으로 변환해서 이미 오버라이딩 되어있는 equals() 기능 사용하기
두 가지 방법 중 하나를 선택해서 동등성 비교가 가능하다.
또한, 직접적으로 equals()를 사용하는 것 외에도 자주 사용하는 자료구조인 map, set 등의 contains 함수를 사용할 때에도 결국은 객체에서 정의된 equals()가 사용되기 때문에 항상 유의해서 코딩해야한다.
