노트

http://talkingaboutme.tistory.com/176

1. 단일 책임의 원칙(SRP : Single Responsibility Principle)
- 한 객체는 하나의 책임을 져야 한다는 원칙으로 높은 응집도와 낮은 결합도를 기본으로 하고 있다.

2. 의존 관계 역전의 법칙(DIP : Dependency Inversion Principle)
- 클라이언트는 클래스가 아닌 추상화(인터페이스, 추상클래스) 레이어에 의존해야 한다는 원칙으로, 확장 이슈가 있는 부분은 추상화를 해야 된다는 내용이다.

3. 인터페이스 분리의 원칙(ISP : Interface SegreGation Principle)
- 클라이언트에 특화된 여러개의 인터페이스가 하나의 범용 인터페이스보다 났다.

4. 리스코프 대체 원칙(LSP : Liskov Substitution Principle)
- 상위 클래스는 파생클래스로 대체 가능해야 되는 원칙으로, 기반 클래스의 기능은 파생 클래스가 포함을 해야 된다는 내용이다. 따라서 파생클래스는 상위 클래스보다 더 많은 기능을 제공 하게 되어있다.

5. 개방 폐쇄 원칙(Open-Closed Principle)
-확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다는 원칙으로 기존의 클래스에 수정하지 말고, 상속 또는 구현으로 확장을 해야 된다는 내용이다.

출처 : http://www.sjava.net/13

ricksGuitars-encapsulation.zip

설계가 잘 되었는지 확인하고 살펴보는 단계입니다.

이제 "3) 유지보수와 재사용이 쉬운 디자인을 위해 노력하세요" 에대한 단계입니다.

새로운 기능의 추가를 원할 때 더 쉽게 확장할수 있게하고, 프로그램의 일부를 재사용이 쉽도록 하는 과정입니다.

Guitar의 내용을 간단한 Guitar객체와 GuitarSpec객체로 분리하여 구조화했지만 향후 유지보수를 위해 이과정을 거쳐야 합니다.

GuitarSpec에 기타 줄의 갯수에 대한 속성을 추가해달라는 요구가 왔을 경우를 생각해 봅시다.

Guitar클래스의 생성자의 매개변수를 추가해 주어야 하며, Inventory클래스의 search()메소드에 속성비교를 하나 추가해야 합니다.

GuitarSpec이 변경되었을 뿐인데, Guitar클래스와 Inventory클래스까지 변경해야 된다는 것입니다.

Guitar클래스의 생성자에서 GuitarSpec의 생성역할까지 맡았기 때문입니다.

또한, Inventory의 search()함수는 검색기능뿐만아니라, 스펙을 비교하는 기능까지 수행하고 있기 때문입니다.

해결방법은 다음과 같습니다.

1. Guitar클래스의 생성자에서 GuitarSpec의 속성을 생성자로부터 캡슐화하여 분리해야 합니다.

FindGuitarTester.java

Guitar.java

이제 GuitarSpec클래스에 새로운 속성이 추가되어도, Guitar클래스에는 변경될 사항이 없습니다.

2. search()메소드를 수정하여 GuitarSpec클래스에 두개의 GuitarSpec객체를 비교하도록 위임 합니다.

Inventory.java

GuitarSpec.java

이처럼 search()함수에서는 검색기능만 수행할 뿐, GuitarSpec객체의 비교는 GuitarSpec클래스의 maches()함수에 위임한것을 확인할 수 있습니다.

이제, 다른 속성이 추가되더라도, GuitarSpec클래스의 maches()함수에 조건문 하나만 추가되면 됩니다.

ricksGuitars-final.zip