OOD(객체지향 개발)의 원칙

나쁜 설계의 냄새

• 경직성 : 뭔가 하나를 바꾸려할때 반드시 다른것도 바꿔야한다.
• 부서지기 쉬움 : 한부분을 바꾸면 전혀 상관없는 다른부분이 동작을 멈춘다.
• 부동성 : 시스템을 여러 컴포넌트로 분해해서 다른 시스템에 재사용하기 힘들다.
• 끈끈함 : 편집 - 컴파일 - 테스트 순환을 한번 도는 시간이 엄청나게 길다.
• 쓸데없이 복잡함 : 언젠가는 굉장히 유용할지도 모른다고 생각하고 괜히 머리 굴려서 짠코드가 많다.
• 필요 없는 반복 : 코드를 작성한 프로그래머 이름이 마치 '복사'와 '붙여넣기'같다.
• 불투명함 : 코드를 만든 의도에 대한 설명을 볼 때 그 설명에 '표현이 꼬인다.'라는 말이 잘 어울린다.

1. The Single Responsibility Principle - SRP

어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.

2. The Open-Closed Principle - OCP

소프트웨어 엔티티(클래스, 모듈,함수 등등)는 확장에 대해서는 개방되어야 하지만, 변경에 대해서는 폐쇄되어야 한다.
혹자는 실제 코드를 작성하기전에 단위 테스트를 먼저 작성함으로써 OCP를 달성하기도 한단다.( 로버트 C.마틴 )
클래스를 변경하지 않고도 어떤 클래스의 환경을 변경할 수 있어야 한다.

3. Liskov Substitution Principle - LSP

서브타입은 언제나 자신의 기반 타입(base type)으로 교체할 수 있어야 한다.->다운캐스트가 필요없어야 한다.
유도된 메소드를 퇴화시키는것, 즉 아무것도 안하는 메소드로 구현하는것도 LSP를 어긴다.
기반 클래스의 사용자는 그 기반 클래스에서 유도된 클래스에 대해 아무것도 알 필요가 없어야 한다.

4. Dependency Inversion Principle - DIP

고차원의 모듈은 저차원 모듈에 의존하면 안 된다. 이 두 모듈 모두 다른 추상화된 것에 의존해야 한다.
추상화된 것은 구체적인 것에 의존하면 안 된다. 구체적인 것이 추상화된 것에 의존해야 한다.
자주 변경하는 컨크리트 클래스 대신 인터페이스나 추상 클래스에 의존하라.

5. Interface Segregation Principle - ISP

클라이언트는 자신이 사용하지 않는 메소드에 의존 관계를 맺으면 안 된다.
어떤 객체의 사용자에게 그 사용자한테 필요한 메소드만 있는 인터페이스를 제공하라.

출처 : http://blog.naver.com/jeddli/40016831716