객체지향 프로그래밍의 기본 원칙과 실천 방법

객체지향 프로그래밍을 하려면 어떤 step을 밟아야할까?

1. 협력, 객체, 클래스: 객체지향의 출발점

객체지향적으로 코드를 짜려 할 때 무엇을 먼저 고민해야 할까요?

많은 개발자들이 다음과 같은 접근 방식을 취합니다:

• ❌ 어떤 클래스가 필요한가?
• ❌ 해당 클래스에 어떤 속성과 메서드가 필요한가?

이는 객체지향적 사고가 아닙니다!

올바른 접근 방식은:

• ✅ 어떤 클래스가 필요한지 고민하기 전에 어떤 객체들이 필요한지 고민하기
• ✅ 객체를 독립적인 존재가 아닌, 서로 협력하는 공동체의 일원으로 바라보기

클래스의 윤곽을 잡기 위해서는 어떤 객체들이 어떤 상태와 행동을 가져야 하는지 결정하고, 이들이 어떻게 협력하는지 고민해야 합니다.

2. 도메인 구조 그려보기

핵심 개념

도메인은 사용자가 프로그램을 사용해 해결하고자 하는 문제의 영역입니다.

도메인 모델은 도메인 내의 개념, 관계, 규칙을 표현하는 모델입니다.

도메인 주도 설계(Domain-Driven Design, DDD)는 도메인 모델을 중심으로 소프트웨어를 설계하는 접근 방식입니다.

객체지향 패러다임의 강점은 요구사항과 프로그램을 객체라는 동일한 관점에서 바라볼 수 있다는 것입니다. 이를 통해 도메인을 구성하는 개념들이 프로그램의 객체와 클래스로 매끄럽게 연결될 수 있습니다.

예: 영화 예매 시스템의 도메인 모델

• 영화는 여러 번 상영될 수 있습니다.
• 상영은 여러 번 예매될 수 있습니다.
• 영화에는 할인정책을 할당하지 않거나 할당하더라도 오직 하나만 할당할 수 있습니다.
• 할인정책이 존재하는 경우에는 하나 이상의 할인 조건이 반드시 존재합니다.
• 할인정책의 종류로는 금액할인정책과 비율할인정책이 있습니다.
• 할인조건의 종류로는 순번조건과 기간조건이 있습니다.

3. 클래스 구현하기

3-1. 클래스의 경계

클래스의 경계를 명확히 구분하는 것이 중요합니다:

1. 외부에서는 객체의 속성에 직접 접근할 수 없도록 차단합니다.
2. 외부로 공개해야 하는 기능은 public 메서드를 통해서만 제공합니다.

이러한 경계의 명확성이 객체의 자율성을 높입니다.

3-2. 객체의 본질

객체는 상태와 행동을 함께 가지는 복합적인 존재입니다.
객체는 스스로 판단하고 행동하는 자율적인 존재입니다.

퍼블릭 인터페이스: 외부에서 접근 가능한 부분
구현(implementation): 오직 내부에서만 접근 가능한 부분

인터페이스와 구현의 분리 원칙

"무엇(What)을 하는지"와 "어떻게(How) 하는지"를 분리하는 것입니다:

• 인터페이스(Interface): "무엇을" 할 수 있는지 정의 - 기능의 명세
• 구현(Implementation): "어떻게" 그 기능을 수행하는지 정의 - 실제 동작 방식

3-3. 구현 은닉과 지식의 양 관리하기

객체지향 설계에서는 두 종류의 프로그래머가 존재합니다:

클라이언트 프로그래머의 목표: 필요한 클래스들을 엮어서 애플리케이션을 빠르고 안정적으로 구축하는 것

클래스 작성자의 목표: 클라이언트 프로그래머에게 필요한 부분만 공개하고 나머지는 꽁꽁 숨겨두는 것 → 구현 은닉

객체의 외부와 내부를 구분하면 클라이언트 프로그래머가 알아야 할 지식의 양이 줄어들고, 클래스 작성자가 자유롭게 구현을 변경할 수 있는 폭이 넓어집니다. 따라서, 클래스를 개발할 때마다 인터페이스와 구현을 깔끔하게 분리하기 위해 노력해야 합니다.

3-4. 협력과 책임 이해하기

객체지향 프로그래밍에서 중요한 개념들:

• 메시지 전송: 객체가 다른 객체와 상호작용할 수 있는 유일한 방법
• 메시지 수신: 다른 객체에게 요청이 도착할 때 해당 객체는 메시지를 수신했다 라고 표현
• 메서드: 수신된 메시지를 처리하기 위한 자신만의 방법
• 다형성: 메시지와 메서드의 구분에서부터 시작하는 개념

Screening이 Movie의 calculateMovieFee 메서드를 호출한다 라고 말했지만, 사실은 Screening이 Movie에게 calculateMovieFee 메시지를 전송한다 라고 말하는 것이 더 적절한 표현입니다.

Screening은 Movie 안에 calculateMovieFee 메서드가 존재하고 있는지조차 알지 못합니다. 단지 Movie가 calculateMovieFee 메시지에 응답할 수 있다고 믿고 메시지를 전송할 뿐입니다. 메시지를 처리하는 방법을 결정하는 것은 Movie 스스로의 문제입니다.

4. 객체 간 협력 설계하기

클래스와 객체를 구현했다면, 이제 협력에 대한 고려가 필요합니다.

4-1. 추상화의 힘

추상 클래스는 상속을 통해 하위 클래스에서 구현하도록 하는 구조입니다. 이는 템플릿 메서드 패턴의 기본이 되는데, 골격은 정의하되 세부 구현은 하위 클래스에 위임하는 방식입니다.

"무엇을 할 것인가"는 상위 수준에서 정의하고, "어떻게 할 것인가"는 하위 클래스에 위임 → 추상화

예시: DiscountPolicy는 할인 여부와 요금 계산에 필요한 전체적인 흐름은 정의하지만, 실제로 요금을 계산하는 부분은 추상 메서드인 getDiscountAmount 메서드에게 위임합니다.

4-2. 코드 의존성과 런타임 의존성의 트레이드 오프

다형성을 활용함으로써 코드의 의존성과 런타임 의존성이 서로 달라질 수 있게 됩니다. 이는 설계의 유연성을 확보하는 대신, 코드를 상세히 이해하고 디버깅하기 어려워지는 트레이드 오프가 발생합니다.

• 지연 바인딩(Late Binding): 다형성이 발생할 때, 메시지와 메서드를 실행 시점에 바인딩
• 정적 바인딩(Early Binding): 컴파일 시점에 실행될 함수를 알고 있는 상태

은탄환은 없습니다. 모든 설계 결정에는 장단점이 따릅니다.

5. 추상화와 유연성

추상화는 고수준 개념입니다. 모든 의존성은 추상화 레벨이 높은 곳으로 흐르게 되는데, 추상화의 힘에 대해 자세히 알아보겠습니다.

5-1. 추상화의 특징과 장점

추상화의 주요 특징:

• 같은 계층에 속하는 클래스들이 공통으로 가질 수 있는 인터페이스를 정의하며, 구현의 일부(추상 클래스인 경우) 또는 전체(자바 인터페이스인 경우)를 자식 클래스가 결정할 수 있도록 결정권을 위임

• 요구사항을 더 높은 수준에서 서술할 수 있게 해줍니다:

  • ❌ "영화의 예매 요금은 '금액 할인 정책'과 '두 개의 순서 조건, 한 개의 기간 조건'을 이용해서 계산할 수 있다"
  • ✅ "영화 예매 요금은 최대 하나의 할인 정책과 다수의 할인 조건을 이용해 계산할 수 있다"

• 설계가 유연해집니다:

  • 특수 케이스 패턴(Special Case Pattern) 또는 널 객체 패턴(Null Object Pattern)을 활용하면 예외 케이스에 대한 처리도 일관적인 협력 방식으로 구조화할 수 있습니다.

널 객체 패턴(Null Object Pattern)

이 패턴은 '없음'이나 '기본값'과 같은 특수 상황을 처리하기 위한 객체를 제공합니다. 클라이언트가 null 체크를 하지 않도록 실제 객체와 동일한 인터페이스를 가진 '아무것도 하지 않는' 객체를 제공합니다.

// 널 객체 패턴의 예: 할인이 없는 상황을 위한 특수 객체
public class NoneDiscountPolicy implements DiscountPolicy {
    @Override
    public int calculateDiscount(int price) {
        return 0; // 할인 없음 (아무것도 하지 않음)
    }
}

5-2. 추상 클래스와 인터페이스의 트레이드 오프

언제 추상 클래스를 인터페이스로 변경해야 할까요?

• 0원에 대한 널 객체 패턴을 적용하기 위해
• 다중 상속이 필요한 경우
• 행위(behavior)만 정의하고 상태(state)나 구현을 공유할 필요가 없는 경우
• 더 느슨한 결합(loose coupling)이 필요한 경우
• 테스트 용이성을 향상시키고자 할 때

인터페이스의 추가적인 장점

1. 기본 구현 제공이 가능 (Java 8 이상)

   public interface Shape {
       double calculateArea();
       
       default String getDescription() {
           return "This shape has area of " + calculateArea();
       }
       
       // 정적 유틸리티 메서드도 제공 가능
       static boolean isLargerThan(Shape s1, Shape s2) {
           return s1.calculateArea() > s2.calculateArea();
       }
   }

2. 기능의 조합이 더 중요한 경우 (합성 over 상속)

   객체지향에서는 "상속보다 합성(Composition over inheritance)"을 권장합니다. 인터페이스 기반 설계는 이러한 원칙을 더 잘 지원합니다. 또한, 상속을 이용하기 위해서는 부모 클래스의 내부 구조를 잘 알고 있어야 하므로 캡슐화를 위배합니다.

   합성과 집합의 차이:

   합성(Composition): 강한 소유 관계

   public class Car {
       // 강한 소유 관계(합성) - Engine은 Car에 종속적
       private final Engine engine;
       
       public Car() {
           // Car가 Engine을 직접 생성 및 관리
           this.engine = new Engine();
       }
       
       // Car가 소멸되면 engine도 함께 소멸됨
   }

   집합(Aggregation): 약한 소유 관계

   public class University {
       // 약한 소유 관계(집합) - Student는 University와 독립적
       private List<Student> students;
       
       public University(List<Student> students) {
           // 이미 존재하는 Student 객체들을 참조
           this.students = students;
       }
       
       // University가 소멸되어도 students 객체들은 계속 존재
   }

결론

객체지향 프로그래밍의 핵심은 객체들의 협력에 있습니다. 객체를 설계할 때는 단순히 데이터와 기능을 캡슐화하는 것에 그치지 않고, 객체들이 어떻게 메시지를 주고받으며 협력하는지를 고려해야 합니다.

추상화를 통해 요구사항을 유연하게 수용할 수 있는 설계를 만들고, 인터페이스와 구현을 분리하여 변경에 유연한 시스템을 구축하는 것이 중요합니다.

상속보다는 합성을, 구체적인 구현보다는 추상화된 인터페이스에 의존하는 설계 원칙을 따른다면, 더 유연하고 확장 가능한 객체지향 시스템을 구축할 수 있을 것입니다.

---

참고 자료

• 조영호, 《오브젝트: 코드로 이해하는 객체지향 설계》
• Martin Fowler, 《엔터프라이즈 애플리케이션 아키텍처 패턴》
• Eric Evans, 《도메인 주도 설계》