[객체지향설계] 좋은 객체에 대한 설계

클래스와 객체

 

 

 

흔히들 붕어빵과 붕어빵 틀, 설계도와 건물과 같은 식으로 클래스와 객체를 설명해왔다. 나 역시 비슷한 수준으로 클래스와 와 객체에 대해 이해하고 있을 뿐이었다. 다만, 그러한 수준으로 클래스와 객체의 관계와 그 자체를 이해하는 것은 정확하지 못하다.

 

클래스의 책임은 객체를 생성하고, 적절한 때에 파괴하는 것이다. 또한 클래스의 자식들이 어떤 모습이며 어떤 행동을 해야 하는 지 적어놓은 "계약"에 대해서 알고 있다. 객체는 계약에 대한 자격을 갖추기 위해 인터페이스를 구혐함으로써 이를 준수하게 된다. 물론 인터페이스는 추상화를 통해 다형성이 보장된 다는 점에서도 의미가 있긴하다.

 

 

 

 

 

객체는 생명체이다.

 

 

올바른 객체는 그 자체로 생명체이다. 현실 세계의 피조물의 대리자 그 자체이며, 생명주기와 행위, 습관을 지닌 것이다. 예를 들어, 직원이나 부서, HTTP 요청이나 파일 등이 적절한 객체이다.

 

HTTP 요청이나 파일 등은 컴퓨터를 켜야하는 가상세계에서만 존재하는 것이 아닌가 생각할 수 있다. 그래서 현실세계의 정의를 조금 다르게 생각해야 한다. 현실세계는 객체가 살아가는 프로그램 범위에서 존재하는 모든 것이다.

 

컴퓨터에서 프로그램이 동작하는 곳이 아니라, 실제 파일이 저장된 디스크도 현실세계이며 프로그램에서는 단순히 이를 대표할 뿐이다.

 

GoF 패턴은 다른 객체와 함께 사용하기 위한 패턴이다. 컨트롤러나 싱글턴, 팩터리 그 자체로 본다면 좋은 객체가 될 수 없다. 이는 GoF 패턴이 현실세계의 대표자가 될 수 없기 때문이다.

 

 

 

 

 

 

객체는 고유하며, 불변적이다.

 

 

캡슐화는 고유성을 지키기 위해서 필연적이다. 만약 복사하는 것이 가능하다면, 동일한 복제본을 가지게 되며 이는 바람직하지 않다.

 

그렇기 때문에 좋은 객체는 캡슐화하는 상태를 지키기 위해 불변성을 유지하고자 한다. 그렇게 하여 객체는 그 객체가 대표하는 것을 배신하지 않아야 한다.

 

@Immutable
final class HTTPStatus implements Status {
  private URL page;
  public HTTPStatus(URL url) {
    this.page = url;
  }
  @Override
  public int read() throws IOException {
    return HttpURLConnection.class.cast(
      this.page.openConnection()
    ).getResponseCode();
  }
}

 

 

_read()_ 함수가 다른 값을 반환하는 것이 가능하더라도, 자신이 대표하는 URL 자체는 절대 변하지 않으며 _setter_를 통해 배신하는 일 따위는 존재하지 않는다.

 

그렇다면, 불변성이 보장된다면 어떤 점에서 더욱 좋을까?

 

• 생성과 테스트, 그리고 사용하기 간편하다.
• 불변 객체는 스레드 안전(Thread Safe)하다.
• 불변 객체는 시간적 결합을 피하는데 도움이 된다.
• 불변 객체는 부수효과(side effect)를 일으키지 않는다.
• 불변 객체는 실패원자성(Failure Atomic)을 띈다.
• 캐싱하기 쉬워진다.
• NULL 참조를 방지한다.

 

 

 

🔶 불변 객체는 스레드 안전하다.

스레드 안전하다는 말이 의미하는 바는 곧, 여러 스레드에서 접근하여도 좋다는 뜻이다. 그렇게 하여도 전혀 충돌할 일이 발생하지 않기 때문이다. 

어떤 메서드도 해당 객체의 상태를 변경할 수 없으며, 각 객체는 메모리 공간 상의 고유한 자리를 차지하고 있다.


🔶 불변 객체는 시간적 결합(Temporal Coupling)을 피할 수 있다.


시간적 결합은 A 메서드가 B 메서드보다 반드시 먼저 호출해야 한다는 것에서 발생한다. 이러한 상태는 작업에 순서에 의존성이 존재함을 말한다. 만약 시간적 결합이 없는 작업들은 동시에 처리될 수 있다. 즉, 동시성에 대한 고민을 할 수 있고, 보다 나은 설계를 해낼 수 있다. 이는 더욱 좋은 확장 가능성과 성능을 가져온다.

불변 객체를 사용함으로써 이러한 시간적 결합을 없앨 수 있다. 


🔶 실패 원자적인(Faliure Atomic) 메소드를 만들 수 있다.

가변 객체는 작업 도중 예외가 발생하면, 불안정한 상태에 빠지게 된다. 이는 또 다른 에러를 야기할 수 있다. 반면, 불변 객체는 아무리 예외가 발생하더라도 초기 메서드 호출 이전의 상태를 항상 유지할 수 있다. 또한 예외가 발생하더라도 다음 로직의 처리가 가능하다.


🔶 부수효과(side effect)를 피해 오류를 피할 수 있다.

부수효과란 변수의 값, 객체의 필드 값, 자료구조가 바뀌거나 에러나 I/O가 발생하는 것을 의미한다. 만약 _setter_를 통해 값이 변화된다면, 전혀 부수효과를 지니지 못하며 객체의 상태를 예측하기 어려울 것이다.

따라서 부수효과를 제거한 순수함수를 만드는 것이 굉장히 중요해진다. 이때, 객체가 불변객체라면 이러한 순수함수를 만드는 데 용이해진다.

기본적으로 불변객체는 수정이 불가능하며, 객체를 생성하고 사용하는데 여러가지 제한이 있다. 즉, 메서드들도 자연스럽게 부수효과가 제거된 순수함수로 이루어질 것이다. 이는 다른 함수에 의해서 해당 객체의 상태가 변할 수 없음을 의미하며 오류를 줄이고, 유지보수성을 높일 수 있다.

 

 

 

 

 

 

정적 메서드는 지양하자.

 

정적 메서드는 객체지향 패러다임에 반하는 설계이다. 그 이유는 정적메서드를 사용함으로써, 객체지향 프로그래밍이 아니라 클래스지향 프로그래밍을 바뀌기 때문이다.

 

객체지향 프로그래밍을 사용함으로써 얻을 수 있는 이점은 그 "고립성"에 있다. 객체 자신의 과업을 수행하는 데 전념하며 이 과정에 있어 메서드 유효범위는 지역변수에 해당된다. 반면, 정적 메서드를 사용하게 되면 언제나 그 클래스는 전역 변수에 해당된다.

 

 

 

 

 

 

 

 

객체의 이름에서 -er은 피하자.

 

객체의 이름을 지을 때 객체가 무엇을 하는 지보다는 객체가 무엇인 지에 초점을 두자. "페이지 모음기"라는 이름보다는 "책" 이라는 이름이 훨씬 더 낫다는 것이다.

 

 

 

 

 

 

 

 

클래스는 final이나 abstract를 쓰자.

 

 

_final_클래스는 상속을 통해 확장할 수 없는 클래스이다. 즉, 누구도 _@Override_ 데코레이션을 통해서 메서드 기능을 확장할 수 없다.

 

기능을 확장할 수 있으면 코드 작성을 덜 해도 되서 좋지 않을까? 라는 생각이 들 수 있다. 다만, 기능 확장 면에서는 좋을 지 몰라도 부모 클래스에 "구현의 일부"를 집어넣는 셈이기 때문에 상당히 큰 위험을 감수해야 한다.

 

즉, _@Override_를 통해서 부모 클래스의 메서드를 가져와 바꾸게 되면, 해당 부모 클래스의 모든 메서드는 _@Override_된 자식 메서드에 의존하는 셈이 된다. 만약 이러한 상태에서 상위 클래스의 메서드 변경이 생기거나, 적절하지 못하게 _@Override_된다면 원치않는 오류가 발생할 수도 있다.

 

반면, _final_로 상속 자체를 막아버린다면 이러한 문제는 쉽게 해결할 수 있다. 그러면 _final_클래스를 확장하는 것은 아얘 불가능한 것일까? 여기에는 "조합"을 사용하면 된다.

 

final class OnlyValidStatus implements Status {
  private final Status origin;
  public OnlyValidStatus(Status status) {
    this.origin = status;
  }
  @Override
  public int read() throws IOException {
    int code = this.origin.read();
    if (code >= 400) {
      throw new RuntimeException("Unsuccessful HTTP code");
    }
    return code;
  }
}

 

 

초기에 생성자를 통해 _Status_ 인스턴스는 제대로 캡슐화되어 멤버변수로 저장된다. 이렇게 상속 대신 멤버변수로써 상속 대상을 받게 되면, 메서드를 호출하는 방식으로 동작하기 때문에 캡슐화를 깨뜨리지 않는다.

 

 

 

 

_abstract_ 클래스는 그 반대의 경우이다. _abstract_가 붙은 클래스는 그 자체로 사용하는 것이 불가능하다. 무조건 별도의 구현 로직을 붙여주어야 작동할 수 있다는 말이다. 이때, 건드릴 수 있게 허용한 곳에만 넣을 수 있다.(_final_이 아닌 것)

 

abstract class ValidatedHTTPStatus implements Status {
  @Override
  public final int read() throws IOException {
    int code = this.origin.read();
    if (!this.isValid()) {
      throw new RuntimeException("Unsuccessful HTTP code");
    }
    return code;
  }
  protected abstract boolean isValid();
}

 

 

위 코드는 _final_과는 달리, 적절한 부분에 있어서 로직을 주입해주기를 원하고 있다. 그 외에 건드리지 않아야 할 메서드는 final을 통해 _@Override_당하는 것을 막음으로써 방어해 줄 수 있다.

 

 

 

 

 

Reference

• https://tecoble.techcourse.co.kr/post/2020-05-18-inheritance-vs-composition/
• https://www.yegor256.com/2014/06/09/objects-should-be-immutable.html
• https://codingnuri.com/seven-virtues-of-good-object/
• https://velog.io/@conatuseus/Java-Immutable-Object%EB%B6%88%EB%B3%80%EA%B0%9D%EC%B2%B4