That that is is. That that is not is not.

상속보다는 구성을 사용하라.

Inheritance를 사용하는 경우에, class들은 모두 super class의 속성을 가진다. 따라서, super class들의 method를 override하는 경우에, 같은 기능이 들어가야하는 method는 코드가 duplicate될 수 있다.

Java의 경우 reference를 이용하여, attribute로 선언해 놓고, 필요할 때마다 잘 작성된 behavior를 할당하여 사용할 수 있다. 이렇게 하면, 내가 필요한 behavior만 class가 가질 수 있고, 실행시간에 동적으로 attribute를 교체할 수도 있다.

그리고 의미상으로도 한가지 장점이 있다.
예를 들어, thread로 동작하는 dog가 있다고 하자. thread를 구현하는 방법에는 몇가지가 있겠지만, thread를 dog가 상속하는 것은 뭔가 문맥에 맞지 않는다.(dog의 parent가 thread라니..) 따라서 상속보다는 구성을 이용할 수 있다.

Strategy pattern을 적용하여, family of algorithms를 잘 define한 후에 바로 구성을 이용하여 멤버로 사용할 수 있다.

구현이 아닌 인터페이스에 맞춰서 프로그래밍 한다.

실행시간에 change가 가능하다.
ex)
Animal - makeSound()
Dog implements Animal - makeSound() { bark(); }
Cat implements Animal - makeSound() { meow(); }

1) 구현에 맞춰서 프로그래밍하는 경우
Dog dog = new Dog();
dog.bark(); // Dog의 implement된 bark를 그대로 사용한다.

2) 인터페이스에 맞춰서 프로그래밍하는 경우
Animal animal = new Dog();
animal.makeSound();

변수를 선언하는 클래스에서 실제 객체의 형식을 몰라도 된다. 즉, dog object에 대해서 알 필요가 없기 때문에, 2)번의 경우가 되어야함이 더 분명해진다.

이로써 loose coupling에 더 다가갈 수 있다.

만약 Dog를 아주 많이 사용한, Farm이라는 있다고 할 때, Farm에서 Dog를 다 팔고 Cat을 사야하는 경우에 일이 복잡하게 된다. 따라서 low coupling을 구현하기 위해 인터페이스를 사용하는 것이 좋다.

바뀌는 부분을 찾아내어 캡슐화 하라.

application에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리 시킨다.
(Separation of concerns)
-> 코드를 변경하는 과정에서 의도하지 않은 일이 일어나는 것을 줄이고, 시스템의 flexibility를 향상시킬 수 있다.