책에서는 toString 를 구현함을 통해 객체의 내부가 변해도 유연하게 대응할 수 있다고 말합니다.
하지만 저는 View 에서 사용할 출력용 객체를 명시적으로 만드는 것이 좋다고 생각합니다.
REST API 에서의 개발은 객체의 내용을 추상화하여 간결히 표현하는 것은 거의 필요가 없기 때문입니다.
반면에 View 에 맞는 객체로 포장하는 경우는 비교적 많기 때문에 하위 호환성을 위한 toString 을 구현하는 일은 적었습니다.
객체의 내부를 알아야하는 단점은 존재합니다.
어쩌면 리소스 기반의 설계가 아닌, RDB 기반의 설계 환경에서만 일해서 이런 습관이 들었는지도 모르겠습니다.
아래의 예시는 front 에서 신경써야하는 부분일 수도 있지만, 보안 등의 이유로 back-end 에서 하는 경우도 많았습니다.
public class PhoneNumber {
private final String number1;
private final String number2;
private final String number3;
}
// 일반 전화번호가 필요한 화면에서의 출력 객체 - 고객센터 화면에서는 전화번호가 보여야함
public class NormalResponse {
private final String printString;
public NormalResponse(final PhoneNumber phoneNumber) {
printString = String.format("%s-%s-%s", phoneNumber.getNumber1(), phoneNumber.getNumber2(), phoneNumber.getNumber3());
}
}
// 가운데 자리수가 마스킹된 전화번호가 필요한 화면에서의 출력 객체 - 일반 웹에서는 전화번호가 모두 노출되면 안됨
public class MaskedResponse {
private final String printString;
public MaskedResponse(final PhoneNumber phoneNumber) {
printString = String.format("%s-****-%s", phoneNumber.getNumber1(), phoneNumber.getNumber3());
}
}
// 국제번호가 필요한 전화번호가 필요한 화면에서의 출력 객체 - 외국인이 들어오는 페이지에는 국제번호가 보여야 됨
public class InternationalResponse {
private final String printString;
public InternationalResponse(final String internationalNumber, final PhoneNumber phoneNumber) {
printString = String.format("%s-%s-%s-%s", internationalNumber, phoneNumber.getNumber1(), phoneNumber.getNumber2(), phoneNumber.getNumber3());
}
}