이 글에서는 java에 대한 관련 지식을 소개합니다. 주로 몇 가지 일반적인 디자인 패턴을 소개합니다. 디자인 패턴은 반복적으로 사용된 코드 디자인 경험의 집합입니다. 목적은 코드를 다른 사람들이 더 쉽게 만들 수 있도록 하는 것입니다. 코드의 신뢰성을 이해하고 보장하는 것이 모든 사람에게 도움이 되기를 바랍니다.
추천 학습: "java tutorial"
디자인 패턴은 반복적으로 사용되어 온 코드 디자인 경험의 집합입니다. 목적은 코드를 재사용하고, 다른 사람이 코드를 더 쉽게 이해할 수 있도록 하며, 코드의 신뢰성을 보장하는 것입니다. 디자인 패턴은 우리 자신, 사람, 시스템 모두에게 윈윈(win-win)입니다. 이는 건물의 벽돌과 마찬가지로 소프트웨어 엔지니어링의 초석입니다. 프로젝트에서 디자인 패턴을 합리적으로 사용하면 많은 문제를 완벽하게 해결할 수 있습니다. 각 패턴에는 실제로 그에 상응하는 원칙이 있습니다. 각 패턴은 우리 주변에서 계속해서 반복되는 문제와 문제 해결의 핵심을 설명합니다. 널리 사용됩니다. 일반적으로 디자인 패턴은 세 가지 주요 범주로 나뉩니다.
- 창의적 패턴: 총 5개: 팩토리 메소드 패턴, 추상 팩토리 패턴, 싱글턴 패턴, 빌더 패턴, 프로토타입 패턴
- 구조 패턴: 총 7개 유형: 어댑터 모드, 데코레이터 모드, 프록시 모드, 브리지 모드, 등장 모드, 조합 모드, 플라이웨이트 모드
- 행동 모드: 총 11가지 유형: 전략 모드, 템플릿 메소드 모드, 관찰자 모드, 책임 체인 모드, 액세스 중재자 모드, 중개자 모드 , 반복자 모드, 명령 모드, 상태 모드, 메모 모드, 해석기 모드
실제로 동시 모드와 스레드 풀 모드의 두 가지 유형이 있습니다. 전체를 설명하려면 그림을 사용하십시오.
(1) 개방형 폐쇄 원칙:
개방형 및 폐쇄형 원칙은 확장을 위해 개방되고 수정을 위해 폐쇄되는 것을 의미합니다. 프로그램을 확장할 때 원본 코드를 수정할 수 없습니다. 이 효과를 얻으려면 인터페이스나 추상 클래스를 사용해야 합니다.
(2) 종속성 반전 원리:
종속성 반전 원리는 열기 및 닫기의 기초입니다. (3) Liskov 대체 원칙:
Liskov 대체 원칙은 상속과 재사용의 초석입니다. 시스템은 영향을 받지 않고 기본 클래스를 재사용할 수 있으며 하위 클래스는 기본 클래스에 새로운 동작을 추가할 수도 있습니다. 따라서 Liskov 대체 원칙은 기본 클래스가 나타날 수 있는 모든 곳에 하위 클래스가 나타나야 함을 의미합니다.
Liskov 대체 원칙은 "개폐 원칙"을 구현하는 핵심 단계는 추상화이며 기본 클래스와 하위 클래스 간의 상속 관계는 추상화의 구체적인 구현입니다. , 그래서 Liskov 대체 원칙은 추상화를 달성하기 위한 특정 단계의 사양입니다.(4) 인터페이스 분리 원칙:
단일 인터페이스를 사용하는 것보다 여러 개의 격리된 인터페이스를 사용하는 것이 더 좋으며, 인터페이스 간의 결합 및 종속성을 줄여 업그레이드 및 유지 관리가 더 쉽습니다.
( 5) 데메테르 원칙:
가장 잘 알려지지 않은 원칙이라고도 알려진 데메테르 원칙은 클래스가 다른 엔터티와의 상호 작용을 최소화하여 시스템 기능 모듈을 상대적으로 독립적으로 만들고 결합 관계를 줄여야 함을 나타냅니다. 이 원칙의 원래 의도는 클래스의 결합을 줄이는 것입니다. 비록 간접적인 클래스와의 통신은 피할 수 있지만 "중개자"를 통해 통신이 이루어져야 합니다. Demeter 원칙을 과도하게 사용하면 많은 수의 중개자가 생성되고 클래스 통과로 이어집니다. 시스템이 더 복잡해지기 때문에 Dimit의 법칙을 사용할 때는 명확한 구조와 높은 응집력 및 낮은 결합도를 모두 달성하기 위해 반복적으로 절충점을 고려해야 합니다.
(6) 복합 재사용 원칙:
상속 대신 조합/집계를 사용해 보세요.
2. 자바의 23가지 디자인 패턴: 다음으로는 자바의 23가지 디자인 패턴에 대한 개념, 응용 시나리오 등을 자세히 소개하고, 그 특징과 디자인 패턴의 원리를 바탕으로 분석하겠습니다1. 타입 팩토리 메소드 패턴 생성:
(1) 단순 팩토리 패턴:
팩토리 클래스를 생성하고 인터페이스를 정의하여 동일한 인터페이스를 구현하는 제품 클래스를 생성합니다. 먼저 관계 다이어그램을 살펴보세요:
(2) 팩토리 메소드 패턴:
팩토리 메소드 패턴은 단순 팩토리 패턴을 개선한 것입니다. 단순 팩토리 패턴의 단점은 표준을 준수하지 않는다는 것입니다. "개폐 원리". 새로운 제품 클래스가 나올 때마다 공장 클래스의 수정이 필요하며 이는 시스템 확장 및 유지 관리에 도움이 되지 않습니다. 팩토리 메소드는 팩토리를 추상화하고 객체 생성을 위한 인터페이스를 정의합니다. 새 제품을 추가할 때마다 제품과 해당하는 특정 구현 팩토리 클래스만 추가하면 됩니다. 특정 팩토리 클래스는 인스턴스화할 제품을 결정하고 하위 클래스에 대한 객체 생성 및 인스턴스화를 지연시킵니다. 공장 설계는 "개폐 원리"를 준수하므로 확장 시 원본 코드를 수정할 필요가 없습니다. UML 관계 다이어그램은 다음과 같습니다.
(3) 정적 팩토리 메서드 패턴:
정적 팩토리 패턴은 팩토리 메서드 패턴의 메서드를 정적으로 만듭니다. 인스턴스를 만들 필요가 없으며 호출만 하면 됩니다. 직접요.
팩토리 메소드 패턴 상세 글: 자바 디자인 패턴의 생성 유형: 팩토리 패턴 상세 설명(간단한 팩토리 + 팩토리 메소드 + 추상 팩토리)
추상 팩토리 패턴은 주로 관련 객체의 패밀리를 만드는 데 사용됩니다. 제품군이 함께 작동하도록 설계해야 하는 경우 추상 팩토리 패턴은 클라이언트가 항상 동일한 제품군의 개체만 사용하도록 보장할 수 있으며 특정 클래스의 생성을 격리함으로써 클라이언트가 특정 클래스를 명시적으로 지정할 필요가 없습니다. 모든 콘크리트 팩토리는 추상 팩토리에 정의된 공용 인터페이스를 구현하므로 전체 소프트웨어 시스템의 동작을 어느 정도 변경하려면 콘크리트 팩토리의 인스턴스만 변경하면 됩니다.
하지만 이 모델의 단점은 새로운 동작을 추가하는 것이 더 번거롭다는 것입니다. 새로운 제품군 개체를 추가해야 하는 경우 인터페이스와 모든 하위 클래스를 변경해야 하므로 필연적으로 많은 문제가 발생합니다.
UML 구조도는 다음과 같습니다.
추상 팩토리 패턴 세부 정보: Java 디자인 패턴의 생성 유형: 팩토리 패턴에 대한 자세한 설명(간단한 팩토리 + 팩토리 메소드 + 추상 팩토리)
빌더 패턴은 복잡한 제품의 생성 단계를 여러 가지 방법으로 분해하여 복잡한 객체의 구성과 사용을 분리함으로써 생성 프로세스를 보다 명확하게 하고 복잡한 객체의 생성 프로세스를 보다 정밀하게 제어합니다. , 제품 생성 제품 자체와 분리되어 동일한 건축 프로세스로 서로 다른 객체를 만들 수 있으며 각 콘크리트 빌더는 서로 독립적이므로 콘크리트 빌더를 교체하거나 새로운 콘크리트 빌더를 추가하기 쉽고 사용자는 서로 다른 것을 사용합니다. 그러면 건축업자는 다양한 제품 개체를 얻을 수 있습니다. UML 구조 다이어그램은 다음과 같습니다.
빌더 패턴 세부 사항: Java 디자인 패턴의 생성 유형: 빌더 패턴
싱글톤 모드는 다음을 보장할 수 있습니다. 특정 A 클래스에는 인스턴스가 하나만 있습니다. 클래스는 자체적으로 인스턴스화되고 이 인스턴스에 대한 공용 액세스 지점을 전체 시스템에 제공합니다. 이 공용 액세스 지점을 제외하고 인스턴스는 다른 방법을 통해 액세스할 수 없습니다. 싱글톤 모드의 장점은 다음과 같습니다.
싱글턴 패턴을 작성하는 방법에는 여러 가지가 있으며, 게으른 사람 스타일 싱글톤, 배고픈 사람 스타일 싱글톤, 등록 스타일 싱글톤의 세 가지 주요 유형이 있습니다.
싱글턴 패턴의 세부 사항: Java 디자인 패턴의 생성 유형: 싱글턴 패턴
프로토타입 패턴은 객체를 생성할 때도 사용됩니다. 프로토타입은 복사-복제를 수행하여 소스 개체와 유사한 새 개체를 생성합니다. UML 클래스 다이어그램은 다음과 같습니다.
Java에서 프로토타입 패턴의 핵심은 프로토타입 클래스 Prototype입니다.
Object 클래스의 clone() 메서드는 깊은 복사본을 원하는 경우 기본값으로 설정됩니다. 그런 다음 clone() 메서드에서 고유한 복사 논리를 사용자 정의해야 합니다.
프로토타입 모드를 사용하여 객체를 생성하면 객체 생성 단계가 단순화될 뿐만 아니라, Object 클래스의 clone() 메소드가 객체를 직접 조작하는 로컬 메소드이기 때문에 new 메소드를 사용하여 객체를 생성하는 것보다 성능이 훨씬 좋습니다. 특히 대용량 객체를 복사할 때 성능 차이는 매우 뚜렷합니다.
프로토타입 패턴 세부 정보: Java 디자인 패턴 생성 유형: 프로토타입 패턴
위에서 5가지 유형의 생성 패턴을 소개했으며, 이제 어댑터 모드, 장식 모드, 프록시 모드, 모양 모드, 브리지 모드, 조합 모드, 플라이웨이트 모드 등 7가지 구조 유형 모드를 소개합니다. 그 중 객체의 어댑터 모드는 아래와 같이 다양한 모드의 유래가 됩니다.
어댑터 모드는 주로 클래스나 인터페이스를 원하는 형식으로 변환하는 데 사용됩니다. 클라이언트에서는 원래의 호환되지 않는 클래스가 함께 작동하여 대상 클래스와 어댑터 클래스를 분리할 수 있으며 "개방 및 닫기 원칙"을 준수하고 특정 구현을 수정하지 않고도 새 어댑터 클래스를 추가할 수 있습니다. 캡슐화된 어댑터 클래스는 클라이언트 클래스에 투명하며 어댑터의 재사용성을 향상시킵니다. 그러나 단점은 어댑터 교체 구현 프로세스가 상대적으로 복잡하다는 것입니다.
따라서 어댑터 패턴은 다음 시나리오에 더 적합합니다.
다음은 어댑터 패턴이 무엇인지 보여주는 매우 생생한 예입니다.
어댑터 패턴에는 클래스 어댑터 패턴, 개체 어댑터 패턴, 인터페이스 어댑터 패턴의 세 가지 주요 구현이 있습니다. 세 가지의 사용 시나리오는 다음과 같습니다.
어댑터 패턴의 세부 사항: Java 디자인 패턴의 구조적 유형: 어댑터 패턴
데코레이터 패턴은 기능을 확장하기 위해 객체에 몇 가지 추가 책임을 동적으로 추가할 수 있습니다. 런타임 시 서로 다른 데코레이터를 사용하여 서로 다른 동작을 수행하는 것은 상속을 사용하는 것보다 더 유연합니다. 서로 다른 데코레이션 클래스를 배열하고 결합하면 다양한 동작을 생성하고 데코레이팅된 "열기 및 닫기 원칙"을 준수하는 더 강력한 개체를 얻을 수 있습니다. 클래스와 데코레이팅된 클래스는 독립적으로 변경됩니다. 사용자는 필요에 따라 새 데코레이팅된 클래스와 데코레이팅된 클래스를 추가한 다음 이를 사용할 때 원래 코드를 변경할 필요가 없습니다. 데코레이터 패턴의 UML 구조 다이어그램은 다음과 같습니다.
하지만 데코레이터 패턴에도 단점이 있습니다. 첫째, 작은 개체를 많이 생성하므로 시스템이 더 복잡해집니다. 여러 데코레이션 개체의 경우 디버깅 중에 오류를 찾으려면 단계별 문제 해결이 필요할 수 있으며 이는 번거롭습니다.
데코레이터 패턴의 세부 사항: 자바 디자인 패턴의 구조적 유형: 데코레이터 패턴
프록시 패턴의 설계 동기는 객체 프록시 클래스를 설정하여 프록시 객체가 원본 객체의 참조를 제어함으로써 실제 객체에 액세스하는 것입니다. 실제 객체의 작동. 프록시 모드에서 프록시 객체는 주로 호출자(즉, 클라이언트)와 호출 수신자(즉, 대상 객체)를 조정하고 연결하는 데 사용되는 중개자 역할을 하며, 이는 시스템과 대상의 결합을 어느 정도 감소시킵니다. 개체가 보호됩니다. 그러나 단점은 호출자와 호출 수신자 사이에 프록시 개체가 추가되어 요청 처리 속도가 느려질 수 있다는 것입니다. UML 구조 다이어그램은 다음과 같습니다.
프록시 패턴의 세부 사항: Java 디자인 패턴의 구조 유형: 프록시 패턴
브리지 패턴은 추상을 분리하고 분리합니다. 구현 부분에서 시스템의 일부를 독립적으로 변경할 수 있습니다. 브릿지 모드에서는 추상 부분과 구현 부분이 독립적으로 변경되도록 하는 목적을 달성하기 위해 상속 관계 대신 결합 관계를 사용하므로 추상 부분은 구현 부분의 인터페이스 개체를 갖습니다. 특정 구현 부분은 이 인터페이스 객체를 통해 호출될 수 있습니다. 즉, 브리지 모드의 브리지는 단방향 관계이므로 추상적인 부분만 구현 부분의 객체를 사용할 수 있고 그 반대는 사용할 수 없습니다.
브리지 모드는 "개폐 원리"를 준수하여 시스템의 확장성을 향상시킵니다. 원래 시스템을 수정하지 않고도 두 가지 변경 차원 중 하나를 임의로 확장할 수 있으며 구현 세부 사항은 고객에게 불투명하고 숨길 수 있습니다. 구현 세부 사항. 그러나 추상화 계층에서 집합 관계가 설정되기 때문에 개발자는 추상화를 위한 프로그래밍을 해야 하므로 시스템을 이해하고 설계하는 데 어려움이 가중됩니다. 브리지 모드의 UML 구조 다이어그램은 다음과 같습니다.
Java에서와 마찬가지로 JDBC를 사용하여 데이터베이스에 연결할 때 기본적으로 너무 많은 코드를 이동할 필요가 없습니다. 이유는 브리지 모드를 사용하고 JDBC가 통합 인터페이스를 제공하고 각 데이터베이스가 자체 구현을 제공한 다음 브리지 클래스가 데이터베이스에 연결하기 위한 드라이버를 생성하기 때문입니다. 특정 데이터베이스를 사용할 때 전환만 하면 됩니다. JDBC의 구조도는 다음과 같습니다.
JDBC에서 브리지 모드의 구현 역할(Implementor)은 Driver 인터페이스이고, 구체적인 구현(Concrete Implementor) 역할은 MysqlDriver, OracleDriver 및 MariadbDriver에 해당하며, 확장 추상화(Refined Abstraction) 역할은 DriverManager에 해당하며, 확장 추상화 역할의 상위 클래스로 추상화(Abstraction) 역할을 갖지 않습니다.情 브릿지 모드 세부 정보: Java 디자인 모드의 구조적 유형: 브릿지 모드
모양 모드는 클라이언트가 하위 시스템의 인터페이스 그룹에 액세스할 수 있도록 통합 인터페이스를 제공합니다. 표시 모드를 사용하면 다음과 같은 장점이 있습니다. (1) 사용이 더 쉬워집니다. 클라이언트는 더 이상 하위 시스템의 내부 구현을 이해할 필요가 없으며 내부 모듈과 상호 작용할 필요도 없습니다. (2) 느슨한 결합: 클라이언트를 하위 시스템에서 분리하여 하위 시스템 내에서 모듈을 더 쉽게 확장하고 유지 관리할 수 있습니다. (3) 더 나은 액세스 수준 구분: Facade를 합리적으로 사용하면 액세스 수준을 더 효과적으로 구분할 수 있습니다. 일부 방법은 시스템 외부에서 사용되며 일부 방법은 시스템 내부에서 사용됩니다. 외부에 노출되어야 하는 기능을 파사드에 집중시켜 클라이언트가 사용하기 편리할 뿐만 아니라 내부 디테일도 잘 숨깁니다. 그러나 모양 패턴이 하위 시스템 클래스에 너무 많은 제한을 가하면 가변성과 유연성이 감소하므로 모양 패턴은 복잡한 하위 시스템에 대한 간단한 인터페이스를 제공하고 시스템의 유용성을 향상시키며, 외관 패턴 하위 시스템은 클라이언트에서 분리되어 하위 시스템의 독립성과 이식성을 향상시킵니다. 모양 패턴의 UML 구조 다이어그램은 다음과 같습니다.10, 구조적 형태-모양 모드:
모양 패턴 세부 정보: Java 디자인 패턴의 구조 유형: 모양 패턴
결합 모드는 리프 객체와 컨테이너 객체를 재귀적으로 결합하여 트리 구조를 형성하여 "부분-전체" 계층 구조를 나타내므로 사용자가 단일 객체와 결합 객체를 쉽게 일관성 있게 사용할 수 있습니다. , 구분 없이 나뭇잎 개체와 같은 복합 개체를 처리하는 기능을 통해 사용자 프로그램을 복잡한 요소의 내부 구조에서 분리할 수 있습니다.
조합 모드에서 가장 중요한 점은 리프 개체와 조합 개체가 동일한 추상 구성 클래스를 구현한다는 것입니다. 고객은 이 추상 구성 클래스에 대해서만 프로그래밍하면 됩니다. . 리프 노드와 객체 노드를 일관되게 처리할 수 있는 이유. 조합 패턴의 UML 구조 다이어그램은 다음과 같습니다.
조합 패턴의 세부 사항: Java 디자인 패턴의 구조 유형: 조합 패턴
플라이웨이트 패턴은 공유 기술을 통해 효과적으로 지원됩니다. 작은 상태 변경으로 세분화된 개체 재사용 시스템에 동일한 개체가 여러 개 있는 경우 각 개체에 대해 개체를 인스턴스화할 필요가 없으므로 개체 수가 크게 줄어듭니다. 시스템에서 자원을 절약합니다.
플라이웨이트 모델의 핵심은 플라이웨이트 팩토리 클래스입니다. 플라이웨이트 팩토리 클래스는 개체 저장 풀을 유지합니다. 클라이언트는 개체가 필요할 때 플라이웨이트 풀에 개체 인스턴스가 있는 경우 먼저 해당 개체를 얻습니다. , 플라이웨이트 풀에 존재하지 않으면 새로운 플라이웨이트 개체 인스턴스를 생성하여 사용자에게 반환하고, 새 개체를 플라이웨이트 풀에 저장하는데 이는 싱글톤이라는 의미를 갖습니다.
팩토리 클래스는 일반적으로 HashMap, Hashtable, Vector 등과 같은 컬렉션 유형을 사용하여 객체를 저장합니다. Java에서 데이터베이스 연결 풀, 스레드 풀 등은 모두 Flyweight 패턴을 사용하는 애플리케이션입니다.
플라이웨이트 패턴의 UML 구조 다이어그램은 다음과 같습니다. ' ' s ' s ' s t t t out out out out out out out out out out out out out out out of to in Java through . . Java의 문자열 상수는 문자열 상수 풀에 저장되며 JVM은 상수 풀에 문자열 상수의 복사본이 하나만 있는지 확인합니다.
그리고 공유 풀의 경우 Java의 JDBC 연결 풀을 쉽게 생각할 수 있습니다. 연결 풀 관리를 통해 데이터베이스 연결 공유가 실현되며 연결을 매번 다시 생성할 필요가 없습니다. 시간, 데이터베이스 재생성 비용 절감, 시스템 성능 향상! 
플라이웨이트 패턴 세부 정보: Java 디자인 패턴의 구조적 유형: 플라이웨이트 패턴
앞서 7가지 구조적 디자인 패턴을 소개했고, 다음으로 11가지 동작 디자인 패턴을 소개합니다: 전략 패턴, 템플릿 메소드 패턴, 관찰자 패턴, 반복자 패턴, 체인 책임 패턴, 명령 패턴, 메모 패턴, 상태 패턴, 방문자 패턴, 중재자 패턴, 인터프리터 패턴으로 구성됩니다. 먼저 사진을 찍어서 11가지 패턴 사이의 관계를 살펴보겠습니다.13. 행동-전략 패턴:
클래스에서 자주 변경되거나 변경 가능성이 있는 부분을 추상 전략 인터페이스 클래스로 추출한 후 The 클래스에는 이 객체의 인스턴스가 포함되어 있으므로 클래스 인스턴스는 런타임 시 이 인터페이스를 구현하는 클래스의 동작을 자유롭게 호출할 수 있습니다. 
전략 패턴의 장점은 객체의 동작을 동적으로 변경할 수 있다는 것입니다. 그러나 단점은 많은 전략 클래스가 생성되고 의사 결정 능력이 있다는 것입니다. 전략 패턴은 사용자에게 달려 있습니다. 시스템은 다양한 알고리즘의 구현만 제공하므로 Duan은 모든 전략 클래스를 알아야 하며 어떤 전략 클래스를 사용할지 스스로 결정해야 합니다.
전략 모드는 다음 장면에 적용 가능합니다.
전략 패턴 세부 사항: 행동 Java 디자인 패턴: 전략 패턴
템플릿 방법은 상속을 기반으로 구현되며 실행 단계는 다음과 같습니다. 알고리즘의 뼈대(즉, 알고리즘 뼈대)는 템플릿 메서드에 정의되어 있습니다. 템플릿 메서드 패턴에서는 하위 클래스의 공통 부분은 상위 클래스에서 구현될 수 있지만, 특성 부분은 하위 클래스로 지연됩니다. 특성 부분만 상위 클래스에서 추상 메서드로 선언하면 됩니다. 서브클래스 알고리즘의 특정 단계는 알고리즘 구조를 변경하지 않고도 재정의될 수 있으며, 다양한 서브클래스는 이러한 논리를 다양한 방식으로 구현할 수 있습니다.
템플릿 메서드 패턴의 장점은 "열기 및 닫기 원칙"을 준수하고 코드 재사용을 달성하고 변경되지 않은 동작을 상위 클래스로 전송하며 하위 클래스에서 중복 코드를 제거할 수 있다는 것입니다. 그러나 단점은 서로 다른 구현에서 하위 클래스를 정의해야 하므로 클래스 수가 증가하고 시스템이 더 커지고 디자인이 더 추상화된다는 것입니다. 템플릿 메소드 패턴의 UML 다이어그램은 다음과 같습니다.
템플릿 메소드 세부사항: Java 디자인 패턴의 동작 유형: 템플릿 메소드 패턴
책임 사슬 요청 핸들러를 할당할 수 있습니다. 체인으로 구성하고 체인을 따라 요청을 전달할 수 있습니다. 프로세서가 요청을 처리할 수 있으면 처리되고, 그렇지 않으면 요청이 처리를 위해 상위로 넘겨집니다. 클라이언트는 책임 체인에 요청을 보내기만 하면 되며 요청 처리 세부 사항에 주의할 필요가 없습니다. 요청 보낸 사람과 프로세서는 책임 체인을 통해 분리됩니다.简 책임 사슬 모델은 클라이언트와 처리자 모두 상대방의 정보를 갖고 있지 않으며, 동시에 처리자는 책임 사슬의 구조를 알지 못하기 때문에 객체 간의 상호 연결을 단순화할 수 있습니다. 모든 후보자에 대한 참조를 저장해야 합니다.
또한 책임 사슬 모델은 시스템의 유연성을 높여줍니다. 원하는 대로 프로세서를 추가하거나 변경할 수 있으며 프로세서 순서도 변경할 수 있습니다. 그러나 이로 인해 요청이 처리되지 않을 수도 있습니다. 체인 끝에 배치됩니다.
그래서 책임 체인 모델에는 다음과 같은 장점이 있습니다.(1) 결합 정도를 줄이고 요청의 발신자와 수신자를 분리합니다. 코드에 반영하면 클래스에 보기 흉한 if...else 문을 많이 작성할 필요가 없습니다. 책임 체인을 사용하면 요청을 제출하기만 하면 됩니다. 프로세서 중 하나에 전달한 다음 블랙박스를 안으로 들어가게 하세요. 전달하는 역할만 담당하세요.(1) 요청이 성공적으로 처리된다는 보장은 없습니다.
- (2) 객체에 체인 구조가 필요하지 않도록 객체를 단순화합니다.
- (3) 체인 내에서 멤버를 변경하거나 순서를 이동하여 핸들러를 동적으로 추가 또는 삭제할 수 있도록 시스템의 유연성을 높입니다.
- (4) 새로운 요청 처리 클래스를 추가하는 것이 편리합니다.
- 그러나 책임 사슬 모델에도 몇 가지 단점이 있습니다.
책임 체인 패턴의 UML 구조 다이어그램은 다음과 같습니다.
- (2) 시스템 성능은 어느 정도 영향을 받으며 루프 호출이 발생할 수 있습니다. 발생하다.
- (3) 런타임 특성을 관찰하는 것이 쉽지 않을 수 있으며, 코드 디버깅 시 불편해 디버깅을 방해합니다.
16. :
그러나 관찰자 패턴의 단점은 관찰자가 많으면 모든 관찰자에게 알리는 데 일정 시간이 걸린다는 것입니다. 관찰자와 관찰자 사이에 순환 종속성이 있으면 시스템이 중단될 수 있습니다. 관찰자 패턴에는 관찰자가 관찰 대상이 어떻게 변했는지 알 수 있는 대응 메커니즘이 없고, 관찰 대상이 변했다는 것만 알 수 있습니다. 관찰자 패턴의 UML 구조 다이어그램은 다음과 같습니다.
관찰자 패턴 세부 사항: 행동 Java 디자인 패턴: 관찰자 패턴
방문자 패턴은 객체를 분리하는 방법입니다. 데이터 구조 및 동작(데이터 구조 기반 작업) 이러한 분리를 통해 다른 수정 없이 방문자에게 새 작업을 동적으로 추가하는 효과가 달성되어 이러한 데이터 구조에 작용하는 새 작업을 추가할 수 있게 됩니다. 각 데이터 구조를 변경할 필요가 없습니다. 이는 다양한 유형의 데이터 구조에 대해 다중 액세스 작업 방법을 제공합니다. 이것이 방문자 패턴의 설계 동기입니다.
새로운 액세스 작업을 더 쉽게 추가할 수 있을 뿐만 아니라 기존 클래스 계층 구조를 수정하지 않고 클래스 계층 구조의 작업을 정의하고 관련 요소 개체의 액세스 동작을 분산시키는 대신 방문자 개체에 집중할 수도 있습니다. 요소 클래스에서 하나씩.
하지만 방문자 패턴의 단점은 새 요소 클래스를 추가하기 어렵다는 것입니다. 새 요소 클래스를 추가할 때마다 추상 방문자 역할에 새 추상 작업이 추가되고 각 특정 방문자에게 새 추상 작업이 추가된다는 의미입니다. . 해당 특정 작업을 클래스에 추가하는 것은 "열기 및 닫기 원칙"의 요구 사항을 위반합니다.
따라서 방문자 패턴은 객체 구조를 거의 변경하지 않지만 종종 이 객체 구조에 대해 새로운 작업을 정의해야 하는 시스템에 적합합니다. 알고리즘 작업 추가가 간단해지거나 객체 구조에 대해 서로 다른 여러 작업을 수행해야 하며 이러한 작업으로 인해 이러한 객체가 오염되는 것을 방지해야 하며 새 작업을 추가할 때 이러한 클래스를 수정하고 싶지 않습니다. . ㅋㅋㅋ 방문자 및 특정 방문자는 주로 일부 작업을 선언하는 데 사용됩니다. 하나는 주로 선언하는 데 사용되는 추상 요소와 구체적인 요소입니다. 작업을 수락하고 개체 구조 ObjectStructure는 서로 다른 유형의 개체를 저장하여 둘 사이의 브리지 역할을 하므로 서로 다른 방문자가 액세스할 수 있고 동일한 방문자가 서로 다른 방식으로 서로 다른 요소에 액세스할 수 있으므로 방문자 모드에서 새 방문자를 추가하면 기존 코드를 수정할 필요가 없으며 확장이 가능합니다. ㅋㅋㅋ > 방문자 모드에서 사용됩니다. 방문자 모드에서는 클라이언트가 특정 방문자에게 특정 상태를 매개변수로 전달합니다. 여기에서 첫 번째 디스패치가 완료되고, 그 다음에는 특정 방문자가 "특정 상태" 메소드에서 매개변수로 사용되며 자체 this도 됩니다. 매개변수로 전달되면 여기서 두 번째 디스패치가 완료됩니다. 이중 디스패치는 요청 유형과 수신자 유형에 따라 결과 실행이 달라짐을 의미합니다.
방문자 패턴 세부 정보: 행동 Java 디자인 패턴: 방문자 패턴
사용 사용 ’ ’ ’ 사용 ’ s ’ s t-- t-to 복잡한 관계 네트워크 객체 간의 구조는 중개자를 핵심으로 하는 단순한 별형 구조가 되며, 객체 간의 일대다 연관은 일대일 연관으로 변환되어 객체 간의 관계를 단순화하고 각 객체 간의 이해를 더 쉽게 만듭니다. 객체 관계가 분리되어 각 객체는 더 이상 연관된 객체와 직접 상호 작용하지 않지만 중간 객체를 통해 연관된 객체와 통신하므로 객체를 상대적으로 독립적으로 사용할 수 있어 객체의 재사용성과 시스템 확장성이 향상됩니다. ㅋㅋㅋ 중재자 패턴에서 중재자 클래스는 시스템의 모든 개체 클래스 간의 관계를 캡슐화하며 개체 간의 상호 작용을 추가로 제어할 수도 있습니다. 중재자 패턴의 UML 구조 다이어그램은 다음과 같습니다.
중재자 개체는 개체 간의 관계를 캡슐화하므로 중재자 개체가 더 커지고 복잡해지며, 더 많은 책임을 지고 유지 관리가 더 어려워집니다. 각 개체와 개체 간의 상호 작용 세부 정보를 알아야 합니다. 잘못되면 전체 시스템이 잘못될 수 있습니다.
Mediator 패턴 세부 정보: 동작 Java 디자인 패턴: Mediator 패턴
19. 동작 명령 패턴:
명령 패턴의 핵심은 요청을 객체로 캡슐화하고 명령을 발행하고 실행하는 책임을 별도로 할당하는 것입니다. , 명령의 송신자와 수신자는 완전히 분리됩니다. 송신자는 명령을 보내는 방법만 알면 되며 명령이 어떻게 구현되는지 또는 명령이 성공적으로 실행되는지 여부에 대해서는 신경 쓸 필요가 없습니다. 명령 패턴의 핵심은 추상 명령 인터페이스를 도입하는 것입니다. 추상 명령 인터페이스를 구현하는 특정 명령만 수신자와 연결될 수 있습니다.
명령 모드를 사용하면 시스템의 결합도가 줄어들고 시스템에 새로운 명령을 쉽게 추가할 수 있다는 장점이 있으며, 결합된 명령을 설계하기도 쉽습니다. 그러나 단점은 각 명령에 대해 특정 명령 클래스를 설계해야 하기 때문에 일부 시스템에는 특정 명령 클래스가 너무 많다는 것입니다.
명령어 패턴의 UML 구조 다이어그램은 다음과 같습니다.
명령어 패턴 세부정보: Java 디자인 패턴의 동작 유형: 명령어 모드
20. 동작 상태 모드:
> 다음의 경우 동작을 변경하여 상태가 변경되면 객체는 클래스를 수정한 것처럼 보입니다. 즉, 동작을 통해 상태를 변경하는 것이 아니라 상태를 원자로 사용하여 동작을 변경하는 것입니다.
객체의 동작이 속성에 따라 달라지는 경우 이러한 속성을 상태라고 하며 객체를 상태 객체라고 합니다. 상태 개체의 동작은 해당 상태에 따라 달라집니다. 예를 들어, 객실을 예약하려는 경우 객실이 비어 있을 때만 예약할 수 있습니다. 객실을 예약한 경우에만 체크인할 수 있습니다. 무료입니다. 이러한 개체의 경우 외부 이벤트가 상호 작용하면 내부 상태가 변경되어 그에 따라 동작이 변경됩니다.
상태 패턴의 UML 구조 다이어그램은 다음과 같습니다.
위 UML 구조 다이어그램에서 상태 패턴의 장점은 다음과 같습니다.
(1) 변환 규칙을 캡슐화하여 다음을 허용합니다. 거대한 조건문 블록 대신 상태 객체와 통합되는 상태 변환 로직
(2) 모든 상태 관련 동작을 클래스에 넣으면 새 상태를 쉽게 추가할 수 있으며 객체 상태만 변경하면 변경됩니다. 객체의 행동.
그러나 상태 패턴의 단점은 다음과 같습니다.
(1) 상태를 열거하기 전에 상태 유형을 결정해야 합니다.
(2) 시스템 클래스 및 개체 수가 증가합니다.
(3) "개방-폐쇄 원칙"에 대한 지원은 우호적이지 않습니다. 새 상태 클래스를 추가하려면 상태 변환을 담당하는 소스 코드를 수정해야 합니다. 그렇지 않으면 새 상태와 특정 수정 동작으로 전환할 수 없습니다. 상태 클래스도 해당 클래스의 소스 코드를 수정해야 합니다.
따라서 상태 패턴은 다음과 같은 경우에 적합합니다. 코드에 객체의 상태와 관련된 다수의 조건문이 포함되어 있고 객체의 동작이 상태에 따라 달라지며 관련 동작이 객체의 변경에 따라 변경될 수 있습니다. 상태. ： 상태 모드 세부 정보: Java 디자인 모드 동작 유형: 상태 모드
메모 모드는 특정 순간의 내부 상태를 객체 외부에 저장하는 메커니즘을 제공합니다. 개체는 특정 기록 상태로 복원될 수 있습니다. 메모 모드는 메모에 저장된 세부 정보를 캡슐화하며 이를 작성한 작성자 외에는 다른 개체가 액세스할 수 없으며 저장된 세부 정보가 변경되더라도 클라이언트는 이를 달성합니다. 영향을 받지 않습니다. 그러나 메모 모드는 다중 상태 및 다중 백업이므로 더 많은 메모리를 사용하고 리소스를 소비합니다. 메모 패턴의 UML 구조 다이어그램은 다음과 같습니다. Memorandum 모드의 핵심은 Memation MEMENTO입니다. Memorandum에서는 원본 장기의 상태 정보 중 일부 또는 전부를 외부 개체에 사용하여 내부 상태 정보가 노출되면 위반합니다. 따라서 메모를 보낸 사람 외에는 다른 개체가 해당 메모에 접근할 수 없습니다. 따라서 메모 모드 캡슐화를 구현하려면 메모에 대한 접근을 제어해야 합니다. (1) 작성자의 경우: 메모에 있는 모든 정보에 접근할 수 있습니다. (2) 담당자, 관리인의 경우: 메모에 있는 데이터에 접근할 수 없지만, 메모를 저장하고 다른 개체에 메모를 전달할 수 있습니다. (3) 기타 개체 : 접근 불가, 저장 불가. 담당자로부터 전달받은 메모를 받아 원래 기기의 상태를 복원하는 역할만 담당합니다.21, 동작 메모 모드:
메멘토 패턴 세부 정보: 동작 Java 디자인 패턴: 메멘토 패턴22. 동작-반복자 패턴: Iterator 패턴은 내부 표현 방법을 노출하지 않고 컬렉션의 개별 요소에 액세스하는 방법을 제공합니다. 컬렉션 객체 대신 반복자에게 요소 간 이동에 대한 책임을 부여하여 컬렉션 컨테이너 구현을 단순화하고 컬렉션 컨테이너가 집중해야 할 사항에 집중할 수 있도록 합니다. 이는 단일 책임 원칙에 더 부합하며 다음 작업을 수행할 필요가 없습니다. 추상 인터페이스 계층은 다양한 순회 작업으로 채워집니다. 이터레이터 패턴의 UML 구조 다이어그램은 다음과 같습니다.
이터레이터 패턴 세부 정보: Java 디자인 패턴의 동작 유형: 이터레이터 패턴23 동작 유형-인터프리터 패턴: 인터프리터 패턴은 다음과 같습니다. 정의 언어의 문법과 언어의 문장을 해석하는 통역사를 구축하여 자주 발생하는 특정 유형의 문제 인스턴스를 해결합니다. ㅋㅋㅋ 이 문장을 해석하는 방법. 인터프리터 모드에서는 언어를 정의하기 위해 문법 규칙을 사용하는 것 외에도 추상 구문 트리를 사용하여 언어의 구성을 보다 직관적으로 표현하고 각 추상 구문 트리를 언어 인스턴스에 대응할 수 있습니다. 추상 구문 트리는 복잡한 문장을 형성하는 방법을 설명합니다. 추상 구문 트리를 분석하여 언어의 터미널 및 비 터미널 기호 클래스를 식별할 수 있습니다. 인터프리터 모드에서는 각 터미널 표현식과 비터미널 표현식에 해당하는 특정 인스턴스가 있으므로 시스템 확장성이 더 좋습니다. 인터프리터 패턴의 UML은 다음과 같습니다. 인터프리터 패턴의 세부 사항: Java 디자인 패턴의 동작 유형: 인터프리터 패턴추천 학습: "
java 학습 튜토리얼"
위 내용은 23가지 일반적인 Java 디자인 패턴에 대한 자세한 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
