자바 코드 최적화 6 대 원칙

단일 직책
코드 최적화 첫 번 째 단계, 단일 직책 원칙 (Single Responsibility Principle).자바 류 에 대해 서 는 변 화 를 일 으 키 는 원인 이 하나 밖 에 없어 야 합 니 다. 즉, 하나의 클래스 에 서 는 상관 성 이 높 은 함수, 데이터 의 패 키 징 이 어야 합 니 다.그러나 이 원칙 의 경 계 는 그리 명확 하지 않 고 어느 정도 개발 자의 개인 경험 에 의존 하여 정 해 야 한다.단일 직책 한계 에 대한 구분 의 가장 큰 문 제 는 바로 유형의 직책 이 무엇 인지, 유형의 직책 을 어떻게 구분 하 느 냐 하 는 것 이다.단일 직책 원칙 은 우리 의 실제 업무 에서 흔히 볼 수 있다. 예 를 들 어 우리 가 비교적 관심 을 가 지 는 프레임 워 크 인 MVC, MVP 에서 페이지 전 시 를 담당 하 는 Activity, Fragment, 그리고 각종 View 는 UI 의 전시 만 맡 고 구체 적 인 업무 논 리 는 Controller 나 Presenter 에 맡긴다.예 를 들 어 각종 유행 하 는 이미지 로드 프레임 워 크 는 그 중에서 이미지 로드 류, 이미지 캐 시 를 전문 적 으로 담당 하 는 종 류 를 찾 을 수 있다.그래서 단일 직책 원칙 은 우리 코드 최적화 의 첫 번 째 단계 이자 가장 중요 한 단계 이다.
개폐 원칙
개폐 원칙 (Open Close Principle) 은 자바 세계 에서 가장 기본 적 인 디자인 원칙 으로 우리 가 어떻게 안정 적 이 고 유연 한 시스템 을 구축 하 는 지 지도 한다.개폐 원칙 정의: 소프트웨어 의 대상 (클래스, 모듈, 함수 등) 은 확장 에 대해 개방 적 이 고 수정 에 대해 폐쇄 적 이 어야 합 니 다.소프트웨어 의 생명주기 내 에 변화, 업그레이드, 유지보수 등 으로 인해 소프트웨어 의 기 존 코드 를 수정 해 야 할 때 이미 테스트 한 낡은 코드 에 오 류 를 도입 하여 기 존 시스템 을 파괴 할 수 있 기 때문에 소프트웨어 가 변화 가 필요 할 때 우 리 는 기 존 코드 를 수정 하 는 것 이 아니 라 확장 하 는 방식 으로 변 화 를 실현 할 수 있어 야 한다.그러나 이것 도 절대적 인 것 이 아니다. 실제 개발 과정 에서 계승 방식 으로 만 기 존 시스템 을 업그레이드 하고 유지 하 는 것 은 이상 적 인 상황 이기 때문에 실제 개발 에서 기 존 코드 를 수정 하고 확장 코드 를 수정 하 는 것 이 동시에 존재 한다.기 존 소프트웨어 모듈 의 정확성 을 확보 하고 기 존 코드 모듈 에 최대한 영향 을 주지 않 는 방법 은 개폐 원칙 을 최대한 지 키 는 것 이 답 이다.
리 씨 교체 원칙
리 씨 교체 원칙 (Liskov Substitution Principle) 은 정의 합 니 다. 모든 유형 이 ClassA 인 대상 a 에 대해 ClassB 인 대상 b 가 있 으 면 ClassB 로 정 의 된 모든 프로그램 P 가 모든 대상 b 에서 a 로 바 뀌 었 을 때 프로그램 P 의 행동 이 변 하지 않 았 습 니 다. 그러면 유형 ClassA 는 유형 ClassB 의 하위 유형 입 니 다.그러나 이 서술 은 쓸모 가 없다. 더욱 직접적인 정 의 는 모든 인용 기 류 는 하위 클래스 의 대상 을 투명 하 게 사용 해 야 한 다 는 것 이다.
우 리 는 대상 을 대상 으로 하 는 세 가지 특징 은 계승, 포장, 다 형, 리 씨 교체 원칙 은 바로 계승, 다 형 이라는 두 가지 특성 에 의존 하 는 것 이라는 것 을 안다.리 씨 교체 원칙 은 쉽게 말 하면 모든 인용 기 류 는 하위 대상 을 사용 해 야 한 다 는 것 이다.부계 가 나타 날 수 있 는 곳 이면 그 자 류 는 나타 날 수 있다 는 것 이다.그리고 하위 클래스 로 바 꾸 면 오류 와 차이 가 발생 하지 않 습 니 다.사용 자 는 뿌리 부분 에서 부류 인지 부류 인지 알 필요 가 없 을 수도 있 지만 반대로 하면 안 되 고 부류 가 나타 나 는 곳 에서 부류 가 반드시 적응 할 수 있 는 것 은 아니다.사실은 근본적으로 리 씨 교체 원칙 은 바로 이 두 글 자 를 바탕 으로 하 는 것 이다. 추상 이다.
예 를 들 어 Android 에서 페이지 Window 의 전 시 는 View 에 의존 하고 View 는 하나의 보기 추상, measure 와 draw 는 하위 클래스 가 공유 하 는 방법 을 정의 합 니 다. 하위 클래스 는 복사 measure 와 draw 방법 을 통 해 다양한 기능 과 보 기 를 실현 할 수 있 습 니 다. View 를 계승 하 는 모든 하위 클래스 는 Window 에 전달 되 고 Window 가 View 를 조직 하고 View 를 화면 에 표시 합 니 다.이것 이 바로 리 씨 교체 원칙 이다.
리 씨 교체 원칙 의 핵심 원 리 는 추상 적 이 고 추상 적 이면 서도 계승 에 의존 하 는 것 으로 OOP 에서 계승 의 장단 점 이 상당히 뚜렷 하 다.장점 은:

코드 를 다시 사용 하여 클래스 를 만 드 는 비용 을 줄 이 고 모든 하위 클래스 는 부모 클래스 의 방법 과 속성 을 가지 고 있 습 니 다

자 류 와 부 류 는 기본적으로 비슷 하지만 부계 와 차이 가 있다

코드 의 확장 성 향상

계승 의 단점: - 계승 은 침입 적 인 것 입 니 다. 계승 하기 만 하면 아버지 류 의 모든 속성 과 방법 을 가 져 야 합 니 다. - 서브 코드 가 지루 하고 유연성 이 떨 어 질 수 있 습 니 다. 왜냐하면 서브 류 는 반드시 아버지 류 의 방법 과 속성 을 가 져 야 하기 때 문 입 니 다.
그러나 사물 은 항상 양면성 이 있 고 균형 과 이용 에 부합 되 는 것 은 구체 적 인 상황 에 따라 선택 해 야 한다.개발 과정 에서 추상 을 활용 하 는 것 은 코드 최적화 로 가 는 중요 한 단계 이다.
후진 원칙 에 의존 하 다.
후진 원칙 (Dependence Inversion Principle) 에 의존 하고 후진 원칙 에 의존 하여 특정한 디 결합 형식 을 지정 하여 고 차원 모듈 이 저 차원 모듈 의 디 테 일 한 실현 목적 에 의존 하지 않 고 모듈 에 의존 하 는 것 이 뒤 바 뀌 었 다.그러나 정의 가 이해 하기 어 려 운 것 은 후진 원칙 에 의존 하 는 데 다음 과 같은 몇 가지 관건 이 있다. - 고 층 모듈 은 저층 모듈 에 의존 해 서 는 안 된다. 둘 다 추상 에 의존 해 야 한다. 추상 은 디 테 일 에 의존 해 서 는 안 된다. 디 테 일 은 추상 에 의존 해 야 한다. 추상 은 인터페이스 나 추상 류 를 말 하 는데 둘 다 직접적 으로 예화 되 어 서 는 안 된다.디 테 일 은 실현 류 이 고 인 터 페 이 스 를 실현 하거나 추상 류 를 계승 하여 발생 하 는 류 는 디 테 일 이 며 그 특징 은 바로 실례 화 될 수 있다 는 것 이다.고 층 모듈 은 호출 단 이 고 저층 모듈 은 구체 적 인 실현 류 이다.후진 원칙 에 의존 하 는 자바 언어 에서 의 표현 은 모듈 간 의 의존 은 추상 적 인 발생 을 통 해 유형 간 에 직접적인 의존 관계 가 발생 하지 않 고 그 의존 관 계 는 인터페이스 나 실현 류 를 통 해 발생 하 는 것 이다.사실 한 마디 로 인 터 페 이 스 를 향 하거나 추상 적 인 프로 그래 밍 을 향 한 것 이다.만약 에 클래스 가 디 테 일 에 직접 의존 하면 그들 사이 에 직접적인 결합 이 있 고 구체 적 으로 변화 가 필요 할 때 의존 자의 코드 를 동시에 수정 해 야 한 다 는 것 을 의미 하 며 시스템 의 확장 성 을 제한 합 니 다.
인터페이스 격 리 원칙
인터페이스 격 리 원칙 (Interface Segregation Principle) 은 클 라 이언 트 가 필요 하지 않 은 인터페이스 에 의존 해 서 는 안 된다 는 것 을 정의 합 니 다.또 다른 정 의 는 클래스 간 의존 관 계 는 최소 인터페이스 에 세 워 져 야 한 다 는 것 이다.인터페이스 격 리 원칙 은 매우 방대 하고 비대 한 인 터 페 이 스 를 더 작은 인터페이스 와 더 구체 적 인 인터페이스 로 나 누 어 고객 들 이 관심 을 가 지 는 방법 만 알 아야 한다.인터페이스 격 리 원칙 의 목적 은 시스템 이 결합 을 풀 어 재 구성, 변경, 재배 치 하기 쉽다 는 것 이다.
정 의 는 항상 이해 하기 어렵다. 우 리 는 코드 를 통 해 인터페이스 격 리 원칙 의 구체 적 인 사용 을 이해한다.예 를 들 어 우리 가 흔히 볼 수 있 는 출력 스 트림 은 사용 한 후에 닫 아야 합 니 다.

FileOutputStream fos = null;
try{
    fos = new FileOutputStream(URI);
    ...
}catch(FileNotFoundException e){
    e.printStackTrace();
}finally{
    if(fos!=null) {
        try{
            fos.close();
        }catch(IOException e){
            e.printStackTrace();
        }
    }
}

우 리 는 이 코드 의 가 독성 이 매우 떨 어 지 는 것 을 보 았 습 니 다. 각종 try catch 에 포 함 된 것 은 매우 간단 한 코드 입 니 다. 그러면 우 리 는 이 문 제 를 어떻게 해결 합 니까?자바 에 Closeable 인터페이스 가 있 습 니 다:

public interface Closeable extends AutoCloseable {

    /**
     * Closes this stream and releases any system resources associated
     * with it. If the stream is already closed then invoking this
     * method has no effect.
     *
     * @throws IOException if an I/O error occurs
     */
    public void close() throws IOException;
}

이 인 터 페 이 스 는 닫 을 수 있 는 대상 을 표시 합 니 다. close 방법 만 있 고 우리 의 FileOutputStream 도 이 인 터 페 이 스 를 실현 합 니 다.이렇게 하면 우 리 는 쉽게 할 수 있다. 우 리 는 Closeable 인터페이스 에 의존 하여 도구 류 를 실현 할 수 있다.

public final class CloseUtils{
    private CloseUtils(){}

    public static void closeQuietly(Closeable closeable){
        if(null!=closeable){
            try{
                closeable.close();
            }catch(IOException e){
                e.printStackTrace();
            }
        }
    }
}

실제 운용 에서 우 리 는 이렇게 만 하면 된다.

...
finally{
    CloseUtils.closeQuietly(fos);
}

코드 가 매우 간결 해 졌 고 이 도구 류 는 각종 닫 을 수 있 는 대상 에 활용 하여 코드 의 중용 성 을 확보 할 수 있다.CloseUtils 의 closeQuietly 방법의 기본 원 리 는 구체 적 인 실현 이 아니 라 CLoseable 추상 에 의존 하 는 것 이다. 또한 의존 원칙 을 최소 화 하 는 토대 에서 이 대상 이 닫 을 수 있 고 다른 것 은 전혀 관심 이 없다 는 것 만 알 아야 한다. 즉, 우리 가 제시 한 인터페이스 격 리 원칙 이다.
디 미트 원칙
디 미트 원칙 (Law of Demeter) 도 최소 지식 원칙 이 되 었 다. 한 대상 은 다른 대상 에 대해 최소한 의 이 해 를 가 져 야 한다.즉, 한 가지 유형 은 자신 이 결합 하거나 호출 해 야 하 는 유형 에 대해 아 는 것 이 가장 적 고, 유형의 내부 가 어떻게 실현 되 는 지 는 호출 자 나 의존 자 와 관계 가 없 으 며, 호출 자 와 의존 자 는 그것 이 필요 로 하 는 방법 만 알 면 되 며, 다른 것 은 일체 상관 하지 않 는 다.클래스 와 클래스 의 관계 가 밀접 할 수록 결합 도가 크 고 한 클래스 가 변 할 때 다른 클래스 에 대한 영향 도 크다.
예 를 들 어 MVP 프레임 워 크 의 Model 층 의 실현 에 있어 우 리 는 Model 추상 이 View 에 구체 적 인 데 이 터 를 제공 하 는 것 임 을 알 고 있다. 그러나 우리 의 View 층 은 데이터 가 어떻게 얻 었 는 지 알 필요 가 없다. 설령 우리 배경 인터페이스 가 어떻게 바 뀌 더 라 도 데이터 구조 가 변 하지 않 는 다 면 우 리 는 View 층 에 변 화 를 알 릴 필요 가 없다.
총결산
우리 의 실제 개발 에서 가장 어 려 운 것 은 응용 개발 업 무 를 완성 하 는 것 이 아니 라 후속 적 인 업그레이드, 유지 과정 에서 시스템 을 호 환 시 키 는 것 이다. 이것 은 수 요 를 만족 시 키 고 시스템 안정성 을 파괴 하지 않 는 전제 에서 높 은 확장 성, 높 은 내부 집적, 낮은 결합 을 유지 하고 각 버 전의 변 화 를 겪 은 후에 도 뚜렷 하고 유연 하 며 안정 적 인 시스템 구 조 를 유지 하 는 것 을 의미한다.물론 이것 은 이상 적 인 상태 이지 만 우 리 는 반드시 이 방향 으로 노력 해 야 한다. 그러면 우리 가 위 에서 제시 한 6 대 원칙 을 따 르 는 것 이 바로 우리 가 코드 를 최적화 하고 유연 한 소프트웨어 의 길 로 가 는 첫 걸음 이다!
이후 저 는 상기 6 대 기본 원칙 을 결합 하여 안 드 로 이 드 의 디자인 모델 활용 에 대해 설명 하 겠 습 니 다. 지속 적 으로 관심 을 가 져 주 십시오.
같이 교류 하고 공부 하 는 것 을 환영 합 니 다.