디자인 모델 - 소프트웨어 디자인 의 결합 정도 에 대한 사고

　　         ，      ，     ·32  ；       ，      。         ：

결합 도가 높 은 버 전:

private static double getResult(double n1, double n2, string operation)
{
  double double rtnResult;
  switch(operation)
  {
    case "+":
    ...
    break;
    case "-"
    ...
    break;
    case "*"
    ...
    break;
    case "/"
    ...
    break;   
  }
  return rtnResult;
}

계산기 의 가감 승제 조작 은 하나의 함 수 를 통 해 주요 업무 논 리 를 직접 실현 하 였 다.이런 방식 의 장점 은 새로운 업무 대상 을 형성 하지 못 한 것 이다.확장 성 이 떨 어 지고 후기 유지 가 쉽 지 않 은 것 이 단점 이다.분명히 가감 승제 가 주요 업무 조작 이기 때문에 4 개의 업무 대상 으로 개조 하고 각 업무 대상 은 자신의 조작 을 봉인 하 며 이 4 개의 모듈 을 관리 할 수 있다.그리고 이 네 개의 모듈 기능 은 병렬 되 어 있어 '공장 모델' 을 적용 하여 실현 할 수 있다.
UML 은 다음 과 같다.
아 날로 그 는 간단 합 니 다. 4 개의 업무 류 는 각각 인 터 페 이 스 를 실현 합 니 다. MangeOper 류 는 4 개의 업무 대상 을 인용 하여 인터페이스의 실현 류 를 확인 합 니 다. UI 클 라 이언 트 는 이 ManageOper 류 를 인용 하여 사용자 에 게 가감 승제 중의 어떤 조작 을 선 택 했 는 지 알려 줍 니 다.
계산기 라 는 예 에서 상기 디자인 모델 은 좋 습 니 다. 주요 업무 대상 의 결합 도가 비교적 낮 습 니 다. 앞으로 다른 작업 을 확장 하려 면 새로운 업무 유형 을 많이 쓰 면 됩 니 다.그러나 모든 디자인 은 결합 도가 가능 한 한 낮 아야 하지 않 습 니까?
이것 은 좋 은 문제 다!
문 제 는 절대적 이지 않다!느슨 한 결합 이 반드시 좋다 고 해서 단단 한 결합 이 반드시 좋 지 않다 는 것 은 아니다.만약 에 특정한 소프트웨어 를 구성 하 는 모듈 의 위치 가 매우 낮다 면 디자인 해 야 하 는 결합 도가 낮 고 유연성 이 강 한 지 고려 해 야 한다.!
나 는 그것 을 작성 하 는 데 너무 많은 정력 을 들 이 고 싶 지 않 기 때문에 앞으로 그것 은 거의 변 하지 않 을 것 이다. 그러면 긴밀 한 결합 을 취 하 는 것 도 좋 은 디자인 방법 이 아 닌 것 은 아니다.다시 말 하면 이것 이 회사 의 중점 업무 라면 결합 도 소문 자 를 써 서 해당 하 는 디자인 모델 을 잘 구상 해 야 한 다 는 것 이다.
디자인 모델 은 업무 와 미래의 업 무 를 따라 갑 니 다!