프로 그래 밍 의 추상 적 인 핵심

목차

1. 프로그램, 알고리즘

본질

예시

2. 대상 지향, 디자인 모델

인터페이스 프로 그래 밍

그룹 이 계승

보다 우수 하 다.

3. 후진 과 제어 반전 에 의존 (IoC / DIP)

돈

스위치 와 램프

증권거래소

프로그램
본질

  =  +    
  =  +  

프로그램 = 알고리즘 + 수 결 구 조 는 모두 가 알 고 있 는 바 와 같이 알고리즘 이라는 해석 은 비교적 청아 하고 탈속 하 다. 1. 논리 2. 제어.

논 리 는 실제 문 제 를 해결 하 는 데 사용 되 고 어떤 전략 으로 문 제 를 해결 하 는 지 제어 하 며 논 리 는 진정한 의미 에서 문 제 를 해결 하 는 알고리즘

이다.

제 어 는 프로그램 이 흐 르 는 방식, 즉 프로그램 이 실행 하 는 방식, 병렬 또는 직렬, 동기 화 또는 비동기, 서로 다른 실행 경로 나 모듈, 데이터 간 의 저장 관 계 를 조정 하 는 것 이다.

논 리 는 , 통 제 는 , 소통 방식 은 이다.
예 를 들다
양식 검증

function check(data) {
       = get(data,   )
    if (     ||       3) {
        return     ，    
    } 
       = get(data,  )
    if (     ||       8) {
        return     ，    
    } 
       = get(data,  )
    if (     ||        ) {
        return     ，    
    } 
    ...
    return     ; 
}

이 함수 의 최종 논 리 는 입력 데이터 의 합 법성 을 검증 하 는 것 입 니 다. 그러나 이것 은 바로 제어 와 논 리 를 결합 시 키 는 것 입 니 다. 검증 필드 가 증가 함 에 따라 이 함수 가 점점 길 어 지고 결국은 가 독성 이 점점 떨 어 지 며 유지 하기 가 점점 어려워 집 니 다.
두 가 지 를 더 잘 분리 하 는 방법 은 폼 검증 기 를 정의 하 는 것 이다. 다음 과 같다.

var rules = {
       : ["    3"],
       : ["    8"]
       : ["email  "]
    ...
    ]
};
 if     =checkRules(rules).  ();         {
    return     ，    
}
return      

이렇게 설명 검증 규칙 을 통 해 제어 와 논리 간 의 결합 을 얻 었 습 니 다. check 에서 여러 가지 if else 를 사용 하지 않 아 도 됩 니 다.
절대 다수의 프로그램 이 복잡 하고 혼 란 스 러 운 근본 원인 은 업무 논리 와 제어 논리의 결합 이다.
2. 대상 지향, 디자인 모델
대상 지향, 디자인 모델 의 중점 은:

인 터 페 이 스 를 사용 하여 구체 적 인 실현 류 를 추상 화 했다. 그러면 다른 유형의 결합 은 실현 류 가 아니 라 인터페이스 이다. 이것 이 바로 너무 많 고 프로그램의 확장 성

을 증가 했다.

인 터 페 이 스 는 일종 의 프로 토 콜 이다. HTTP 프로 토 콜 처럼 브 라 우 저 와 백 엔 드 의 프로그램 은 모두 이 프로 토 콜 에 의존 하 는 것 이지 구체 적 인 실현 에 의존 하 는 것 이 아니다. (구체 적 인 실현 에 의존 하 는 것 이 라면 브 라 우 저 는 백 엔 드 의 프로 그래 밍 언어 나 미들웨어 에 의존 해 야 한다. 이것 은 너무 징그럽다.)따라서 브 라 우 저 와 백 엔 드 프로그램 은 의존 관 계 를 완전히 해제 하고 표준 프로 토 콜 에 의존 하 는 것 도 Ioc / DIP 의 본질 이다.

23 개의 디자인 모델 은 기본적으로 두 개의 대상 을 대상 으로 하 는 핵심 이념 을 말 했다. 즉, 인터페이스 프로 그래 밍, 조합 이 계승 보다 우수 하 다.
인터페이스 프로 그래 밍

사용 자 는 데이터 유형, 구조, 알고리즘 의 세부 사항 을 알 필요 가 없다

사용 자 는 실현 세부 사항 을 알 필요 가 없고 제 공 된 인터페이스 만 알 아야 한다

조합 이 계승 보다 낫다
계승 은 부류 에 일부 부류 의 설계 와 실현 세부 사항 을 폭로 해 야 한다. 부류 가 실현 하 는 변 화 는 부류 도 변화 해 야 하고 조합 은 이런 폐단 이 존재 하지 않 는 다.우 리 는 계승 은 주로 코드 를 재 활용 하기 위 한 것 이 라 고 생각 하지만 실제로 하위 클래스 에서 많은 부모 류 를 다시 실현 하 는 방법 이 필요 하 다. 더 많은 것 을 계승 하 는 것 은 다 형 을 위 한 것 이 어야 한다.
3. 반전 과 제어 에 의존 (IoC / DIP)
쉽게 말 하면 추상 적 인 인터페이스 에 의존 해 야 한다. 구체 적 인 실현 에 의존 해 서 는 안 된다. 이것 이 바로 반전 을 제어 하 는 것 이다. 스위치 는 예전 설비 의 전용 스위치 에서 전원 을 제어 하 는 스위치 로 바 뀌 었 고 예전 의 설 비 는 반대로 스위치 공장 이 설명 한 전원 인터페이스 에 의존 해 야 한다.
돈.
예전 의 물 물 교환 에서 '돈' 에 의존 하 는 것 으로 바 뀌 었 고 모든 상품 은 이 '돈' 의 거래 협의 에 의존 하 며 더 이상 서로 의존 하지 않 아 도 된다. 전 세계 의 동작 은 매우 간단 해 졌 다.
스위치 와 램프
하나의 스위치 가 하나의 불 을 켜 고 끄 는 것 을 제어 해 야 하 는데 가장 직접적인 방법 은 스위치 와 불 을 함께 하 는 것 이다.그러나 어느 날, 우 리 는 이 스위치 가 전구 뿐만 아니 라 다른 것 도 제어 해 야 한 다 는 것 을 발견 하면 스위치 가 전구 와 결합 되 어 매우 확장 되 지 않 는 다 는 것 을 알 게 될 것 이다.해결 방안 은 스위치 공장 을 만 드 는 것 이 통제 할 필요 가 없 는 것 이 무엇 인지 에 따라 하나의 스위치 만 만 만 드 는 것 이다. 기능 은 바로 전 기 를 연결 하고 끊 는 것 이다. 수 동, 음성 제어 든 광 제어, 리모콘 이 든 스위치 공장 과 전등 공장 은 표준 적 인 전기 와 단전 의 인터페이스 에 의존 하 는 것 이다.전 구 를 만 드 는 공장 도 당신 이 어떤 스위치 를 사용 하 는 지 에 관심 이 없습니다. 전등 의 전원 인 터 페 이 스 를 만 들 기만 하면 됩 니 다. 스위치 공장 과 전등 공장 은 표준 전기 와 단전 의 인터페이스 에 의존 합 니 다.
증권 거래소
거래 하 는 과정 에서 판매 자 는 바이어 에 게 물건 을 팔 고 한 손 으로 돈 을 내 고 한 손 으로 물건 을 인도 한다. 기본적으로 만 나 야 한다. 이때 은행 이 나 와 담 보 를 한다. 바 이 어 는 먼저 돈 을 은행 에 걸 고 은행 은 판매자 에 게 물건 을 보 내 라 고 한다. 바 이 어 는 물건 을 검사 한 후에 은행 은 다시 돈 을 판매자 에 게 건네준다.이것 이 바로 반전 통제 이다. 매매 쌍방 은 상대방 에 대한 직접적인 의존 과 통 제 를 상대방 으로 하여 금 표준 적 인 거래 모델 에 의존 하 게 하 는 인터페이스 로 반전 시 켰 다.