[OOP] 피터 코드의 상속 규칙

 

 

객체지향 소프트웨어 개발의 대가

피터 코드(Peter Coad)

 

피터 코드는 상속의 오용을 막기 위해

5가지 상속 규칙을 내세웠다.

 

 

1. 자식클래스와 부모클래스는 '역할 수행' 관계가 아니어야 한다.

 

상속은 '추상화'를 구현한다. 추상화란 '공통된 특징'을 파악해 '인식의 대상'으로 삼는 행위이다. 

 

달달하고 상큼한 것을 먹고 싶을 때, 우리는 '과일' 먹고 싶다라고 말한다. 바나나, 딸기, 수박, 파인애플 등등 '과일'이라는 단어가 없다면 무척이나 표현이 힘들어진다. 그러므로 추상화란 어떤 집단이나 집합의 '간판'과 같다. 그리고 객체지향설계에서 추상화는 상속으로 구현된다.

 

그런데 가끔 상속을 역할과 혼동하는 경우가 생긴다. 민수는 출근하면 회사원이다. 퇴근하면 운전자가 된다. 주말에는 아르바이트생이 된다.

 

 

 

그렇다면 회사원, 운전자, 아르바이트생을 통칭하는 '간판'이 되는 단어로 민수가 될 수 있을까? 세 가지는 민수로 추상화 될 수 없다. 민수는 단지 특정 시간에 따라 해당 역할을 수행했을 뿐이다. 회사원, 운전자, 아르바이트생을 통칭하는 추상적 단어는 '직업'이 적절하다.

 

 

 

 

 

그러므로 회사원, 운전자, 아르바이트생은 직업으로 추상화되고 상속으로 구현될 수 있다. 역할을 표현하는 좋은 방법은 일반화 관계가 아닌 연관관계로 표현하는 것이다. 

 

 

2. 한 클래스의 인스터스는 다른 서브 클래스의 객체로 변환할 필요가 절대 없어야 한다. 

 

[OOP] 일반화(추상화)

 

[OOP] 특수화

 

 

지난 포스팅에서 일반화와 특수화를 다룬 적이 있다. 

 

우리가 상속이나 인터페이스를 통해, 일반화를 구현하는 이유는 결합도를 낮추기 위함이다. 그러나 그 안에는 '다형성'이 존재한다. 일반화되어 표현되었지만 결국 다양한 형태로 표현이 가능하다. 즉 회사원, 운전자, 아르바이트생은 '직업'으로 일반화 되었지만 제각기 특수하다. 그러므로 회사원은 아르바이트생으로 운전자는 회사원으로 아르바이트생은 운전자로 변환되어서는 안된다.

 

3. 자식 클래스가 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행해야 한다. 

 

이 규칙이 정확이 무엇을 의미하는지는 모르겠다. 개인적인 생각으로는 달달함이 과일의 특성인데 새로 추가 된 A라는 과일이 쓴 맛이 나면 안 된다는 의미인거 같다. 

 

4. 단지 일부 기능을 재사용할 목적을 지는 유틸리티 역할을 수행하는 클래스를 상속하지 않는다. 

 

단순 기능 재사용이 목적인 클래스는 공통된 특성을 파악하여 인식의 대상으로 삼는 추상화와 맞지 않는다. 

 

5. 자식클래스가 역할, 트랜잭션, 디바이스 등을 특수화해야 한다. 

 

추상화된 개체가 부모 클래스이다. 그럼 특수화된 개체는 자식클래스가 되어야 한다. 자식 클래스가 구체적인 연관관계를 맺음으로써 특수화되어야 한다.

 

 

 

회사원은 회사와 관계를 맺고 운전자는 차와 관계를 맺고 아르바이트생은 편의점과 관계를 맺어야 한다. 직업이 회사와 관계를 맺거나 차와 관계를 맺거나 편의점과 관계를 맺으면 추상화라 부를 수 없다.  추상화가  목적인 부모클래스가 구체적인 무언가와 연관관계를 맺어서는 안된다.

 

 

---

 

참고자료

JAVA 객체지향 디자인 패턴 : 네이버 도서