JAVA의 일반적인 디자인 패턴

이 기사는 주로 JAVA의 일반적인 디자인 패턴을 공유합니다. 필요한 친구는 한 번 살펴볼 수 있습니다.

저는 아주 일찍부터 디자인 패턴을 접했습니다. 오늘 몇몇 기사를 읽어보니 디자인 패턴을 배우고 이해하는 데 약간의 편차가 있는 것을 발견했습니다. 디자인 패턴은 특정 시나리오를 지원해야 하며 이전 경험에서 요약된 코드 솔루션 아이디어입니다. 이 솔루션 아이디어는 코드 간의 결합을 낮추고 중복성을 줄이는 방법을 고려하여 코드를 결합하는 목적은 프로그램의 더 나은 확장을 위한 것입니다. 소위 더 나은 확장이란 기능이 변경되거나 확장될 때 가능한 한 적은 변화를 유발하는 것을 말합니다. 따라서 디자인 패턴을 학습할 때, 프로그램의 확장을 시뮬레이션하여 이전에 요약한 디자인 패턴과 기존 코드의 차이점을 비교하는 것이 좋은 학습 방법이어야 하며, 그 장점을 진정으로 이해해야만 그 본질을 완전히 이해할 수 있습니다. .

Creative Pattern

Creative Pattern은 객체의 인스턴스화 프로세스를 추상화하여 시스템이 해당 객체가 생성, 구성 및 표현되는 방식에 독립적이도록 도와줍니다.

추상 팩토리 패턴

추상 팩토리 패턴은 다양한 제품군으로 구성된 공장을 만드는 데 사용됩니다. 이른바 제품군은 여러 개체의 값이 개체에 상대적입니다. 동일한 인터페이스를 구현하므로 동일한 제품군의 개체는 확실히 동일한 인터페이스를 구현하지 않습니다.

추상 팩토리 패턴에는 유형 A 추상 역할과 유형 A 특정 역할(AbstractProductA, ProductA), 유형 B 추상 역할과 유형 B 특정 역할(AbstractProductB, ProductB)의 7가지 주요 역할이 포함되며 추상 팩토리(AbstractFactory)는 유형 A를 제공합니다. 제품 클래스 B 제품의 두 가지 메소드 인터페이스를 사용하여 콘크리트 팩토리(ConcreteFactory)는 추상 팩토리의 두 가지 메소드 인터페이스를 구현합니다. 두 메소드 인터페이스의 구현은 서로 다른 제품 A와 B에 따라 다릅니다(createProductA는 구현 클래스에서 구현을 선택합니다.) 제품 A 클래스의 createProductB는 제품 B)의 구현 클래스에서 구현 클래스를 선택합니다. 고객은 추상 팩토리의 특정 구현 클래스에 의존하여 특정 팩토리의 제품군 제품을 생산합니다.

추상 팩토리 패턴은 여러 제품에 대한 제품군 팩토리 제공을 구현하고 여러 제품의 다차원 조합을 실현합니다. 제품군의 대표적인 예는 UnixButton 및 WindowsButton입니다. 다양한 제품 조합을 위해 공장에서 제공됩니다. 확장 관점에서 볼 때 콘크리트 팩토리는 추상 팩토리를 구현합니다. 새로운 제품군이 필요한 경우 다른 제품군을 구현하면 핫 스와핑이 실현됩니다. 공장 모델을 비교하면, 콘크리트 공장은 제품을 마주하고, 추상적인 공장은 일련의 제품을 마주합니다.

Builder Pattern

빌더 패턴의 역할은 객체의 구성 단계를 추상화하여 객체의 구성 프로세스를 쉽게 다시 작성할 수 있도록 하는 것입니다.

빌더 패턴에는 빌더 인터페이스(Builder), 콘크리트 빌더(ConcreteBuilder), 제품 객체(Product) 및 디렉터 클래스(Director)의 4가지 주요 역할이 포함됩니다. Director 클래스의 생성 메소드는 어셈블리를 위한 추상 빌더의 여러 buildPart 메소드를 호출하는 역할을 합니다. Builder 인터페이스는 구상 빌더가 구현할 여러 부분 생성 프로세스 buildPart() 메소드와 생성 결과 메소드 검색결과() 메소드를 정의합니다. 생성 방법 및 결과 반환 방법에서 특정 빌더는 해당 어셈블리 작업을 완료하고 검색 결과를 사용하여 해당 어셈블리 결과를 얻습니다.

목적 관점에서 빌더 패턴은 객체의 다양한 조립 방법을 가장 간단하게 구현합니다. 조립 순서는 디렉터 클래스에 의해 제어되며 특정 조립 작업은 다양한 빌더, 디렉터 클래스 및 관리자의 손에 분산됩니다. 추상 빌더. 집계 관계를 통해 제품 구성의 실제 작업을 핫스왑 가능하게 만들어 특정 빌드 구현을 더 쉽게 확장하거나 교체할 수 있습니다. 반면에 Director 클래스를 사용하여 제품을 직접 조작하여 제품 조립 과정을 구현하고, 구성 과정을 변경해야 하는 경우 Director 클래스를 수정해야 하는데, 이는 우리가 보고 싶지 않은 것입니다. .

구조적 패턴

구조적 패턴은 확장성 및 캡슐화와 같은 특정 목적을 달성하기 위해 기존 클래스를 조립하고 클래스 간의 상호 작용을 설계하는 방법에 중점을 둡니다.

어댑터 패턴

어댑터 패턴의 목적은 클래스의 메서드 인터페이스를 다른 클라이언트에서 사용할 다른 메서드 인터페이스로 변환하는 것입니다.

어댑터 패턴에는 클라이언트에 필요한 대상 인터페이스(Target)와 해당 메서드 SampleOperation(), Target 인터페이스를 상속하는 실제 실행자인 Adaptee 클래스, 그리고 상속이라는 세 가지 주요 역할이 포함되어 있습니다. Adapter의 SampleOperation 메소드인 Adaptee는 Adptee의 SampleOperation 메소드를 호출합니다. 실제로 Adaptee 클래스 메서드는 상속 또는 직접 종속성을 통해 호출될 수 있습니다. 전자를 클래스 어댑터라고 하고 후자를 개체 어댑터라고 합니다.

어댑터 패턴은 한 인터페이스에서 다른 인터페이스로의 호환성 변환을 구현합니다. 확장성에는 특별한 것이 없습니다.

데코레이터 패턴

데코레이터 패턴은 패키징 패턴이라고도 합니다. 그 목적은 원래 상속 관계를 변경하지 않고 클래스의 기능을 동적으로 확장하는 것입니다. 여기에 언급된 확장 클래스의 기능은 기존 메서드를 변경하거나 더 많은 메서드를 제공할 수 있습니다.

데코레이터 패턴에는 시스템에 이미 존재하는 상속 관계, 컴포넌트 인터페이스(Component) 및 해당 구현 클래스(ConcreteComponent)라는 4가지 주요 역할이 포함되어 있습니다. 데코레이터(Decorator)는 컴포넌트 인터페이스를 구현하고 특정 구현 클래스에 따라 다릅니다. SampleOperation() 메서드는 장식되는 특정 구성 요소 클래스의 SampleOperation() 메서드에 따라 달라지며, 특정 데코레이터(ConcreateDecorator)는 Decorator에서 상속되며, 이는 다른 메서드를 추가하거나 해당 샘플Operation 메서드를 수정하여 다음을 달성할 수 있습니다. 원래 클래스를 변경하지 않고 동일한 동적 메서드 확장을 구현하는 것이 목표이며 이 확장은 클라이언트에 투명합니다.

확장 관점에서 Decorator는 원본 ConCreteComponent를 교체하여 상속의 동적 확장을 완료합니다. ConcreteComponent에서 직접 상속하는 것과 비교하여 이 메서드는 종속성이 적고 해당 데코레이팅된 개체도 동적으로 삽입할 수 없습니다. 장식 클래스의 존재를 알아야 하므로 복잡한 클래스 관계를 유지할 필요가 없습니다.

애플리케이션의 구체적인 예는 BufferInputStream과 FileInputStream 간의 관계입니다. InputStream은 Component이고, FileInputStream, ByteArrayInputStream 등은 BufferInputStream 등이 FilterInputStream에서 상속된 특정 데코레이터입니다.

프록시 패턴

프록시 패턴의 목적은 객체에 대한 프록시를 제공하는 것입니다. 프록시 객체는 원래 기능을 향상, 수정 또는 삭제할 수도 있습니다.
프록시 모드는 매우 널리 사용되므로 다른 블로그에서 프록시 모드에 대해 자세히 설명했으며 여기서는 중복되지 않습니다.

구조적 패턴

구조적 디자인 패턴은 클래스나 객체 간의 책임 분배에 중점을 두고, 여러 클래스나 객체가 효율적으로 협력하여 작업을 완료할 수 있는 방법을 연구합니다.

Observer Pattern

Observer 패턴의 목적은 일대다 종속 관계를 구현하여 토픽이 업데이트될 때 특정 방식으로 토픽에 바인딩된 관찰자에게 업데이트를 알릴 수 있도록 하는 것입니다.

옵저버 패턴에는 4개의 참가자, 토픽 인터페이스 및 특정 구현 토픽(Subject, ConcreteSubject), 옵저버 및 구체적인 옵저버(Observer, ConcreateObserver)가 포함됩니다. Observer는 Aggregation을 통해 Subject에 등록됩니다. 종속성 정의 인터페이스로 인해 특정 주제는 서로 다른 알림 전략을 구현할 수 있으며 특정 관찰자와 특정 주제 간에 낮은 결합 종속성이 달성될 수 있습니다.
Attach 및 Detach 메서드를 통해 둘 사이의 종속성을 설정하고 해제할 수 있습니다. 주체의 상태가 변경되면 통지Observer를 통해 모든 관찰자에게 알리고 해당 관찰자의 업데이트 메서드를 호출할 수 있습니다.
확장 관점에서 관찰자 패턴의 장점은 새로운 관찰자를 추가할 때 관찰자 인터페이스만 구현한 다음 모니터링하려는 특정 대상에 연결하여 유사하게 추가하면 된다는 것입니다. 주제 삭제 관찰자 중 한 명이 핫 스와핑을 구현하려면 연결 메소드만 호출하면 됩니다. 이 설계 방법을 채택하지 않으면 어느 쪽도 인터페이스를 사용할 수 없어 한쪽을 추가하는 데 어려움을 겪게 됩니다.

Mediator 패턴

Mediator 패턴의 역할은 중간 개체를 사용하여 일련의 개체의 상호 작용을 캡슐화하여 각 개체의 상호 작용에 명시적인 상호 의존성이 필요하지 않도록 하는 것입니다. 간단히 말하면, 다대다 메시 연관에서 서로 다른 객체 간의 상호 작용을 일대다 별 연관으로 변환하는 것입니다.

중개자 패턴은 네 가지 주요 역할로 구성됩니다. 중재자 인터페이스(Mediator)는 공개 상호 작용 메서드()를 정의합니다. 구체적인 중재자(ConcreteMediator)는 특정 상호 작용 메서드()를 구현하고 필요한 정보를 얻습니다. 동료의 참조, 변경된() 메소드의 구체적인 구현은 보유된 동료 참조에 따라 다릅니다. 동료 추상 클래스(Colleague)는 동료 인터페이스와 중재자 인터페이스 간의 연관을 정의하고 이를 얻기 위한 인터페이스 메소드를 제공합니다. 중재자, 특정 동료 구현 클래스는 주로 특정 대화형 작업을 구현하기 위해 여러 개(ConcreteColleague)가 있을 수 있습니다. 대화형 작업은 관련 중개자의 변경된 방법에 따라 달라집니다. 일대다 관계가 된 이유는 위의 네 가지 역할의 관계로 판단하면 각 동료는 중재자에 대한 참조를 갖고 있으며 각 중재자는 모든 대학에 대한 참조를 보유하고 있습니다.

중개자 패턴의 장점은 복잡한 시스템 객체의 상호 작용을 분리하여 칼리지를 추가하거나 삭제할 때 중간 중재자만 수정하면 된다는 것입니다. 중재자는 다른 특정 중재자로 대체될 수도 있으며 해당 대화형 동작을 대체할 수도 있습니다. 단점은 상호작용이 필요한 동료의 수가 계속 늘어나는 만큼 특정 중개자의 수도 계속 늘어날 것이라는 점이다.

위 내용은 JAVA의 일반적인 디자인 패턴의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!