디자인 패턴

디자인 패턴(Design Pattern)은 대부분의 사람들에게 알려져 있는, 반복적으로 사용되는 코드 디자인 경험을 분류하고 정리한 집합입니다. 디자인 패턴을 사용하는 목적은 코드를 재사용하고, 다른 사람이 코드를 더 쉽게 이해할 수 있도록 하며, 코드 신뢰성을 보장하는 것입니다. 디자인 패턴이 우리 자신과 다른 사람, 그리고 시스템 모두에게 윈윈(win-win)이라는 것은 의심의 여지가 없습니다. 디자인 패턴은 코드 작성을 진정한 엔지니어링으로 만듭니다. 디자인 패턴은 건물의 구조와 마찬가지로 소프트웨어 엔지니어링의 초석입니다.

디자인 패턴(영어 디자인 패턴)은 객체 지향 디자인에서 반복되는 문제에 대한 솔루션입니다. 이 용어는 1990년대 Erich Gamma 등에 의해 건축 디자인 분야에서 컴퓨터 과학에 도입되었습니다. 이 용어의 의미는 논란의 여지가 있습니다. 알고리즘은 디자인 문제보다는 문제 해결을 다루기 때문에 디자인 패턴이 아닙니다. 디자인 패턴은 일반적으로 서로 밀접하게 상호 작용하는 클래스 및 개체 집합을 설명합니다. 디자인 패턴은 숙련된 디자이너의 디자인 경험을 초보자와 다른 디자이너가 이해할 수 있도록 소프트웨어 디자인을 논의하기 위한 공통 언어를 제공합니다. 디자인 패턴은 소프트웨어 리팩토링의 목표도 제공합니다.

소프트웨어 개발 커뮤니티에서 디자인 패턴에 대한 관심이 높아짐에 따라 일부 관련 논문이 출판되고 해당 세미나가 정기적으로 개최되었으며 Ward Cunningham은 디자인 패턴에 대한 경험을 교환하기 위해 WikiWiki를 발명했습니다.

팁: 이 튜토리얼에서는 Java 예제를 통해 디자인 패턴의 개념을 단계별로 설명합니다. 따라서 Java 지식에 대해 알아야 합니다.

표현형식

소프트웨어 디자인 패턴을 표현하는 형식은 저작자에 따라 다르며, 구분과 명칭도 다릅니다. 일반적으로 사용되는 GoF 설명 패턴의 형식은 대략 다음과 같은 부분으로 나뉩니다.

• 패턴 이름: 각 패턴에는 고유한 이름이 있으며, 패턴 이름을 통해 디자인에 대해 논의할 수 있습니다.

• 문제: 객체 지향 시스템 설계 중에 반복되는 특정 상황이 있으며 이로 인해 특정 패턴을 채택하게 됩니다.

• 해결책: 위 문제에 대한 해결책인 콘텐츠는 디자인의 다양한 구성 요소, 관계, 책임 분할 및 협업 방법을 제공합니다.

• 별칭: 패턴은 둘 이상의 이름을 가질 수 있습니다. 이 섹션에서는 이러한 이름을 기록해야 합니다.

• 동기: 이 모드를 사용하는 경우 이 섹션에 제공된 솔루션(문제 및 내용 포함)에 대한 책임이 있습니다.

• 적용성: 패턴이 적용되는 상황, 패턴의 배경 등

• 구조: 일반적으로 사용되는 클래스 다이어그램과 상호 작용 다이어그램의 이 부분이 이 패턴을 보여줍니다.

• 참여자: 이 섹션에서는 이 패턴에 사용되는 클래스 및 객체 목록과 이들이 디자인에서 수행하는 역할을 제공합니다.

• 협력: 이 모드에서 클래스와 개체 간의 상호 작용을 설명합니다.

• 영향: 이 모델을 채택하면 시스템의 확장성 및 이식성에 미치는 영향과 같이 소프트웨어 시스템의 다른 부분에 미치는 영향. 영향에는 부정적인 영향도 포함됩니다. 이 섹션에서는 이 패턴 사용의 결과, 부작용 및 장단점을 설명해야 합니다.

• 구현: 이 섹션에서는 패턴 구현, 패턴에 대한 부분 솔루션, 패턴 구현을 위해 가능한 기술 또는 제안 사항을 설명해야 합니다. 구현 패턴 방법.

• 예: 프로그래밍 언어에서 패턴을 사용하는 방법을 간략하게 설명합니다.

• 알려진 응용 프로그램: 업계에 알려진 구현 사례입니다.

• 관련 패턴: 이 섹션에는 다른 관련 패턴뿐만 아니라 다른 유사한 패턴과의 차이점도 포함되어 있습니다.

팁: 디자인 패턴 튜토리얼은 디자인 패턴에 대한 모든 것을 배우는 데 도움이 됩니다. 궁금하신 점은 PHP 중국어 커뮤니티에 가셔서 질문해주시면 열성적인 네티즌들이 답변해드리겠습니다.

패턴 원칙

모두가 디자인 패턴에 관심을 갖기 시작했습니다. 그렇다면 우리는 왜 디자인 패턴을 사용하는 걸까요? 왜 우리는 그렇게 많은 디자인 패턴으로 디자인해야 할까요?

솔직히 예전에는 잘 이해가 안 됐어요. 모두가 "디자인 패턴"을 반복하는 모습을 보는 것만으로도 조금 약해지는 느낌이 듭니다. 그래서 "Gang of Four"의 디자인 패턴에 관한 책을 샀는데 전혀 이해하지 못한 것으로 나타났습니다. 읽을 때는 이해하는 것 같았지만 잠시 후에 잊어 버렸습니다. . 어쩌면 제가 상대적으로 '멍청'하기 때문일 수도 있습니다 :)) 최근에 저는 몇 가지 통찰력을 얻었습니다. "함께 즐기는 것보다 혼자 즐기는 것이 낫다"라는 말을 여러분과 공유하고 싶은데, 조언을 해주시면 좋겠습니다!

왜 "디자인 패턴"을 옹호해야 할까요? 근본적인 이유는 코드를 재사용하고 유지보수성을 높이기 위함입니다.

그렇다면 코드 재사용을 어떻게 달성할 수 있을까요? OO 세계에는 "Open Closed Principal" 원칙, Liskov 대체 원칙, 합성 및 재사용 원칙 등 이전 모델의 몇 가지 원칙이 있습니다. 디자인 패턴은 코드 재사용을 달성하고 유지 관리성을 높이기 위해 이러한 원칙을 구현합니다.

• 개방-폐쇄 원칙

이 원칙은 "Bertrand Meyer"가 제안했습니다. 원본 텍스트는 "소프트웨어 엔터티는 확장을 위해 열려 있어야 하지만 수정을 위해서는 닫혀 있어야 합니다"입니다. 즉, 모듈은 확장을 위해 열려 있어야 하지만 수정을 위해서는 닫혀 있어야 합니다. 모듈은 원본("원본", 원본 코드 참조) 코드를 수정하지 않고 확장을 시도해야 합니다. 그렇다면 어떻게 확장할 것인가? "공장 패턴"을 살펴보겠습니다. 중관촌에 불법 복제 디스크와 포르노 영화를 판매하는 사람이 있다고 가정해 보겠습니다. 우리는 그를 위해 "CD 판매 관리 소프트웨어"를 설계합니다. 먼저 "CD" 인터페이스를 디자인해야 합니다. 그림과 같이: [pre]______________|<>|| CD ||_____________||+Sell() || ||_____________|[/pre] 그리고 불법 복제된 디스크와 포르노 영화가 그 하위 범주입니다. 소년은 "DiscFactory"를 통해 이러한 디스크를 관리합니다. 코드는 다음과 같습니다.

publicclassDiscFactory{
publicstatic光盘
getDisc(Stringname){
return(光盘)Class.forName(name).getInstance();
}
}

누군가 불법 복제 디스크를 사고 싶은데 어떻게 해야 하나요?

public class boy { public static void main(String[] args){ CD d=DiscFactory.getDisc("Pirate Disc"); CD.Sell() } }

언젠가 이 소년의 양심이 알게 된다면, 정품 소프트웨어 판매를 시작하세요. 그것은 중요하지 않습니다. "정품 소프트웨어"라는 "CD"의 또 다른 하위 범주를 생성하면 됩니다. 원래 구조와 코드를 수정할 필요가 없습니다. 어때요? 확장을 위해 열려 있고 수정을 위해 닫혀 있습니다. "개방-폐쇄 원칙" 팩토리 패턴은 특정 제품을 확장합니다. 일부 프로젝트에서는 더 많은 확장성이 필요할 수 있습니다. 이 "팩토리"를 확장하려면 "추상 팩토리 패턴"이 됩니다.

• 리히터 치환 원리

리스코프 대체 원칙은 "Barbara Liskov"가 제안했습니다. 상위 클래스가 호출되면 하위 클래스로 변경되어 실행될 수 있습니다. 예: CD d=new 불법 복제 디스크(); d.sell(); "해적 디스크" 범주를 "포르노 영화" 범주로 변경하려는 경우 문제 없이 완전히 실행될 수 있습니다. Java 컴파일러는 프로그램이 Liskov 대체 원칙을 준수하는지 확인합니다. 아직도 자바 상속의 원칙을 기억하시나요? 하위 클래스의 재정의 메서드에 대한 액세스 권한은 상위 클래스의 해당 메서드에 대한 액세스 권한보다 작을 수 없습니다. 예를 들어, "CD"의 "Sell" 메소드에 대한 액세스 권한이 "public"인 경우 "Pirate Disc" 및 "Raw Film"의 "Sell" 메소드는 보호되거나 비공개로 설정될 수 없으며 편집이 통과되지 않습니다. 왜 이렇게 되어야만 하는가? 생각해 보십시오: "해적판 디스크"의 "판매" 방법이 비공개인지 여부. 그러면 다음 코드를 실행할 수 없습니다. CD d=new 불법 복제된 disk(); d. Liskov 대체 원칙은 상속 및 재사용의 기초라고 할 수 있습니다.

• 구성 및 재사용의 원칙

은 상속을 덜 사용하고 구성 관계를 더 많이 사용한다는 의미입니다. 저는 다음과 같은 프로그램을 작성한 적이 있습니다. 데이터베이스를 처리해야 하는 클래스가 여러 개 있으므로 데이터베이스 작업을 위한 클래스를 작성하고 데이터베이스를 처리하는 다른 클래스가 이를 상속합니다. 그 결과 나중에 데이터베이스 연산 클래스의 메소드를 수정하게 되었고, 모든 클래스를 수정해야 했습니다. "하나의 움직임이 몸 전체에 영향을 미친다"! 객체 지향은 변동을 가능한 한 가장 작은 범위로 제한하는 것입니다.

Java에서는 구현 클래스보다는 인터페이스에 대한 프로그래밍을 시도해야 합니다. 이렇게 하면 하위 클래스를 변경해도 해당 메서드를 호출하는 코드에 영향을 주지 않습니다. 각 카테고리는 다른 사람과의 접촉을 최대한 최소화하고, "낯선 사람과 대화하지 마세요." 이렇게 하면 성문에 불이 붙더라도 연못에 있는 물고기에게 해를 끼치지 않습니다. 확장성과 유지보수성이 향상될 수 있을 때에만

이러한 원칙을 이해하고 디자인 패턴을 살펴본 후 특정 문제에 대해 이러한 원칙을 어떻게 구현하는지에 관한 것입니다. Zhang Wuji는 태극권을 배우고 모든 동작을 잊어 버리고 "두 장로 Xuan Mi"를 물리 쳤다고합니다. 디자인 패턴은 트릭이라고 할 수 있습니다. 먼저 모든 패턴을 학습한 다음 모든 패턴을 잊어버리고 원하는 대로 하면 OO의 최고 상태라고 할 수 있습니다. 하하, 웃겨, 웃겨! (JR)

종속성 반전 원칙 추상화는 세부 사항에 의존해서는 안 됩니다. 세부 사항은 구현 프로그래밍이 아닌 인터페이스용

• 종속성 반전 원칙

에 따라 프로그래밍되어야 합니다. 매개변수를 전달할 때 또는 결합된 집계 관계에서 더 높은 수준의 클래스를 참조하십시오. 주된 이유는 객체를 생성할 때 다양한 구체적인 객체가 동적으로 생성될 수 있다는 것입니다. 물론 일부 구체적인 클래스가 상대적으로 안정적이라면 추상 클래스를 상위 클래스로 만들 필요가 없습니다. 이는 인터페이스 격리 원칙에 따른 불필요한 작업입니다. 서비스 예, 모든

• 인터페이스 격리의 원리

역할, 더도 말고 덜도 말고, 하지 말아야 할 일을 하세요, 추상 클래스, 추상 클래스는 하지 않습니다. 인스턴스가 있습니다

• 추상 클래스

클래스는 하위 클래스에 의해 상속되며 일반적으로 이 시스템의 공통 속성과 메서드를 포함합니다. 참고: 좋은 상속 관계에서는 리프 노드만 구체적 클래스여야 하고 다른 노드는 추상 클래스여야 합니다. 즉, 구체적 클래스는 상속되지 않습니다. 가능한 한 많은 공통 코드를 추상 클래스에 넣으십시오. 7 데메테르의 최소 지식 법칙 원리. 낯선 사람과 이야기하지 마십시오.

본 디자인 패턴 튜토리얼 매뉴얼에서 다루는 내용

이 디자인 패턴 튜토리얼은 Factory Pattern, Abstract Factory Pattern, Singleton Pattern, Builder Pattern(Builder Pattern), Prototype Pattern(Prototype Pattern), 등.

팁:이 튜토리얼의 각 장에는 디자인 패턴을 더 잘 배우고 이해하는 데 도움이 되는 많은 Java 예제가 포함되어 있습니다.