PHP 잡담'재 구성-기 존 코드 의 디자인 개선'의 4 가지 간략화 조건 식

사유 도 는 아래 그림 을 클릭 하여 큰 그림 을 본다.

 소개 하 다.
 
 조건 논리 가 매우 복잡 할 수 있 기 때문에 본 장 은 재 구성 기법 을 제공 하여 그것들 을 간소화 하 는 데 사용한다.
 
전문 약술(아래 내용 을 직접 뛰 어 넘 을 수 있 습 니 다)
핵심 재 구성:Decompose Conditional―분리'전철 논리'(switching logic)와'조작 디 테 일'(details)분리.
여러 테스트 에서 같은 결과 가 나 왔 습 니 다:Consolidate Conditional Expression
조건 부 코드 에서 중복 성분 제거:Consolidate Duplicate
표지 특수 상황:중첩 조건 을 가드 조항 으로 교체
싫어 하 는 제어 태그 제거:Remove Control Flag
 
 
 전문 용어
 
decompse:분해,분리
consolidate:합병
적합 하 다
조각
nest:끼 워 넣 기
가드
clause:종문
polymorphism:다 중
assertion:단언
unchecked exception:제어 할 수 없 는 이상
 
 Decompose Conditional
 
상황:당신 은 복잡 한 조건(if-else if-else)문 구 를 가지 고 있 습 니 다.그러면 if,else if,else 세 단락 에서 각각 함 수 를 추출 합 니 다.



 
 

 
 Consolidate Conditional Expression
 
상황:일부 조건 테스트 가 있 습 니 다.모두 같은 결 과 를 얻 었 습 니 다.그러면 이 테스트 를 하나의 조건 식 으로 합 쳐 이 조건 을 하나의 독립 된 함수 라 고 추출 합 니 다.
동기:1.합병 후의 조건 코드 는"실제로 한 번 의 조건 검사 만 있 을 뿐,단지 몇 개의 병렬 조건 이 검 사 를 필요 로 할 뿐"이 라 고 말 할 것 이다.검사 의 의 도 를 더욱 명확 하 게 할 것 이다.
　　　  2.Extract Method 를 위 한 준비.검사 조건 을 하나의 독립 함수 로 추출 하여 코드 의 미 를 정리 하 는 데 매우 유용 하 다.그것 은'무엇 을 하 느 냐'는 문 구 를'왜 이렇게 하 느 냐'로 바 꾸 었 다.





 
조건문 의'합병 이유'도'합병 하지 말 라'는 이 유 를 지적 했다.만약 에 이런 검사 들 이 서로 독립 적 이 고 똑 같은 검사 로 간주 되 어 서 는 안 된다 고 생각한다 면 본 재 구성 을 사용 하지 말 아야 한다.이런 상황 에서 당신 의 코드 는 이미 자신의 의 미 를 분명하게 표현 하기 때 문 입 니 다.
 

 
 Consolidate Duplicate Conditional Fragments
 
상황:조건 식 의 모든 분기 에 같은 코드 가 있 으 면 이 중복 코드 를 조건 밖으로 옮 깁 니 다.
 




 
 Remove Control Flag
 
상황:일련의 불 표현 식 에서 특정한 변 수 는'제어 태그'역할 을 합 니 다.그러면 break 문 이나 return 문 구 를 제어 표 시 를 대체 합 니 다.
 


 
 

 
 Replace Nested Conditional with Guard Clauses
 
상황:함수 의 조건 논 리 는 정상 적 인 실행 경 로 를 알 아 보기 어렵 습 니 다.그러면 위생 문(Guard Clauses)을 사용 하여 모든 특수 한 상황 을 표현 합 니 다.



조건 식 의 두 가지 형식:
1.모든 가 지 는 정상 적 인 행동 에 속 합 니 다.[if..else..]
2.조건 식 은 매우 보기 드물다.이 조건 을 단독으로 검사 하고 이 조건 이 진실 일 때 즉시 함수 에서 되 돌려 야 한다.이런 단독 검 사 는 흔히'위문'이 라 고 불 린 다.
Replace Nested Conditional with Guard Clauses 정수:특정한 부분 에 특히 중시 합 니 다.

 
 Replace Conditional with Polymorphism
 
상황:대상 유형 에 따라 다른 행동 을 선택 하 는 표현 식 이 있 습 니 다.이 조건 식 의 모든 가 지 를 subclass 내 복사 함수 에 넣 고 원시 함 수 를 추상 함수 로 설명 합 니 다.
 

이 코드 의 나 쁜 맛:
1.너무 길 어서 동 영상 에 새로운 유형 이 있 을 때 더 길 어 집 니 다.
2.그것 은 분명히 한 가지 일 을 한 것 이 아니다.
3.그것 은 여러 가지 수정 이유 가 있 기 때문에 단일 권력과 책임 원칙 을 위반 했다.
4.새로운 유형 을 추가 할 때마다 수정 해 야 하기 때문에 개방 폐쇄 원칙 을 위반 합 니 다.하지만 가장 번 거 로 운 것 은 곳곳에 유사 한 구조 가 있 을 수 있다(get 형식 이름 Rank()의 함수 입 니 다.

 

 Introduce Assertion
 
상황:특정한 코드 는 프로그램 상태(state)에 대해 특정한 가설 을 해 야 한다.그러면 단언(assertion)으로 이러한 가설 을 명확 하 게 표현 해 야 한다.
 
 
 

실행 결과:



실행 결과:

 
채 점:

1.이런 코드 가 자주 있 습 니 다.특정한 조건 이 사실 일 때 만 이 코드 가 정상적으로 작 동 할 수 있 습 니 다.실제 프로그램의 최종 완제품 은 종종 assertion 을 모두 삭제 합 니 다.
2.이러한 가설 은 코드 에 명확 하 게 나타 나 지 않 기 때문에 전체 알고리즘 을 읽 어야 알 수 있다.때때로 프로그래머 는 주석 으로 이런 가설 을 쓰 는데,assetion 은 더 좋 은 기술 이다.
3.assertion 은 조건 식 이 므 로 항상 진실 해 야 합 니 다.실패 하면 프로그래머 가 실 수 를 했다 는 뜻 이다.
4.assertion 은 교류 와 디 버 깅 의 보조 가 될 수 있다.커 뮤 니 케 이 션:프로그래머 가 코드 가 한 가설 을 읽 고 이해 하 는 데 도움 을 줄 수 있 습 니 다.디 버 깅:프로그래머 가 bug 를 찾 도록 도와 주 고 가장 가 까 운 곳 에서 bug 를 잡 을 수 있 습 니 다.
5.assertion 은 프로그램의 어떠한 행위 도 바 꾸 지 않 습 니 다.
6.assertion 가치:프로그래머 가 코드 의 정확 한 운행 에 필요 한 조건 을 이해 하도록 도와 준다.
7.assertion 의 조건 식 을 Extract Method 를 사용 하 는 것 이 좋 습 니 다.여러 곳 의 중복 코드 를 같은 함수 에 추출 하기 위해 서 는 조건 식 의 용 도 를 더욱 명확 하 게 설명 하기 위해 서 일 수도 있 습 니 다.
 
 총결산
 
       이 장 에서 저 는'Replace Nested Conditional with Guard Clauses'라 는 방식 을 좋아 합 니 다.저 는 평소에 코드 에서 도 자주 이렇게 사용 합 니 다.그리고 이런 방식 으로'위 종문'이 라 고 이름 을 지어 주 는 사람 도 있 습 니 다.
      또 하 나 는 제 가 phop 개발 에 자주 사용 하 는 디 버 깅 은 var 입 니 다.dump()또는 printr(),저도 phop 에 assert 라 는 방식 이 있 는 것 을 처음 발 견 했 습 니 다.좋 습 니 다!
 
        공부 하고 실천 하 는 과정 에서 저도 좋 은 방법 을 많이 배 웠 습 니 다.하지만 저 는 팀 개발 에서'대국 이 중요 하 다'고 생각 합 니 다.팀 의 습관 적 인 방식 으로 인 코딩 을 하거나 팀 과 소통 하여 인 정 받 은 후에 이 안의 방법 을 사용 하면 서로 상대방 의 코드 를 디 버 깅 하고 읽 을 때 편리 하 다 고 생각 합 니 다.