객체지향 프로그래밍(OOP) 핵심 개념 정리

1. 캡슐화(Encapsulation)

• 정의: 불안정한 부분과 안정적인 부분을 분리하여 변경의 영향을 통제하는 기법
• 목적: 변경에 의한 파급 효과를 최소화
• 핵심 원칙:
  • 변할 수 있는 요소(속성 타입, 할인 정책 등)를 감추기
  • 내부 구현 변경이 외부 객체에 영향을 미치면 캡슐화 위반
• 설계 지침: 변화하는 개념을 식별하고 이를 적극적으로 캡슐화

2. 응집도(Cohesion)와 결합도(Coupling)

• 좋은 설계의 조건: 높은 응집도, 낮은 결합도
• 응집도:
  • 한 모듈 내 요소들이 얼마나 밀접하게 관련되어 있는지 나타냄
  • 낮은 응집도: 서로 연관 없는 기능이 하나의 클래스에 뭉쳐 있는 상태
• 결합도:
  • 모듈 간 상호 의존성의 정도
  • 인터페이스에 의존하도록 설계하면 결합도를 낮출 수 있음
• 영향 요소: 캡슐화의 정도가 응집도와 결합도에 직접적 영향을 미침

3. 역할(Role)과 책임(Responsibility)

• 역할: 대체 가능한 책임의 집합
• 설계 접근법: 역할을 먼저 고민하고, 그 역할을 수행할 객체를 선택
• 책임 주도 설계(RDD):
  • 협력에 필요한 메시지를 먼저 정의한 후 이를 처리할 객체 결정
  • 잘못된 접근: "이 클래스가 필요한데, 무엇을 해야 하지?"
  • 올바른 접근: "이 메시지를 전송해야 하는데, 누구에게 보내야 하지?"

4. 객체 설계 원칙

• 책임 중심:
  • 큰 책임을 작은 단위로 재귀적으로 분할하여 객체에 할당
  • 객체가 의미 있는 메서드를 가져야 함
• 행동 중심 설계:
  • 객체 간 협력 관계(메시지 전달)를 중심으로 설계
  • 데이터보다 행동(메시지)을 먼저 고려
• 설계 순서:
  • 협력 관계 구축 → 인터페이스 설계 → 구현

5. 정보 전문가 패턴(Information Expert)

• 원칙: 책임을 수행할 정보 전문가를 찾아 메시지 전송
• 핵심 개념:
  • 객체는 자신이 소유한 정보와 관련된 작업을 수행
  • 정보를 직접 저장하지 않아도 다른 객체에게 요청 가능
  • 중요한 것은 정보 사용에 대한 논리적 권한 여부

6. 캡슐화 위반 사례

• Getter/Setter 남용:
  • 무분별한 사용은 캡슐화 원칙 위반
  • 내부 데이터를 그대로 노출하는 것은 진정한 캡슐화가 아님
• 올바른 캡슐화:
  • 객체의 상태를 보호하면서 필요한 동작만 외부에 제공
  • 협력을 고려한 설계로 불필요한 접근자 메서드 최소화

7. 데이터 중심 설계의 문제점

• 높은 결합도:
  • 제어 로직이 특정 객체에 집중되며 다수의 데이터 객체에 강하게 결합
  • 데이터 객체 변경 시 제어 객체도 함께 변경 필요
• 낮은 응집도:
  • 하나의 요구사항 변경을 위해 여러 모듈 수정 필요
  • 서로 다른 변경 이유를 가진 코드가 한 모듈에 섞여 있음

8. 단일 책임 원칙(SRP)

• 정의: "클래스는 단 하나의 변경 이유만 가져야 한다"
• 목적:
  • 클래스가 하나의 책임만 가지면 변경은 해당 책임과 관련된 이유로만 발생
  • 불필요한 영향을 최소화

9. 객체의 자기 책임

• 객체의 본질: 단순한 데이터 제공자가 아님
• 중요성:
  • 객체 내부 데이터보다 협력에 참여하면서 수행할 책임이 중요
  • 객체는 자신의 데이터를 스스로 책임져야 함
• 설계 질문:
  • 이 객체가 포함해야 할 데이터는 무엇인가?
  • 이 객체가 데이터에 대해 수행해야 할 오퍼레이션은 무엇인가?

10. 다형성(Polymorphism)

• 활용: if-else나 switch-case 대신 다형성 활용
• 이점: 유연한 구조 형성, 확장성 향상

11. 메시지와 메서드

• 구분:
  • 메시지: 객체에 대한 요청
  • 메서드: 요청을 처리하는 실행 코드
• 다형성: 메시지는 다형성을 통해 다양한 메서드와 바인딩 가능
• 오퍼레이션과 시그니처:
  • 오퍼레이션: 퍼블릭 인터페이스에 포함된 메시지
  • 메서드: 오퍼레이션의 구현
  • 시그니처: 메서드의 이름과 파라미터 목록

12. 디미터 법칙(Law of Demeter)

• 원칙:
  • "낯선 자에게 말하지 마라"
  • "오직 인접한 이웃하고만 말하라"
  • "오직 하나의 도트(.)만 사용하라"
• 목적: 객체의 내부 구조에 강하게 결합되지 않도록 협력 경로 제한
• 메시지 전송 대상 제한:
  • this 객체
  • 메서드의 매개변수
  • this의 속성
  • this의 속성인 컬렉션의 요소
  • 메서드 내에서 생성된 지역 객체

13. "묻지 말고 시켜라"(Tell, Don't Ask)

• 원칙: 데이터를 꺼내서 처리하지 말고, 객체가 직접 처리하도록 명령
• 효과: 정보 전문가 패턴이 자연스럽게 적용됨

14. 의도를 드러내는 인터페이스

• 메서드 명명 원칙:
  • "어떻게"가 아닌 "무엇"과 "목적"을 드러내는 이름 사용
• 효과: 다양한 타입의 객체가 참여할 수 있는 유연한 협력 가능

15. 응집도 개선 지침

• 응집도 낮은 클래스의 특징:
  • 변경의 이유가 하나 이상인 클래스
  • 객체 생성 시 일부 속성만 초기화되는 클래스
  • 메서드들이 특정 속성만 사용하는 그룹으로 나뉘는 클래스
• 응집도 높은 클래스의 특징:
  • 객체 생성 시 모든 속성이 함께 초기화됨
  • 모든 메서드가 객체의 모든 속성을 사용함