I. 소개
최근에 일부 역사적 코드의 변형에서 매우 분명한 특징을 발견했고, 대부분의 코드는 내러티브이며, 사건의 발전 과정에 따라 스토리가 간단하게 설명됩니다.
이 방법의 장점은 인간의 사고 습관에 더 부합한다는 것입니다. 마지막에 메인 라인이 설명되어 있습니다. 코드는 읽기가 너무 어렵지 않습니다. 덩굴을 따라 가면 멜론을 느낄 수 있지만 단점도 분명합니다. 일단 스토리 라인에 새로운 이야기를 삽입해야하면 다음과 같은 요소 : 새 캐릭터 추가, 새 타임 라인은이 새 요소의 통합에 맞게 스토리 라인을 많이 변경해야하며 원본 기사에 파괴적인 영향을 미칩니다.
이 문제를 해결하기 위해 사람들은 전체 포인트 구조, 병렬 구조, 전체 포인트 전체 구조 등과 같은 많은 종류의 기사 구조를 요약했습니다. 이러한 구조를 사용하면 새로운 요소를 추가 할 때 새로운 요소를 고려할 필요조차 없습니다. 원본 스토리 라인과의 관련성을 위해 전체 스토리가 끝나기 전에 메인 스토리로 수렴 할 수있는 한 브랜치 스토리 라인을 가져와 독립적으로 말하면됩니다 (git와 매우 유사합니까?).
소프트웨어 개발 분야에는 디자인 패턴이라고 부르는 매우 유용한 연습 요약이 많이 있습니다. 디자인 패턴에 익숙하지 않은 사람은 없습니다. 아는 사람은 N 개의 디자인 패턴을 말할 수있을 것으로 예상되지만 이러한 디자인 패턴의 개념 외에도 많은 사람들이 이러한 디자인 패턴을 유연하게 사용하는 방법을 모릅니다. 따라서이 기사를 통해 모든 사람과 함께 디자인 패턴에 대한 아이디어를 배우십시오.
두 가지 이해 디자인 패턴
모든 사람에게 도움이되기를 바라면서 내가 이해하는 디자인 패턴을 설명하기 위해 가장 이해하기 쉬운 예제와 언어를 사용하려고합니다.
또한 모든 디자인 패턴에 능숙 할 필요는 없습니다. 공통 디자인 패턴을 통합 할 수 있으면 코드를 우아하게 만들 수 있습니다. 쳉 야오 진이 3 번의 스트라이크 만하는 것처럼 그의 실력은 타의 추종을 불허하며 여전히 세계를 여행 할 수 있습니다.
1 공장 모드 (Factory)
단순 공장
샤오밍이 언니를 쫓았을 때 그녀는 그녀에게 커피를 많이 마시라고 권유했습니다. 그녀는 카푸치노를 마시는 것을 좋아합니다. 그녀는 커피 숍에 갈 때마다 웨이터에게 "카푸치노 한잔"이라고 말하면됩니다. 가족마다 취향은 다르지만 말입니다. ,하지만 스타 파파 든 코스타 든 카푸치노를 제공 할 수 있습니다. 여기 Papa Star와 Costa는 커피를 생산하는 공장입니다.
(1) 간단한 공장 모델 구조
간단한 팩토리 패턴에는 다음 역할이 포함됩니다.
Factory : 모든 인스턴스를 만드는 내부 논리를 구현하는 역할을 담당하는 팩토리입니다.
제품 : 추상 제품 역할-생성 된 모든 개체의 상위 클래스로, 모든 인스턴스에서 공유하는 공통 인터페이스를 설명합니다.
ConcreteProduct : 특정 제품 역할-생성 대상이며, 생성 된 모든 개체는이 역할의 특정 클래스 인스턴스로 작동합니다.
구조 다이어그램 :
타이밍 다이어그램 :
(2) 장점과 단점
장점 : 고객 등급과 공장 등급이 분리되어 있습니다. 소비자는 언제든지 특정 제품이 필요하며 공장에서 요청하기 만하면됩니다. 소비자는 수정없이 신제품을 받아 들일 수 있습니다.
단점 : 제품이 수정되면 공장 등급도 그에 따라 수정되어야합니다.
공장 방법
예전에는 아내를 유니클로 (단순 공장)로 데려가 옷을 사곤했는데 스타일이 너무 많아서 쇼핑을 자주하면 짜증이 났어요. 나중에 전략을 바꾸고 아내를 쇼핑몰 (추상 공장)로 데려 갔는데, 쇼핑몰 안에는 다양한 브랜드의 상점이 있는데 나 없이는 하루 종일 쇼핑을 할 수있다.
단순한 공장과 달리 핵심 공장 카테고리 (쇼핑몰)는 더 이상 모든 제품의 생성을 담당하지 않고 대신 특정 생성 작업을 하위 카테고리 (의류 매장)에 위임하여 추상적 인 공장 역할이되고 특정 공장 카테고리 만 부여하는 역할 만 담당합니다. 인스턴스화해야하는 제품 클래스의 세부 사항을 건드리지 않고 구현해야하는 인터페이스 (저장소)입니다.
(1) Factory method 패턴 구조
팩토리 메소드 패턴에는 다음 역할이 포함됩니다.
제품 : 추상 제품
ConcreteProduct : 특정 제품
공장 : 추상 공장
ConcreteFactory : 콘크리트 공장
구조 다이어그램 :
타이밍 다이어그램 :
공장 모드 요약
(1) 적용 가능한 시나리오
수출 된 제품은 표준 제품으로 누구나 할 수 있습니다.
(2) 예
공통 데이터베이스 커넥션 팩토리 인 SqlSessionFactory는 데이터베이스 커넥션인데, oracle에서 제공하는지 mysql에서 제공하는지에 대해서는 sql을 통해 데이터를 조작 할 수 있기 때문에 신경 쓸 필요가 없습니다.
(3)주의가 필요한 사항
프로젝트를 시작할 때 소프트웨어 구조와 요구 사항이 안정적이지 않을 때이 모드를 사용하지 않는 것이 좋습니다. 단점도 분명하고 코드의 복잡성이 증가하고 호출 수준이 증가하며 메모리 부담이 증가하기 때문입니다. 따라서 모델의 남용을 방지하기 위해주의하십시오.
(4) 간단한 구현
package FactoryMethod;
public class FactoryPattern
{
public static void main(String[] args)
{
Factory factory = new ConcreteFactoryA();
Product product = factory.createProduct();
product.use();
}
}
//抽象产品：提供了产品的接口
interface Product
{
public void use();
}
//具体产品A：实现抽象产品中的抽象方法
class ConcreteProductA implements Product
{
public void use()
{
System.out.println("具体产品A显示...");
}
}
//具体产品B：实现抽象产品中的抽象方法
class ConcreteProductB implements Product
{
public void use()
{
System.out.println("具体产品B显示...");
}
}
//抽象工厂：提供了厂品的生成方法
interface Factory
{
public Product createProduct();
}
//具体工厂A：实现了厂品的生成方法
class ConcreteFactoryA implements AbstractFactory
{
public Product createProduct()
{
System.out.println("具体工厂A生成-->具体产品A.");
return new ConcreteProductA();
}
}
//具体工厂B：实现了厂品的生成方法
class ConcreteFactoryB implements AbstractFactory
{
public Product createProduct()
{
System.out.println("具体工厂B生成-->具体产品B.");
return new ConcreteProductB();
}
}
2 Singleton 모드 (Singleton)
웨이 샤오 바오에는 7 명의 아내가 있지만 한 명 한 명은 남편 일 뿐이고 모든 아내를 남편이라고 부를 때 그를 언급하며 그는 단 하나의 사건이다.
싱글 톤 모드 구조
싱글 톤 모드에는 다음 역할이 포함됩니다.
싱글 톤 : 싱글 톤
구조 다이어그램 :
타이밍 다이어그램 :
장점과 단점
장점 : 전체적으로 인스턴스가 하나만있어 통합 제어에 편리하고 시스템 리소스 오버 헤드를 줄입니다.
단점 : 추상화 계층이없고 확장하기 어렵습니다.
응용 시나리오
글로벌 고유 코드 생성기와 같이 글로벌 통합 제어가 필요한 시나리오에 적합합니다.
지침
공개 getInstance 메소드 만 외부 세계에 제공되며 공개 생성자는 제공되지 않습니다.
간단한 구현
public class Singleton
{
private static volatile Singleton instance=null; //保证 instance 在所有线程中同步
private Singleton(){} //private 避免类在外部被实例化
public static synchronized Singleton getInstance()
{
//getInstance 方法前加同步
if(instance == null)
{
instance = new Singleton();
}
return instance;
}
}
3 데코레이터
대학을 졸업 한 후 룸메이트에게 기념 선물을주고 싶었습니다. 모두의 사진을 찾아서 "포에버 브라더!"라고 적고 선물 가게에 가져가 액자를 설치하고 선물 상자에 포장했습니다. 여기 선물 가게와 나는 둘 다 데코레이터이고 둘 다 사진 자체를 바꾸지 않았지만 둘 다 사진을 선물로 더 적합하게 만들었습니다.
장식 패턴 구조
장식 모드에는 다음 역할이 포함됩니다.
구성 요소 : 추상 구성 요소
ConcreteComponent : 콘크리트 구성 요소
데코레이터 : 추상 데코레이션 클래스
ConcreteDecorator : 콘크리트 장식 수업
구조 다이어그램 :
타이밍 다이어그램 :
장점과 단점
장점 : 상속보다 더 유연하고 (상속은 결합 수준이 높은 정적 관계), 동적으로 개체에 책임을 추가 할 수 있으며, 개체 자체에 영향을주지 않고 다른 데코레이터 조합을 사용하여 개체에 대한 N 개의 새로운 기능을 확장 할 수 있습니다.
단점 : 개체에 대한 장식자가 너무 많으면 작은 장식 개체와 장식 조합 전략이 많이 생성되어 시스템의 복잡성이 증가하고 코드 읽기 및 이해 비용이 증가합니다.
해당 장면
(다이아몬드와 같은 구성을 통해) 오브젝트 기능을 동적으로 늘리거나 줄여야하는 장면에 적합합니다.
객체에 N 종류의 기능적 순열 및 조합이 필요한 장면에 적합합니다 (상속을 사용하면 하위 클래스 수가 폭발합니다).
지침
데코 레이팅 된 클래스의 인터페이스는 데코 레이팅 된 클래스의 인터페이스와 동일하게 유지되어야하며, 클라이언트의 경우 데코레이션 전 오브젝트와 데코레이션 후 오브젝트 모두 일관되게 취급 될 수 있습니다.
구체적인 컴포넌트 클래스 Component를 "light"클래스로 유지하십시오. 즉, 구체적인 컴포넌트 클래스에 너무 많은 로직과 상태를 넣지 마십시오. 데코레이션 클래스를 사용할 수 있습니다.
간단한 구현
package decorator;
public class DecoratorPattern
{
public static void main(String[] args)
{
Component component = new ConcreteComponent();
component.operation();
System.out.println("---------------------------------");
Component decorator = new ConcreteDecorator(component);
decorator.operation();
}
}
//抽象构件角色
interface Component
{
public void operation();
}
//具体构件角色
class ConcreteComponent implements Component
{
public ConcreteComponent()
{
System.out.println("创建具体构件角色");
}
public void operation()
{
System.out.println("调用具体构件角色的方法operation()");
}
}
//抽象装饰角色
class Decorator implements Component
{
private Component component;
public Decorator(Component component)
{
this.component=component;
}
public void operation()
{
component.operation();
}
}
//具体装饰角色
class ConcreteDecorator extends Decorator
{
public ConcreteDecorator(Component component)
{
super(component);
}
public void operation()
{
super.operation();
addBehavior();
}
public void addBehavior()
{
System.out.println("为具体构件角色增加额外的功能addBehavior()");
}
}
4 전략 모드 (전략)
남학생은 보통 여학생을 쫓을 때이 모델을 사용합니다. 일반적인 전략에는 다음과 같은 것들이 포함됩니다. 데이트, 영화, 콘서트, 쇼핑, 여행 ... 서로 다른 일을하지만 서로를 대체 할 수 있습니다. 유일한 목표 모두 소녀들의 마음을 사로 잡고 있습니다.
전략 모드 구조
컨텍스트 : 환경 클래스
전략 : 추상 전략 클래스
ConcreteStrategy : 특정 전략 클래스
구조 다이어그램 :
타이밍 다이어그램 :
장점과 단점
장점 : 전략 모드는 "개폐 원칙"에 대한 완벽한 지원을 제공하며 사용자는 원래 시스템을 수정하지 않고도 알고리즘 또는 동작을 선택할 수 있습니다. 복잡하고 추악한 if-else를 죽이십시오.
단점 : 호출 할 때 현재 장면에서 사용할 전략을 직접 결정하기 위해 사용할 수있는 전략 모드 클래스를 미리 알아야합니다.
시험 시나리오
시스템은 여러 대체 알고리즘 중 하나를 동적으로 선택해야합니다. 사용자는 알고리즘의 세부 사항에 신경 쓰지 않고 특정 알고리즘을 전략 클래스로 캡슐화합니다.
지침
전략 클래스의 의견에 전략의 목적과 적용 가능한 시나리오를 설명하십시오.
간단한 구현
package strategy;
public class StrategyPattern
{
public static void main(String[] args)
{
Context context = new Context();
Strategy strategyA = new ConcreteStrategyA();
context.setStrategy(strategyA);
context.algorithm();
System.out.println("-----------------");
Strategy strategyB = new ConcreteStrategyB();
context.setStrategy(strategyB);
context.algorithm();
}
}
//抽象策略类
interface Strategy
{
public void algorithm(); //策略方法
}
//具体策略类A
class ConcreteStrategyA implements Strategy
{
public void algorithm()
{
System.out.println("具体策略A的策略方法被访问！");
}
}
//具体策略类B
class ConcreteStrategyB implements Strategy
{
public void algorithm()
{
System.out.println("具体策略B的策略方法被访问！");
}
}
//环境类
class Context
{
private Strategy strategy;
public Strategy getStrategy()
{
return strategy;
}
public void setStrategy(Strategy strategy)
{
this.strategy=strategy;
}
public void algorithm()
{
strategy.algorithm();
}
}
5 프록시 모드 (프록시)
Taobao 상점 고객 서비스는 항상 다음과 같은 반복 질문을 많이 받게됩니다. 재고가 있습니까? 언제 배송됩니까? 어떤 종류의 신속 배송입니까? 많은 반복적 인 질문에 답하는 것이 너무 귀찮아서 샤오 미 로봇이 나타나 고객 서비스를 도와 알려진 질문에 답했고 샤오 미가 대답 할 수없는 질문을 만나면 수동 고객 서비스로 이동했습니다. 여기에서 Xiaomi 로봇은 고객 서비스 에이전트입니다.
대행사 모델 구조
프록시 모드에는 다음 역할이 포함됩니다.
주제 : 추상 주제 역할
프록시 : 프록시 테마 역할
RealSubject : 실제 주제 역할
구조 다이어그램 :
타이밍 다이어그램 :
장점과 단점
장점 : 상담원이 발신자와 수신자를 조정할 수 있으므로 시스템의 결합이 줄어 듭니다. 다양한 에이전트 유형 및 시나리오에 따라 보안을 제어하고 시스템 오버 헤드를 줄이는 역할을 할 수 있습니다.
단점 : 프록시 처리 계층이 추가되어 시스템의 복잡성이 증가하고 해당 시스템의 속도가 저하 될 수 있습니다.
시험 시나리오
이론적으로는 모든 객체를 프록시 할 수 있습니다. 일반적인 프록시 모드는 다음과 같습니다.
원격 프록시 : 다른 주소 공간에있는 개체에 대한 로컬 프록시 개체를 제공합니다.이 다른 주소 공간은 동일한 호스트 또는 다른 호스트에있을 수 있습니다. 원격 프록시는 대사 ( 대사).
가상 에이전트 : 많은 리소스를 소비하는 객체를 생성해야하는 경우 먼저 상대적으로 적은 양을 소비하는 객체를 생성하여 표현합니다. 실제 객체는 필요할 때만 생성됩니다.
Copy-on-Write 에이전트 : 클라이언트가 실제로 필요할 때만 실행될 때까지 복사 (복제) 작업을 지연시키는 가상 에이전트 유형입니다. 일반적으로 개체의 전체 복제 작업은 비용이 많이 드는 작업입니다. Copy-on-Write 에이전트는이 작업을 지연시킬 수 있으며 개체는 사용되는 경우에만 복제됩니다.
보호 (보호 또는 액세스) 에이전트 : 개체에 대한 액세스를 제어하고 다양한 사용자에게 다양한 수준의 액세스를 제공 할 수 있습니다.
캐시 에이전트 : 여러 클라이언트가 이러한 결과를 공유 할 수 있도록 특정 대상 작업의 결과를위한 임시 저장 공간을 제공합니다.
방화벽 (방화벽) 프록시 : 악의적 인 사용자로부터 대상을 보호합니다.
동기화 (동기화) 에이전트 : 여러 사용자가 충돌없이 동시에 개체를 사용할 수 있도록합니다.
스마트 참조 에이전트 : 개체가 참조되면 개체가 호출 된 횟수를 기록하는 것과 같은 몇 가지 추가 작업을 제공합니다.
간단한 구현
package proxy;
public class ProxyPattern
{
public static void main(String[] args)
{
Proxy proxy = new Proxy();
proxy.request();
}
}
//抽象主题
interface Subject
{
void request();
}
//真实主题
class RealSubject implements Subject
{
public void request()
{
System.out.println("访问真实主题方法...");
}
}
//代理
class Proxy implements Subject
{
private RealSubject realSubject;
public void request()
{
if (realSubject==null)
{
realSubject=new RealSubject();
}
preRequest();
realSubject.request();
afterRequest();
}
public void preRequest()
{
System.out.println("访问真实主题之前的预处理。");
}
public void afterRequest()
{
System.out.println("访问真实主题之后的后续处理。");
}
}
6 관찰자 모드 (관찰자)
출장 중이고 집에서 자녀의 상황을 알고 싶습니다. 지금은 "가족 가족"그룹에 가입하기 만하면됩니다. 엄마와 아빠는 종종 자녀의 사진과 동영상을 그룹에 게시합니다. 여러분이해야 할 일은 관찰자가되는 것입니다. 그룹의 정보를 스 와이프하여 모든 것을 이해할 수 있습니다.
관찰자 패턴 구조
관찰자 모드에는 다음 역할이 포함됩니다.
제목 : target
ConcreteSubject : 구체적인 목표
관찰자 : 관찰자
ConcreteObserver : 특정 관찰자
구조 다이어그램 :
타이밍 다이어그램 :
장점과 단점
장점 : 복잡한 직렬 처리 논리를 통합 된 독립 처리 논리로 전환합니다. 관찰자는 자신의 논리에 따라 메시지를 전송하고 누가 메시지를 소비하는지는 신경 쓰지 않습니다. 각 관찰자는 자신이 관심있는 것만 처리합니다. 논리 격리는 간단하고 새로운 코드 구조를 제공합니다.
단점 : 관찰자가 많을 때 메시지를 보내는 데 일정량의 오버 헤드를 소비 할 수 있지만 메시지는 한 명의 관찰자 만 사용할 수 있습니다.
해당 장면
일대 다 비즈니스 시나리오에 적합하며, 하나의 객체가 변경되면 N 개의 객체가 해당 처리를 수행하도록 트리거합니다. 예 : 주문 예약 알림, 작업 상태 변경 등
지침
관찰자와 관찰자 사이에 순환 종속성을 형성하지 마십시오. 시스템이 중단 될 수 있습니다.
간단한 구현
package observer;
import java.util.*;
public class ObserverPattern
{
public static void main(String[] args)
{
Subject subject = new ConcreteSubject();
Observer obsA = new ConcreteObserverA();
Observer obsb = new ConcreteObserverB();
subject.add(obsA);
subject.add(obsB);
subject.setState(0);
}
}
//抽象目标
abstract class Subject
{
protected List<Observer> observerList = new ArrayList<Observer>();
//增加观察者方法
public void add(Observer observer)
{
observers.add(observer);
}
//删除观察者方法
public void remove(Observer observer)
{
observers.remove(observer);
}
public abstract void notify(); //通知观察者方法
}
//具体目标
class ConcreteSubject extends Subject
{
private Integer state;
public void setState(Integer state){
this.state = state;
// 状态改变通知观察者
notify();
}
public void notify()
{
System.out.println("具体目标状态发生改变...");
System.out.println("--------------");
for(Observer obs:observers)
{
obs.process();
}
}
}
//抽象观察者
interface Observer
{
void process(); //具体的处理
}
//具体观察者A
class ConcreteObserverA implements Observer
{
public void process()
{
System.out.println("具体观察者A处理！");
}
}
//具体观察者B
class ConcreteObserverB implements Observer
{
public void process()
{
System.out.println("具体观察者B处理！");
}
}
방법은 없지만 기술은 달성 할 수 있습니다. 방법이 없으면 기술로 끝납니다.
모두가 Java Way 공용 계정 을 따르도록 환영 합니다.
좋은 기사, 읽고 있습니다 ❤️