# 상속과 컴포지션

## 상속
- 상속(Inheritance)은 객체 지향 4가지 특징중 하나로서 클래스 기반의 프로그래밍에서 가장 먼저 배우는 개념일 것이다.
- 클래스 상속을 통해 자식 클래스는 부모 클래스의 자원을 물려 받게 되며, 부모 클래스와 다른 부분만 추가하거나 재정의함으로써 기존 코드를 쉽게 확장할 수 있다.
- 상속 관계를 is-a 관계라도 표현하기도 한다


class Mobile {
	// ...
}

class Apple extends Mobile {
	// ...
}

**상속은 장점이 많지만 단점 역시 존재한다**

- **강한 결합** : 상속은 부모 클래스와 자식 클래스 사이에 강한 결합을 만든다. 이로 인해 부모 클래스의 변경이 자식 클래스에 영향을 미칠 수 있으며, 유지 보수와 확장이 어려워질 수 있다.
- 강한 결합이란 두 개 이상의 클래스나 컴포넌트가 서로 긴밀하게 연관되어 있는 것을 의미
- 코드의 재사용성 제한 : 자바에서 다중 상속을 지원하지 않기 때문에 자식 클래스는 단일 부모 클래스로부터만 상속받을 수 있다. 이로 인해 코드의 재사용성이 제한될 수 있다.
- 상속 깊이 증가문제 : 클래스 계층 구조가 복잡해질수록 상속 깊이가 깊어지고, 코드의 가독성과 이해도가 떨어진다. 이 경우, 코드를 이해하고 디버깅하는 데 어려움이 발생할 수 있다.
- 캡슐화 위반 : 상속은 부모 클래스의 구현 세부사항이 자식 클래스로 노출되기 쉽다. 이로 인해 캡슐화 원칙이 약화되며, 코드의 안정성과 유지 보수성이 저하될 수 있다.
- 상속 오용 : 개발자들이 코드의 재사용을 목적으로 상속을 남용할 수 있다. 이로 인해 불필요한 클래스 계층이 생성되고, 코드의 복잡성이 증가한다. 상속을 사용할 때는 신중하게 판단해야 한다.
- 상속 사용 시에는 부모 클래스의 내부 구현에 대해 상세하게 알아야 한다
- 유연함 문제 : 상속 관계는 컴파일 타임에 결정되고 고정되기 때문에 코드를 실행하는 도중에 변경할 수 없다.

---

## 컴포지션

- 필드로 클래스의 인스턴스를 참조하게 만드는 설계 방법
- 합성의 방식을 사용
- 각 구성 요소 클래스는 독립적으로 변경되고 테스트될 수 있다.
- 클래스 간의 결합도를 낮춰 유연한 설계를 가능하게 한다.
- 느슨한 결합
- 상속의 한계를 극복하여 다중 상속과 비슷한 효과를 얻을 수 있다.
- 컴포지션 관계를 has-a 관계라도 표현하기도 한다
> Sample code
> ```java
> class Car {
> Engine engine; // 필드로 Engine 클래스 변수를 갖는다(has)
>
> Car(Engine engine) {
> this.engine = engine; // 생성자 초기화 할때 클래스 필드의 값을 정하게 됨
> }
>
> void drive() {
> System.out.printf("%s엔진으로 드라이브~\n", engine.EngineType);
> }
>
> void breaks() {
> System.out.printf("%s엔진으로 브레이크~\n", engine.EngineType);
> }
> }
>
> class Engine {
> String EngineType; // 디젤, 가솔린, 전기
>
> Engine(String type) {
> EngineType = type;
> }
> }
> ```

**컴포지션은 상속의 단점을 보완해주지만 역시 단점을 가지고 있다.**

- 중복 코드: 컴포지션을 사용하면 각 구성 요소 클래스의 메소드를 호출하는 코드를 여러 클래스에서 중복해서 작성해야 할 수 있다. 상속을 사용할 경우 이러한 중복 코드를 최소화할 수 있다.
- 인터페이스 구현: 구성 요소 클래스의 메소드를 외부로 노출하려면, 상위 클래스에 인터페이스를 구현해야 할 수 있다. 이 경우, 상위 클래스에 구성 요소 클래스의 메소드와 매핑되는 메소드를 정의해야 하며, 이로 인해 코드가 복잡해질 수 있다.
- 간접성: 컴포지션은 간접적인 방식으로 클래스 간의 관계를 구현한다. 이로 인해 코드를 이해하고 디버깅하는 데 어려움이 있을 수 있다.
- 성능: 컴포지션은 상속에 비해 약간의 성능 저하가 발생할 수 있다. 구성 요소 클래스의 메소드를 호출할 때, 상위 클래스를 통해 간접적으로 호출되기 때문이다. 하지만 대부분의 경우 이러한 성능 차이는 미미하며, 설계의 유연성과 유지 보수성을 향상시키는 데 초점을 맞추는 것이 더 중요하다.

---

## 상속 vs 컴포지션

- 둘 다 재사용성을 위한 방법
- 상속으로 해결할 수 있는 많은 문제를 컴포지션으로도 가능
- 그 반대도 가능
- 순전히 기술적인 관점
- 역사적으로 사람들의 선호는 왔다갔다 한다
- 초창기에는 상속을 과도하게 선호
- 그 후 무조건 컴포지션이 답이라는 잘못된 조언을 많이 따랐음 (현재진행형)
- OO에서 가장 큰 결정사항 중 하나 : 상속 vs 컴포지션 중 하나를 고르는 것
- 가이드라인
- 실생활에서 개채들끼리의 관계를 기준으로 선택
- has-a 관계 : 컴포지션
- is-a 관계 : 상속
- 물론 훌륭한 프로그래머들은 필요에 따라 이 규칙을 어긴다.

---

### 상속과 컴포지션 선택 시 고려할 사항

- 기계상의 차이 때문에 하나를 골라야 할 때 (메모리 상의 차이는 용량보다는 실행 성능에 영향을 미친다)
- 상속 : 개체 생성 시, **메모리가 하나의 덩어리**다. 개체가 한 번에 캐시 메모리에 들어갈 가능성이 높다.
- 컴포지션 : 개체 생성 시 **메모리가 여러 덩어리**다. 개체 내 부품 수 만큼 캐시 메모리로 로딩할 가능성이 높다.
- 즉, 좋은 성능이 필요하다면 상속을 고르는 것이 더 좋다.
- 용도 때문에 상속을 고를 수밖에 없을 때
- 명령 하나로 여러 형의 개체를 한번에 처리하고 싶을 때 (다형성)
- 관리의 효율성을 고려할 때
- 일반적으로 메서드 중복을 피하기 위해서는 상속을 사용하는게 좋다. 하지만 깊은 상속 관계일 경우 (부모 자식간의 단계가 많을 경우) 상위 부모개체 클래스의 코드를 수정할 경우 하위 모든 자식 클래스에서 문제가 발생하지 않는지 확인해야 하는 불편함이 있다. 해당 문제는 컴포지션도 문제가 있긴 하지만 상속보다는 덜하다.
- 인터페이스나 다형성이 이러한 문제를 조금 완화시켜준다
- 그 외 일반적인 상황
- has-a 와 is-a 관계에 충실하자

> **강한 결합 vs 느슨한 결합**
> - 강한 결합(Strong Coupling)
> - 장점
> - 간단한 시스템에서는 강한 결합이 구현이 빠르고 쉬울 수 있다.
> - 단점
> - 한 클래스의 변경이 다른 클래스에 영향을 미쳐 유지 관리와 확장이 어렵다.
> - 코드의 재사용성이 낮아진다. 강한 결합된 클래스는 다른 시스템에서 사용하기 어려울 수 있다.
> - 오류 수정 및 기능 추가에 대한 비용이 증가하며, 시스템의 안정성이 낮아질 수 있다.
> - 느슨한 결합(Loose Coupling)
> - 장점
> - 클래스 간의 연결이 최소화되어 변경에 더 유연하게 대응할 수 있다.
> - 코드의 재사용성이 높아진다. 느슨한 결합된 클래스는 다른 시스템에서 사용하기 쉽다.
> - 유지 관리와 확장성이 향상된다. 한 클래스의 변경이 다른 클래스에 미치는 영향이 적어진다.
> - 시스템의 안정성이 높아진다. 오류 수정 및 기능 추가에 대한 비용이 감소한다.
> - 단점
> - 초기 설계 및 구현에 시간이 더 소요될 수 있다.
> - 인터페이스, 추상 클래스, 디자인 패턴 등을 사용하여 느슨한 결합을 구현하기 위해서는 더 많은 계획과 구조화가 필요하다.

---

###### tags: `과외(하희영)`