[디자인패턴] 헤드퍼스트 디자인패턴 Chap.1

상속만 사용한 경우 생길 수 있는 문제

• 서브 클래스에서 코드 중복
• 실행 시에 특징 바꾸기 어려움
• 모든 클래스의 동작 알기 어려움
• 슈퍼 클래스에서 코드 변경시 원치 않은 서브 클래스에도 영향 준다.

=> 인터페이스의 등장

 

다만 인터페이스를 사용하면 인터페이스를 상속하는 모든 서브 클래스들에서 코드를 구현해야함.

ex) A,B,C,D,E,F 6개의 서브 클래스가 있을 때 x 라는 인터페이스를 만들어 동작을 구현했는데 이를 동일하게 수정하고 싶으면, A~F까지 모든 서브 클래스의 내용을 수정해야함.

 

즉 코드 재사용이 되지 않는 문제점이 있다는 것,

한가지 동작을 바꿀 때 마다 그 동작이 정의되어 있는 서브 클래스들을 전부 찾아서 코드를 고쳐야 하고, 그 과정에서 버그가 생길 수 있음 

 

소프트웨어 개발 불변의 진리: 아무리 디자인을 잘한 애플리케이션이라도 시간이 지남에 따라 변화하고 성장하지 않으면 죽는다.

 

디자인 원칙 : 애플리케이션에서 달라지는 부분과 달라지지 않는 부분을 분리할 것 

 

이를 지키기 위해 캡슐화를 한다. 어디에?? 달라지는 부분을 캡슐화한다 => 코드 변경을 해도 나머지 코드에 영향을 주지 않는다.

 

디자인 원칙 : 구현보다는 인터페이스에 맞춰서 프로그래밍한다.

 

행동 인터페이스의 내용을 서브 클래스에서 구현하는 것이 아닌 특정 행동 클래스들을 만들어 거기에 구현

ex) A,B,C,D,E,F 6개의 서브 클래스가 있을 때 move 라는 행동 인터페이스를 만들면, 행동 클래스로 withCar, withShip, withTrain 같은 클래스를 만들어 구현. 

 

인터페이스에 맞춰서 프로그래밍 한다 == 상위 형식에 맞춰서 프로그래밍 한다

 

// 구체적인 구현 필요
Dog dog = new Dog();
dog.bark();

// 다형성 활용하여 Animal의 레퍼런스 사용
Animal animal = new Dog();
animal.makeSound();

// 구현된 객체 대입
a = getAnimal();
a.makeSound();

 

인터페이스에 맞춰서 프로그래밍함으로 얻는 장점으로

상속을 사용할 때 발생하는 부담은 없애고 재사용의 장점은 그대로 누릴 수 있게 된다.

 

디자인 원칙 : 상속보다는 구성을 활용한다

두 클래스를 합칠 때 A는 B이다 보다 A에는 B가 있다(composition)이 더 나을 수 있음