객체지향 핵심과 SOLID·설계 계약
객체지향의 네 특성과 오버로딩·오버라이딩, SOLID 원칙의 적용 목적을 정리한다.
객체지향의 기본 요소
- 객체(Object): 식별 가능한 상태와 행동을 가진 실행 단위
- 클래스(Class): 공통 속성과 연산을 정의한 설계
- 인스턴스(Instance): 클래스로부터 생성된 실제 객체
- 속성(Attribute): 객체의 상태를 나타내는 데이터
- 메서드(Method): 객체가 수행하는 구체적 연산
- 메시지(Message): 다른 객체에 책임 수행을 요청하는 상호작용
객체지향 설계는 데이터만 묶는 것이 아니라 책임과 협력을 분명히 하는 것이 중요하다.
객체지향의 네 특성
| 특성 | 핵심 의미 |
|---|---|
| 추상화 | 필요한 본질만 모델링하고 불필요한 세부를 감춤 |
| 캡슐화 | 상태와 행동을 하나의 경계에 묶고 올바른 변경 경로 제공 |
| 상속 | 상위 클래스의 특성과 동작을 하위 클래스가 물려받아 확장 |
| 다형성 | 같은 메시지·인터페이스에 객체별로 다른 동작을 수행 |
정보 은닉은 외부가 알 필요 없는 구현 결정을 감추는 설계 원리다. 캡슐화는 이를 구현하는 데 도움을 주지만 필드를 private으로 선언하는 것만으로 좋은 설계가 완성되는 것은 아니다.
오버로딩과 오버라이딩
| 구분 | 오버로딩(Overloading) | 오버라이딩(Overriding) |
|---|---|---|
| 의미 | 같은 이름의 연산을 매개변수 형태에 따라 여러 개 정의 | 하위 클래스가 상위 클래스의 메서드를 재정의 |
| 상속 필요 | 필수 아님 | 일반적으로 필요 |
| 선택 기준 | 호출 시그니처 | 실제 객체의 재정의 메서드 |
| 관련 다형성 | 정적·컴파일 시점 다형성 | 동적·실행 시점 다형성 |
반환형만 다르게 한 동일 매개변수 메서드는 일반적으로 오버로딩으로 구분되지 않는다.
상속과 합성
- 상속: “~은 ~이다(is-a)”라는 일반화 관계와 치환 가능성이 분명할 때 적합
- 합성: 다른 객체를 구성요소로 포함하고 역할을 위임하는 “가지고 있다(has-a)” 관계
상속은 강한 결합을 만들 수 있으므로 단순 코드 재사용만을 목적으로 남용하지 않는다. 실행 중 역할 교체와 독립 변경이 중요하면 합성·위임이 유리할 수 있다.
SOLID 원칙
객체지향·SOLID 요약도
SRP: 단일 책임 원칙
클래스·모듈이 하나의 응집된 책임과 변경 이유를 갖게 한다. 메서드 수가 하나여야 한다는 뜻은 아니다.
OCP: 개방-폐쇄 원칙
확장에는 열려 있고 기존 코드의 불필요한 수정에는 닫히도록 안정된 추상화 지점을 둔다. 어떤 변경에도 코드를 절대 수정하지 않는다는 뜻은 아니다.
LSP: 리스코프 치환 원칙
하위 타입 객체가 상위 타입 객체를 대신해도 프로그램의 기대되는 성질이 깨지지 않아야 한다. 문법적으로 상속했다는 사실만으로 자동 충족되지 않는다.
ISP: 인터페이스 분리 원칙
클라이언트가 사용하지 않는 기능에 의존하지 않도록 목적별로 인터페이스를 분리한다. 무조건 메서드 하나짜리 인터페이스를 만들라는 뜻은 아니다.
DIP: 의존성 역전 원칙
상위 정책과 하위 구현이 모두 구체 구현보다 추상화에 의존하도록 한다. 의존성 주입(DI)은 이를 구현하는 한 방법이지 원칙 자체와 동일하지 않다.
인터페이스 계약의 기본
객체 간 인터페이스에는 입력, 결과, 오류 조건, 상태 변경을 명확히 한다. 이 수준의 계약은 객체를 안전하게 치환하고 시험하는 데 도움을 준다. 사전·사후·불변 조건의 기본 정의와 책임을 구분하되, 계약 상속의 형식 규칙과 정형 증명은 다루지 않는다.