객체지향 해석(2) - 요구사항과 계약

응큼한포도·2025년 6월 21일

객체지향 해석

목록 보기
2/7

요구사항은 돈이다

개인적으로 소프트웨어에서 중요하다고 생각하는건 돈을 버는 것이라고 생각한다.
사용자든 고객이든 만족시켜서 돈을 버는것이 중요하므로 소프트웨어에서 가장 중요한 건 요구사항을 이끌어내고 만족시키는 것이다.

객체지향과 요구사항

요구사항과 객체지향은 아주 근접해있다. 사실 소프트웨어의 거의 모든 것이 요구사항을 잘 만족시키기 위한 것이다.

객체지향이든 TDD든 DDD든 그에 따른 MSA든 모두 요구사항을 명확하게 이끌어내지 못하면 아무 소용이 없다. 반대로 요구사항을 잘 이끌어내고 철저한 분업화에 대해서 이해하면 객체지향과 TDD, DDD 모두 요구사항을 위한 것임을 깨닮게 된다.

요구사항과 계약

요구사항을 잘 이끌어내는 프로젝트 설계에 대해선 말하지 않겠다. TDD와 DDD 또한 나중에 서술하겠다. 지금은 잘 설계된 현실의 요구사항을 어떻게 소프트웨어로 구현하는지에 대해서만 서술하겠다.

나는 이 시리즈에서 요구사항과 요구사항을 만족시키기 위한 방법, 표현, 약속등을 계약이라고 지정하겠다.

잘 설계된 요구사항은 제약과 해야될 행동 등이 정의된다.

예를 들어서 스마트폰의 디스플레이는 다음과 같은 요구사항이 필요하다.

  1. 전원이 켜진다.
  2. 밝기를 조절할 수 있다.

이는 요구사항이자, 계약 사항, 제약 조건이므로 우리가 소프트웨어로 이를 구현할 때 꼭 이뤄야하는 계약이라고 볼 수 있다.

따라서 이런 계약을 소프트웨어로 표현하고 강제하는 것이 인터페이스이다.

interface Display {
    void turnOn(); // 전원을 켠다.
    void setBrightness(int level); // 밝기를 조절한다.
    Resolution getResolution(); // 해상도 정보를 제공한다.
}

위의 예를 들면 디스플레이의 계약은 위와 같이 소프트웨어에서 명시 될 수 있다.

따라서, 이렇게 정의된 계약을 코드로써 보증하고 강제하는 수단이 바로 인터페이스다.

개발의 과정

운영적인 것을 제외하고 기능구현만을 생각해보면 개발의 과정은 다음과 같다.

  1. 고객과 회의를 통해 요구사항을 듣는다.
  2. 지속적인 회의를 통해 요구사항을 구체화한다.
  3. 계약서를 작성한다.
  4. 프로젝트 설계를 실행한다.
  5. 각 부분에 대한 계약을 코드로 옮긴 인터페이스를 작성한다.
  6. 구현 클래스는 인터페이스라는 계약을 반드시 준수하며 코드를 완성한다.

프로젝트의 설계가 매우 중요한데 인터페이스를 이용하는 건 이런 설계의 연장선상이라고 볼 수 있다. 따라서 인터페이스는 매우 중요하다.

다시 요구사항과 객체지향

그렇다면 이 모든 것이 객체지향과 무슨 관련이 있는가?

객체지향의 본질이 '분업'이라면, '요구사항'은 바로 그 '분업의 대상'이자 '분업의 기준'이 된다.

우리는 요구사항을 보고 무엇을 나눌지 결정한다. 요구사항을 분석하여 서로 관련 있는 것끼리 뭉친다. 이렇게 요구사항을 기준으로 시스템을 적절하게 나누고 뭉쳐서, 각자에게 명확한 책임을 부여하는 설계 과정 그 자체가 바로 객체지향적 접근법이다.

그리고 이렇게 분업화된 각 객체들이 서로 약속(계약)을 잘 지키도록 강제하는 도구가 바로 인터페이스인 것이다.

0개의 댓글