디자인 모드 - 문제 풀이 보고서

이 문집 의 시 리 즈 는 라 는 책 으로 업무 코드 에 싫 증 이 날 때 볼 수 있 고 많은 이익 을 얻 을 수 있 도록 권장 합 니 다.
제1장 에서 제1 3 장 을 보면 흥미진진 하지만 한 번 보면 잊어버린다. 왜냐하면 이런 예 는 실제 응용 에서 유연 하고 융통성 이 필요 하기 때문이다.마치 고 수 를 배 우 는 것 과 같다. 너 는 방정식 의 문제 풀이 방법 과 과정 을 배 웠 지만 같은 문 제 를 실제 물리 모델 에 넣 으 면 바로 그 중의 해법 을 발견 할 수 있 는 것 은 아니다.
여러 번 읽 고 문 제 를 생각 할 때 디자인 모델 의 사 고 를 천천히 대 입 하고 재 구성 할 때 그 중의 법칙 을 따른다. 이것 이 바로 대 신 들 이 흔히 말 하 는 '너 는 이렇게 해 야 한다' 는 것 이다.왜 갑자기 멈 춰 서서 이 직책 체인 모델 을 씁 니까?다음 코드 덕분 입 니 다.
만약 에 우리 가 핸드폰 을 판매 하 는 전자상거래 사 이 트 를 책임 진다 고 가정 하면 각각 500 위안 의 계약금 과 200 위안 의 계약금 을 납부 하 는 2 차 예약 을 거 친 후에 (주문 은 이때 생 성) 지금 은 정식 구 매 단계 에 이 르 렀 다.회 사 는 계약금 을 지불 한 사용 자 를 대상 으로 일정한 우대 정책 을 가지 고 있다.본 격 적 인 구 매 후 이미 계약금 500 원 을 지급 한 사용 자 는 100 원 짜 리 몰 쿠폰 을, 200 원 짜 리 가입 자 는 50 원 짜 리 쿠폰 을 받 을 수 있 는데 그 간 계약금 을 지급 하지 않 은 사용 자 는 일반 구 매 모드, 즉 쿠폰 이 없고 재고 가 제 한 된 경우 에 만 살 수 있다 고 장담 할 수 없다.
여기 간략하게...
orderType: 주문 유형 | 1 = > 500 원 계약금 사용자, 2 = > 200 원 계약금 사용자, 3 = > 일반 구 매 사용자 pay: 계약금 을 지 불 했 는 지 여부.(사용자 가 500 / 200 위안 의 계약금 주문 을 했 지만 지불 하지 않 았 다 면 일반 구 매 모델 로 강등) stock: 현재 일반 구 매 지 에 사용 되 는 핸드폰 재고 수량, 이미 계약금 을 지불 한 사용 자 는 제한 을 받 지 않 습 니 다.

//    
var oder = function( orderType, pay, stock) {
  if( orderType === 1 ) { // 500       
    if ( pay === true ) {
      console.log('500     ，  100    ');
    }else {
      if ( stock > 0 ) {
        console.log('    ，     ');
      }else {
        console.log('      ');
      }
    }
  }

  else if ( orderType === 2 ) { // 200       
    if ( pay === true ) {
      console.log('200     ，  50    ');
    }else {
      if ( stock > 0 ) {
        console.log('    ，     ');
      }else {
        console.log('      ');
      }
    }
  }

  else if ( orderType === 3 ) { // 200       
    if ( stock > 0 ) {
      console.log('    ，     ');
    }else {
      console.log('      ');
    }
  }
};

order(1, true, 500); //  ： 500     ，  100    

저 자 는 아마도 최신 프로그래머 만 이 이런 코드 를 쓸 수 있 을 것 이 라 고 논평 했다.그래서 나 는 어색 하 게 생각 했다. 하하, 나 도 끼 워 줘.
실습 기간 에 제 가 직면 한 실제 상황 은 조금 복잡 합 니 다. 간단하게 설명 하 겠 습 니 다. 하나의 제품 관리 시스템, 첫 번 째 가 지 는 서로 다른 계열 의 제품 입 니 다. 두 번 째 가 지 는 서로 다른 역할 이 고 세 번 째 가 지 는 바로 대응 하 는 action 입 니 다. (이 층 은 위의 log 에 해당 하 므 로 포함 되 지 않 을 수 있 습 니 다)
그러면 전체 절 차 를 진정 으로 숙지 하지 못 한 상황 에서 저 는 else - if 의 많은 가 지 를 자주 씁 니 다. 이런 가 지 는 처음에 그렇게 많 지 않 았 습 니 다. (보통 처음에는 2 시간 상황 이 었 고 3 개 일 때 기능 의 포장 등 상황 을 고려 했 습 니 다) 프로젝트 가 앞으로 가면 임시로 상황 을 넣 었 습 니 다. else - if 분기 가 폭발 하기 시 작 했 습 니 다.코드 를 쓸 때마다 소똥 에 꽃 을 심 는 것 과 같 아서, 너 는 돌아 서서 이 꽃 들 을 감상 하고 싶 지 않다.전체 과정 이 마치 따뜻 한 물 속 의 개구리 와 같 습 니 다. 당신 은 제품 이 끓 인 물 을 탓 할 수 있 습 니까?제품 에 의 하면 나 도 솥뚜껑 을 덮 지 않 았 는데, 너 자신 은 제때에 튀 어 나 와 야 한 다 는 것 을 의식 하지 못 했 니?
사고 1. 새로운 수 요 를 받 으 면 코드 재 구성 이 필요 하 다 는 것 을 어떻게 의식 합 니까?2. 재 구성 이 필요 하 다 면 코드 를 어떻게 전망 적 으로 재 구성 합 니까?
코드 는 한 번 만 재 구성 할 수 있다 는 말 을 읽 은 적 이 있다.불합격 프로그래머 로 서 나 는 많은 시간 을 들 여 재 구성 하여 그 고통 을 깊이 알 고 있다.
level 5 때 재 구성 을 두 번 시도 해 보 겠 습 니 다.

코드 정리 + 주석 정리

기능 분리

Emily Morter 2017-01-11.jpg
level 6 때 나 는 코드 재 구성 이 모델 상의 변화 라 는 것 을 알 게 되 었 다. 그래서 나 는 더 이상 기능 적 인 코드 를 바 꾸 지 않 았 다. 예 를 들 어 상호작용 사건 등 이다.

디 결합 코드, 폐쇄 - 개방 원칙 에 위반 한 코드 처리

level 7 때 나 는 아직 하지 못 했다.나 는 고치 지 않 을 것 이다. 왜냐하면 이것 은 너 로 하여 금 네가 가장 좋아 하 는 것 을 싫어 하 게 할 뿐 이기 때문이다.
마지막 으로 이 책 을 진심으로 추천 합 니 다.