반응형
클래스 간의 코드 통합
전략패턴 도입
기존 코드에서는 인터페이스 안에 모든 코드를 통합하다보니 유지보수가 어려운 문제가 있었다.
그래서 전략패턴을 도입해서 각각의 성격에 맞게 전략을 분리할 수 있다.
전략패턴 vs 상태패턴
전략패턴과 상태패턴은 뭔가 비슷한데 아래와 같은 차이가 있다.
전략패턴
- 인스턴스 생성 후, 상태가 거의 바뀌지 않는 경우
- 전략을 클래스로 표현
상태패턴
- 인스턴스 생성 후, 상태가 빈번하게 바뀌는 경우
- 상태를 클래스로 표현
UML
UML 은 코드에 대한 속성을 전달하기 위해 다양한 유형의 표준 다이어그램으로 구성됨
- 시퀀스 다이어그램 : 객체 간의 요청과 응답 흐름
- 클래스 다이어그램 : 클래스 설계 및 연관관계
- 활동 다이어그램 : 기획 흐름을 보여줌
구현체가 하나인 인터페이스를 만들지 말 것
구현 클래스가 하나인 인터페이스는 가독성에 도움이 안되며,
인터페이스는 변형을 전제로 하는데, 아무것도 없다면 오히려 가독성을 방해한다.
또한 구현 클래스를 수정하려는 경우 인터페이스까지 수정해야 하므로 오버헤드를 발생시킨다.
따라서 구현체가 하나라면 인터페이스를 만들지 말고, 구현체가 2개 이상이 되는 시점에 인터페이스를 만들어라.
(나는 현업에서 구현체가 하나여도 인터페이스를 만들었었는데, 위 단점이 공감이 됨)
반응형
댓글