이 요약은 주로 디자인 패턴의 기본에 관한 이전 기사 시리즈를 기반으로 합니다. 중요한 지식 포인트를 본인의 말로 설명하는 것이 가장 중요하며, 다소 틀린 부분이 있을 수 있으니 양해해 주시고 지도해주시길 바랍니다.
Design Pattern
Creative Pattern
Creative Pattern의 역할은 객체를 생성할 때 가장 친숙한 것은 객체를 새로 만든 다음 관련 속성을 설정하는 것입니다. 그러나 많은 시나리오에서 클라이언트에게 객체를 생성하는 보다 친숙한 방법을 제공해야 합니다. 특히 클래스를 정의했지만 이를 다른 개발자에게 제공해야 하는 경우에는 더욱 그렇습니다.
싱글 케이스
单例模式保证全局的单例类只有一个实例,这样的话使用的时候直接获取即可,比如数据库的一个连接,Spring里的bean,都可以是单例的。 单例模式一般有5种写法。 第一种是饿汉模式,先把单例进行实例化,获取的时候通过静态方法直接获取即可。缺点是类加载后就完成了类的实例化,浪费部分空间。 第二种是饱汉模式,先把单例置为null,然后通过静态方法获取单例时再进行实例化,但是可能有多线程同时进行实例化,会出现并发问题。 第三种是逐步改进的方法,一开始可以用synchronized关键字进行同步,但是开销太大,而后改成使用volatile修饰单例,然后通过一次检查判断单例是否已初始化,如果未初始化就使用synchronized代码块,再次检查单例防止在这期间被初始化,而后才真正进行初始化。 第四种是使用静态内部类来实现,静态内部类只在被使用的时候才进行初始化,所以在内部类中进行单例的实例化,只有用到的时候才会运行实例化代码。然后外部类再通过静态方法返回静态内部类的单例即可。 第五种是枚举类,枚举类的底层实现其实也是内部类。枚举类确保每个类对象在全局是唯一的。所以保证它是单例,这个方法是最简单的。
팩토리 패턴
简单工厂一般是用一个工厂创建多个类的实例。 工厂模式一般是指一个工厂服务一个接口,为这个接口的实现类进行实例化 抽象工厂模式是指一个工厂服务于一个产品族,一个产品族可能包含多个接口,接口又会包含多个实现类,通过一个工厂就可以把这些绑定在一起,非常方便。
프로토타입 패턴
一般通过一个实例进行克隆从而获得更多同一原型的实例。使用实例的clone方法即可完成。
빌더 패턴
建造者模式中有一个概念叫做链式调用,链式调用为一个类的实例化提供便利,一般提供系列的方法进行实例化,实际上就是将set方法改造一下,将原本返回为空的set方法改为返回this实例,从而实现链式调用。 建造者模式在此基础上加入了builder方法,提供给外部进行调用,同样使用链式调用来完成参数注入。
구조 패턴
이전 생성 패턴에서는 객체를 생성하는 방법을 몇 가지 디자인 패턴으로 소개했습니다. 이 섹션에서 소개하는 구조적 패턴은 코드 구조를 변경하여 코드를 유지 관리하고 확장하기 쉽게 만들어 디커플링 목적을 달성하는 것을 목표로 합니다.
어댑터 패턴
어댑터 패턴은 두 개의 서로 다른 클래스를 적용하는 데 사용됩니다.
어댑터 패턴과 프록시 패턴의 유사점과 차이점
이 두 패턴을 비교하는 것은 실제로 객체 어댑터 패턴과 프록시 패턴을 비교하는 것입니다.
두 패턴은 매우 유사하며 둘 다 특정 구현 클래스의 인스턴스가 필요합니다.
그러나 그들의 목적은 다릅니다. 프록시 모드는 원래 방법을 향상시키는 작업을 수행합니다.
어댑터는 "닭을 오리로 포장한 다음 오리로 사용"하기 위해 적응 작업을 수행합니다. ,
닭과 오리 사이에는 상속관계가 없습니다.
어댑터 패턴은 클래스 어댑터, 객체 어댑터 등으로 나눌 수 있습니다.
클래스 어댑터는 상속을 통해 상위 클래스에 적응할 수 있습니다.
객체 어댑터는 패키징을 위해 객체를 다른 객체의 생성자에 전달해야 합니다.
플라이웨이트 모드
/ 플라이웨이트 모드의 핵심은 플라이웨이트 팩토리 클래스에 있습니다.
// 플라이웨이트 팩토리 클래스의 기능은 플라이웨이트 객체를 저장하기 위한 플라이웨이트 풀을 제공하는 것입니다.
// 사용자 시기 개체가 필요하면 먼저 플라이급 풀에서 가져옵니다.
// 플라이급 풀에 없으면 새 플라이급 개체를 만들어 사용자에게 반환합니다.
// 새 개체를 플라이급에 저장합니다. 수영장 .
//Flyweight Pattern
// 이 단어를 처음 번역한 사람이 누구인지는 모르겠지만, 이 번역은 정말 이해하기 어려운 것 같습니다. 플라이웨이트는 경량을 의미합니다. 즉, 이미 생성된 객체를 재사용하는 방식을 말합니다.
// 객체를 재사용하는 가장 간단한 방법은 HashMap을 사용하여 새로 생성된 각 객체를 저장하는 것입니다. 객체가 필요할 때마다 먼저 HashMap으로 이동하여 존재하는지 확인하세요. 그렇지 않은 경우 새 객체를 생성한 다음 이 객체를 HashMap에 넣으세요.
// 이 간단한 코드는 보여드리지 않겠습니다.
프록시 모드
// 직설적으로 말하면 프록시 모드는 "메서드 패키징" 또는 "메서드 향상"을 수행하는 것입니다.
// 관점 지향 프로그래밍에서는 이 용어를 잊어버리세요. AOP에서
//는 실제로 동적 프록시 처리 과정입니다. 예를 들어, Spring에서는
// 프록시 클래스를 직접 정의하지 않지만 Spring은 프록시를 동적으로 정의하는 데 도움을 줍니다.
// 그런 다음 @Before, @After 및에서 정의한 코드 로직을 동적으로 추가합니다. @프록시 중간쯤.
외관 모드
외관 모드는 일반적으로 특정 구현 세부 정보를 캡슐화하고 사용자에게 더 간단한 인터페이스를 제공합니다.
메서드 호출을 통해 필요한 콘텐츠를 얻을 수 있습니다.
결합 패턴
//결합 패턴은 데이터를 계층 구조로 표현하는 데 사용되므로 단일 개체와 복합 개체에 대한 액세스를 일관되게 만듭니다.
//예를 직접 살펴보겠습니다. 각 직원에는 이름, 부서, 급여와 같은 속성이 있습니다.
// 하위 직원 집합도 있습니다(비어 있을 수 있음).
// 하위 직원과 자신 구조는 동일합니다.
// 이름, 부서 등의 속성도 있고,
// 하위 직원 모음도 있습니다.
class Employee { private String name; private String dept; private int salary; private List<Employee> subordinates; // 下属 }
Decorator 패턴
Decorator
데코레이터 패턴은 각 고급 클래스가 최상위 상위 클래스를 상속하도록 만듭니다. 그런 다음 기능 향상이 필요할 때 클래스 인스턴스를 향상된 클래스에 전달하면 향상된 클래스를 사용할 때 원래 클래스의 기능을 향상시킬 수 있습니다.
프록시 모드와 달리 데코레이터 모드에서는 각 데코레이션 클래스가 상위 클래스를 상속하며 여러 수준에서 캡슐화될 수 있습니다.
행동 패턴
행동 패턴은 다양한 클래스 간의 상호 작용에 중점을 두고 책임을 명확하게 나누어 코드를 더욱 명확하게 만듭니다.
Strategy Pattern
전략 패턴은 일반적으로 전략을 클래스로 취급하고 전략을 지정해야 할 때 인스턴스를 전달하므로 알고리즘을 사용해야 하는 지정된 알고리즘을 전달할 수 있습니다.
명령 모드
명령 모드는 일반적으로 명령 개시자, 명령 및 명령 수신자의 세 가지 역할로 나뉩니다.
명령 개시자는 명령 인스턴스를 사용할 때 명령 인스턴스를 삽입해야 합니다. 그런 다음 명령 호출을 실행하십시오.
명령 호출은 실제로 명령 수신자의 메서드를 호출하여 실제 호출을 수행합니다.
예를 들어 리모컨 버튼은 명령과 동일합니다. 버튼을 클릭하면 명령이 실행되고 TV에서 제공하는 메소드가 자동으로 호출됩니다.
Template 메소드 패턴
Template 메소드는 일반적으로 메소드 템플릿을 제공하는 것을 말하며, 그 안에는 구현 클래스와 추상 클래스가 있는데, 그리고 실행 순서를 규정합니다.
구현 클래스는 템플릿에서 제공하는 좋은 방법입니다. 추상 클래스는 사용자가 직접 구현해야 합니다.
템플릿 메소드는 템플릿 내 메소드의 실행 순서를 지정하는데, 이는 일부 개발 프레임워크에 매우 적합하므로 오픈소스 프레임워크에서도 템플릿 메소드가 널리 사용됩니다.
관찰자 패턴 및 이벤트 수신 메커니즘
관찰자 패턴은 일반적으로 구독자와 메시지 게시자 간의 데이터 구독에 사용됩니다.
일반적으로 옵저버와 토픽으로 구분됩니다. 토픽을 구독하고 토픽이 관리하는 옵저버 목록에 인스턴스를 등록합니다.
토픽이 데이터를 업데이트하면 자동으로 데이터를 관찰자에게 푸시하거나 데이터가 업데이트되었음을 관찰자에게 알립니다.
하지만 이 방법으로 인해 메시지 푸시의 결합 관계가 상대적으로 빡빡합니다. 그리고 데이터를 열어보지 않으면 데이터 유형이 무엇인지 알기가 어렵습니다.
데이터 형식을 보다 유연하게 만들기 위해 이벤트 및 이벤트 리스너 패턴이 이벤트 래퍼의 이벤트 유형과 이벤트 데이터를 주체와 관찰자에서 분리한 것으로 알고 있습니다.
Theme 이벤트가 발생하면 해당 이벤트의 모든 리스너가 트리거되고, 이벤트를 청취한 후 먼저 처리를 지원하는 이벤트 유형에 따라 이벤트가 리스너 목록을 통해 각 리스너에게 전송됩니다. 해당 이벤트 핸들러를 찾은 다음 핸들러를 사용하여 해당 이벤트를 처리합니다.
책임 사슬 모드
책임 사슬은 일반적으로 먼저 단방향 연결 목록을 설정해야 하며 그 다음 호출자는 헤드 노드를 호출하면 나중에 자동으로 전송됩니다. 예를 들어 프로세스 승인이 좋은 예입니다. 최종 사용자가 신청서를 제출하기만 하면 해당 신청서의 콘텐츠 정보를 기반으로 책임 체인이 자동으로 설정되고 흐름이 시작됩니다
위 내용은 Java 디자인 패턴 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!