자바 디자인 패턴 - 디자인 패턴의 6가지 원칙

6가지 디자인 원칙

단일 책임 원칙

수업 변경에 한 가지 이상의 이유를 두지 마세요. . 평신도의 관점에서 보면 클래스는 단 하나의 책임만 담당합니다.

문제의 원인: 클래스 T는 책임 P1과 책임 P2라는 두 가지 책임을 담당합니다. 책임 P1의 요구 사항 변경으로 인해 클래스 T를 수정해야 하는 경우 원래 정상적으로 실행되고 있던 책임 P2의 기능이 오작동할 수 있습니다.

한 문장으로 요약: 그래픽 코드의 양이 적다고 한 클래스에 헛소리를 잔뜩 집어넣지 마세요

리히터 대체 원리

1. 하위 클래스는 상위 클래스의 추상 메서드를 구현할 수 있지만 상위 클래스의 비추상 메서드를 재정의할 수는 없습니다.

2. 서브클래스는 고유한 메서드를 추가할 수 있습니다.

3. 하위 클래스의 메서드가 상위 클래스의 메서드를 재정의하는 경우 메서드의 전제 조건(즉, 메서드의 형식 매개변수)은 상위 클래스 메서드의 입력 매개변수보다 느슨합니다.

4. 하위 클래스의 메서드가 상위 클래스의 추상 메서드를 구현할 때 메서드의 사후 조건(즉, 메서드의 반환 값)은 상위 클래스의 사후 조건보다 더 엄격합니다.

한 문장 요약: 부모 클래스의 구현된 메서드를 다시 작성하지 마세요. 인터페이스 등 다른 메서드를 사용하여

종속성 역전 원칙

상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다. 세부 사항은 추상화에 의존해서는 안 됩니다.

다음은 설명을 위한 예입니다.

import java.util.LinkedList;  
import java.util.Queue;  
  
  
  
interface IEAT  
{  
    public void eat();//抽象吃这个动作  
}  
class EatApple implements IEAT  
{  
  
    @Override  
    public void eat()   
    {  
        //这里是吃苹果  
        System.out.print("eat a apple");  
          
    }  
}  
class EatWater implements IEAT  
{  
  
    @Override  
    public void eat() {  
        // 这里是吃水  
        System.out.print("dringk water");  
          
    }  
      
}  
public class Human  
{  
    public void dosomething(IEAT ieat)//我爱吃东西，吃什么呢，看传入什么  
    {  
        ieat.eat();  
    }  
    /* 
    public void dosomething(String food)//我爱吃东西，吃什么呢，看传入什么 
    { 
        if(food.equals("apple")) 
        { 
            //吃苹果 
        } 
        if(food.equals("water")) 
        { 
            //喝水 
        } 
    } 
    */  
    public static void main(String[] args)  
    {  
        Human human=new Human();  
        /* 
        human.dosomething("apple"); 
        human.dosomething("water"); 
         */  
        //给你吃个苹果  
        human.dosomething(new EatApple());  
        //再给你喝点水  
        human.dosomething(new EatWater());  
    }  
}

댓글은 일반적으로 사용되는 방법입니다. 이 방법은 확장에 매우 부적합합니다. 왜냐하면 바나나나 수박을 먹고 싶다면 dosomething에 많은 판단을 써야 하기 때문입니다. 쓰다보니 헷갈리네요.

한 문장으로 요약하자면: 추상적인 인터페이스를 사용하여 동일한 동작을 설명하고 동작을 구현하는 사람과 개체 간의 결합을 줄입니다.

인터페이스 격리 원칙

클라이언트는 자신이 사용하지 않는 인터페이스에 의존해서는 안 됩니다. 필요; 다른 클래스에 대한 클래스의 종속성은 가장 작은 인터페이스를 기반으로 해야 합니다.

문제의 원인: 클래스 A는 인터페이스 I를 통해 클래스 B에 종속되고, 클래스 C는 인터페이스 I을 통해 클래스 D에 종속됩니다. 인터페이스 I가 클래스 A와 클래스 B의 최소 인터페이스가 아닌 경우 클래스 B는 클래스 D는 필요하지 않은 메서드를 구현해야 합니다.

한 문장으로 요약하자면, 물고기와 인간처럼 물고기도 수영과 아가미 호흡이라는 두 가지 행동을 갖고 있고, 인간은 걷기와 먹기라는 두 가지 행동을 가지고 있습니다. 하나의 인터페이스에 4개의 액션을 작성할 수 없습니다. 특히 물고기와 인간을 위한 두 개의 인터페이스로 분할되어야 합니다.

데메테르의 법칙

데메테르의 법칙 알려진 원리는 1987년 미국 노스이스턴대학교의 이안 홀랜드(Ian Holland)가 처음 제안한 것이다. 평신도의 관점에서 보면 클래스가 자신이 의존하는 클래스에 대해 덜 알수록 좋습니다. 즉, 종속 클래스의 경우 로직이 아무리 복잡하더라도 로직은 최대한 클래스 내부에 캡슐화되어야 하며, 제공되는 퍼블릭 메소드 외에는 어떠한 정보도 외부로 유출되지 않습니다.

요약하면 다음과 같습니다. father1

이에 대해서는 말할 것도 없습니다. 기존 코드를 수정하기보다는 소프트웨어 엔터티의 동작을 확장하여 변화를 달성하려고 노력하십시오.