UML, 실전에서는 이것만 쓴다 Java 프로그래머를 위한 UML

잘못 관리한 의존관계가 많은 나쁜냄새의 원인이라고 한다.. 어떤 모양의 의존관계 구조가 바람직한것인지에 대한 원칙 몇가지를 정리해둔 것이 기억해둘만 하다.. 요약해 정리해보자..
클래스를 작성할때 꼭 되새겨 보자.. 명심, 명심, 명심..

단 하나의 책임 원칙
(The Single Responsibility Principle - SPR)
어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다. 너무 많은 것을 아는 클래스를 피하자.

개발-폐쇄 원칙
(The Open-Closed Principle - OCP)
소프트웨어 엔티티 (클래스, 모듈, 함수 등등)는 확장에 대해서는 개방되어야 하지만, 변경에 대해서는 폐쇄되어야 한다. 클래스를 변경하지 않고도 어떤 클래스의 환경을 변경할 수 있어야 한다.

리스코프 교체 원칙
(Liskov Substitution Principle - LSP)
서브타입은 언제나 자신이 기반타입 (base type)으로 교체할 수 있어야 한다. 유도된 클래스의 메소드를 퇴화시키거나 불법으로 만드는 일을 피하라. 기반 클래스의 사용자는 그 기반 클래스에서 유도된 클래스에 대해 아무것도 알 필요가 없어야 한다.

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

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