디자인 원칙 1
- 애플리케이션에서 달라지는 부분을 찾아내고 달라지지 않는 부분과 분리
즉 바뀌는 부분은 따로 뽑아서 캡슐화한다. 나중에 바뀌지 않는 부분에는 영향을 미치지 않고 그 부문만 고치거나 확장할 수 있다.
ex) bird()이라는 클래스에서 찾아보자
자주 바뀌는 부분?? -> cly() - 운다. why?? 새마다 울음소리가 다르다. fly() -> 새마다 나는 방식이 다르다
자주 안 바뀌는 부분?? -> walk() - 걷기, eat() - 먹기
이때 자주 바뀌는 부분을 클래스 집합으로 만든다. 예를 들어 꽦꽥 우는 행동을 클래스로 만들고 뽹뽹 거리는 행동을 클래스로 만드는 식이다.
디자인 원칙 2
- 구현 보다는 인터페이스에 맞춰서 디자인한다.
즉 fly, cly 부분은 특정 행동 인터페이스를 구현한 별도의 클래스안에 있고 bird 클래스는 행동을 구체적으로 구현할 필요가 없다.
ex)
- flyBehavior() <<인터페이스>>
- FlyWithWings() - <<클래스>>
- FlyNoWay() - <<클래스>>
모든 부분을 다 전략패턴을 따지는 것이 좋은지 생각해 봤다. 새 처럼 종류가 많고 상속 클래스마다 오버라이딩 해야한다면 전략패턴이 유용할 것 같다. 만약 종류가 다양하지 않고 행동이 일정하다면 굳이 전략패턴으로 각 행동을 클래스로 만드는 수고로움과 많은 클래스를 관리하는 것이 더 복잡하고 쓸모 없을 것 같다.
그렇다면 이러한 전략패턴을 회사의 어떤 부분에 적용할 수 있을까??
1. 유저 - 모니터링, 관리자, 최고관리자
2. 정책 - snort, blacklist, white blacklist 등등
이 두가지 예시에 적용시키는 것이 옳을까?? => user는 no 정책은 고려 필요
why? 유저는 굳이 나누는 것보다 각 3개의 클래스로 나눠서 관리하는 것이 효율적일 것 같음 각 포지션의 행동이 다양하게 많지도 않기 때문에 굳이 다른 부분을 클래스로 여러개 만들어서 관리하기 보다는 3개의 클래스를 만들거나 user 인터페이스를 만들고 필요한 것만 오버라이딩 하는 것이 더 좋아보임. 아니면 user인터페이스에 공통적인 부분만 넣고 각 클래스에 필요한 부분을 새롭게 추가하는 방식
정책은 각 정책마다 가지는 공통요소가 존재하고 각 특징마다 여러가지 다르게 행위를 취하는 경우가 많아서 클래스로 뽑아서 행위를 동적으로 바꾸는 것이 좋을 수 도 있을 것 같음.
책의 예시 코드 - Duck
