디자인 패턴의 6 가지 원칙의 개방 및 폐쇄 원칙과 단일 책임 원칙에 대한 자세한 설명

디자인 모드의 6 가지 원칙-개폐 원칙과 단일 책임 원칙에 대한 자세한 설명


1. OCP (Open Close Principle)

  • 개념

    열기 및 닫기 원칙의 핵심은 확장을 위해 개방하고 수정을 위해 폐쇄하는 것 입니다. 그 목적은 프로그램의 확장 성을 향상시키고 핫 플러깅을 실현하는 것입니다. 즉, 요구 사항이 변경 될 때마다 원본 코드를 수정하지 않고 수정할 수 있습니다. 수정 . 요구를 충족하기 위해 새로운 기능을 확장합니다.

  • 간단한 케이스

    도서 판매 사업 :

    다음 범주를 사용할 수 있습니다.

    1. Book이 인터페이스에는 가격, 책 제목, 저자, 기본 getter 및 setter 메소드와 같은 속성이 포함됩니다.

    public interface Book {
          
          
        String getName();
        int getPrice();
        String getAuthor();
    }
    

    2. 클래스 NovelBook(小说)구현Book

    public class NovelBook implements IBook{
          
          
        private String name;
        //为了防止精度丢失,这里用原有的价格*100的整数来保存
        private int price;
        private String author;
    
        public NovelBook(String name, int price, String author) {
          
          
            this.name = name;
            this.price = price;
            this.author = author;
        }
    
        @Override
        public String getName() {
          
          
            return this.name;
        }
    
        @Override
        public int getPrice() {
          
          
            return this.price;
        }
    
        @Override
        public String getAuthor() {
          
          
            return this.author;
        }
    }
    

    3. BookStore서점

    private static ArrayList<IBook> bookList=new ArrayList<>();
    
        static {
          
          
            bookList.add(new OffNovelBook("红楼梦", 9900, "曹雪芹"));
            bookList.add(new OffNovelBook("侠客行", 8900, "金庸"));
            bookList.add(new OffNovelBook("原则", 6900, "瑞达利欧"));
            bookList.add(new OffNovelBook("海贼王1", 4900, "尾田荣一郎"));
        }
    
        public static void main(String[] args) {
          
          
            System.out.println("卖书的记录如下----------------------");
            for (IBook book : bookList) {
          
          
                System.out.println("书籍名称:"+book.getName()+"\t\t作者:"+book.getAuthor()+"\t\t价格:¥"+book.getPrice()/100.0+"元");
            }
        }
    }
    

    이제 다음과 같은 새로운 수요가 있습니다.

    Double Eleven 때문에 70 위안 이상 도서 20 %, 70 위안 미만 도서 10 % 할인이 필요한데, 지금이 수요를 어떻게 충족해야할까요? 생각하기가 더 쉽습니다. ① NovelBook이 클래스의 getPrice메서드를 수정 합니다. Book인터페이스에 새 메서드를 추가합니다. 위의 두 가지 방법은 다소 부적절합니다. 첫째, getPrice방법 을 수정하면 다른 곳에서 책의 정상 가격을 얻으려는 경우 만족하지 못하여 원래 기능변경됩니다 . 메서드가 인터페이스에 추가되면이 메서드를 모든 구현 클래스에 추가 해야하므로 수정해야하는 위치더 많아 집니다 . 위에서 발생한 문제에 대해 개폐 원칙과 결합하여 추가 할인을 추가 할 수 있습니다. 할인 된 가격을받을 수 있도록 방법을 OffNovelBook계승 NovelBook하고 재 작성 하는 새로운 카테고리 , getPrice이러한 방식으로 원래 비즈니스에 영향을주지 않고 새로운 수요를 충족시킵니다.

    코드 쇼 :

    public class OffNovelBook extends NovelBook{
          
          
    
        public OffNovelBook(String name, int price, String author) {
          
          
            super(name, price, author);
        }
    
        @Override
        public int getPrice() {
          
          
            int sellPrice=super.getPrice();
            int offPrice=0;
            if(sellPrice>7000){
          
          
                offPrice=sellPrice*90/100;
            }else{
          
          
                offPrice=sellPrice*80/100;
            }
            return offPrice;
        }
    }
    
  • 요약하자면 :

    이점:

    1. 소프트웨어 테스트 촉진

    원래 코드가 수정되지 않았기 때문에 매번 새 코드 만 테스트하면됩니다.

    2. 코드 재사용 성 향상

    세분화가 적을수록 재사용 가능성이 높아집니다.

    3. 소프트웨어 유지 보수성 향상

    매번 새로운 기능 만 확장하고 원래 기능에 큰 영향을주지 않기 때문에 개폐 원칙을 준수하는 소프트웨어로 안정성이 강하고 유지 관리가 용이합니다.


2. 단일 책임 원칙 (Single Responsibility Principle, SRP)

  • 개념:

    이름에서 알 수 있듯이 클래스는 변경 이유가 하나만 있어야합니다 (즉, 다른 책임과 관련된 이유 만) . 목적은 복잡성을 줄이고 가독성 및 유지 관리 성을 향상시키는 것 입니다. 한 사람이 여러 역할을하고 한 사람이 하나의 팀인 것처럼 간단 해 보이지만 분명히 그 사람을 매우 피곤하게 만들 것입니다. 관련된 모든 것이 관련되어있는 한 그에게. 특별한 설명이 필요한 것은 책임 분담에 대한 고유 한 해결책이 없기 때문에 모든 사람이 상황에 따라 어떻게 분담할지 결정할 수 있다는 것입니다.

  • 간단한 경우 :

    호출 기능을 구현하십시오.

    Phone전화 걸기, 전화 걸기 및 전화 끊기의 여러 방법을 정의하는 인터페이스

    public interface Phone {
          
          
        //拨号
    	void dial(String phoneNumber);
        //通话
    	void chat(Object obj);
        //挂断
        void hangup();
    }
    

    간단히 분석 :

    위에 쓰여진 단점 :

    1. 클라이언트가 책임 중 하나만 필요한 경우 불필요한 다른 책임을 포함해야하므로 코드 중복이 발생합니다.

    2. 특정 책임의 변경은이 클래스가 다른 책임을 수행하는 능력을 유발할 수 있으며, 평신도 입장에서는 짧은 시간 동안 너무 바쁠 수 있습니다.

    세심한 분석 결과 전화 걸기 및 전화 끊기의 두 가지 방법이 프로토콜과 관련이 있고 통화가 데이터 전송과 관련되어 있음을 찾기가 어렵지 않으므로 분석에 따라 책임을 나눌 수 있습니다.

    public interface DataTransfer {
          
          
        void chat(Object obj);
    }
    
    public interface ConnectionManger {
          
          
        void dial(String phoneNumber);
        void hangup();
    }
    

  • 요약하자면

    이점:

    1. 복잡성 감소

    클래스는 하나의 책임 만 담당하며 논리는 비교적 간단합니다.

    2. 가독성 향상

    복잡성 감소, 가독성 향상

    3. 유지 보수성 향상

    가독성이 향상됨에 따라 유지 보수성도 향상됩니다.

    4. 변경으로 인한 위험 감소

    단일 책임 원칙에 따라 기능이 수정되면 다른 기능에 미치는 영향이 크게 감소합니다.

추천

출처blog.csdn.net/weixin_44829930/article/details/109722654