디자인 패턴은 디자인 수준 솔루션을 위한 반복되는 문제는 우리가 소프트웨어 엔지니어를 건너 많습니다. 그것은 코드가 아닙니다-나는 반복한다,❌코드. 이러한 문제를 해결하고 솔루션을 설계하는 방법에 대한 설명과 같습니다.
를 사용하여 이러한 패턴으로 간주 좋은 연습으로 디자인의 솔루션은 매우 시도하고 테스트 결과 가독성 높은 최종의 코드입니다., 디자인 패턴은 자주 만들고 사용하는 OOP 언어,Java,에서는 대부분의 예에서 여기에 기록됩니다.
형식의 디자인 패턴
있는 약 26 패턴 현재 발견(나는 거라 생각을 할 것이다.).
이들 26 은 3 가지 유형으로 분류 될 수있다:
1. Creational:이러한 패턴은 클래스 인스턴스화를 위해 설계되었습니다. 클래스 생성 패턴 또는 객체 생성 패턴 일 수 있습니다.피>2. 구조적:이러한 패턴은 클래스의 구조 및 구성과 관련하여 설계되었습니다., 이러한 패턴의 대부분의 주요 목표는 구성의 대부분을 변경하지 않고 관련된 클래스(es)의 기능을 높이는 것입니다.피>3. 행동:이러한 패턴은 한 클래스가 다른 클래스와 통신하는 방식에 따라 설계되었습니다.
이 게시물에서는 분류 된 유형마다 하나의 기본 디자인 패턴을 살펴 보겠습니다.
유형 1:을 생성-단일 디자인 패턴
단일 디자인 패턴은 패턴을 생성,그 목표를 만드는 단 하나의 클래스의 인스턴스를 제공하는 단 하나의 글로벌 액세스 포인트하는 개체입니다., Java 에서 이러한 클래스의 일반적으로 사용되는 예 중 하나는 Calendar 이며,여기서 해당 클래스의 인스턴스를 만들 수 없습니다. 또한 자체getInstance()메소드를 사용하여 사용할 객체를 가져옵니다.
클래스를 사용하는 단일 디자인 패턴을 포함됩니다.
- 적인 변수를 잡고,유일한 클래스의 인스턴스.
- 개인 생성자이므로 다른 곳에서는 인스턴스화 할 수 없습니다.
- 클래스의 단일 인스턴스를 반환하는 공용 정적 메소드입니다.,
싱글 톤 디자인의 많은 다른 구현이 있습니다. 오늘은;
1 의 구현을 살펴 보겠습니다. 열망하는 인스턴스화
2. 게으른 인스턴스화
3. 스레드에 안전한 인스턴스
열심 비버
public class EagerSingleton {// create an instance of the class.private static EagerSingleton instance = new EagerSingleton();// private constructor, so it cannot be instantiated outside this class.private EagerSingleton() { }// get the only instance of the object created.public static EagerSingleton getInstance() {return instance;}}이 유형의 인스턴스화 중에 일어나는 클래스 로드,으로 인스턴스화하는 변수의 인스턴스 밖에서 일어나는 어떤 방법입니다. 이 클래스가 클라이언트 응용 프로그램에서 전혀 사용되지 않는 경우 큰 단점이 있습니다. 이 클래스를 사용하지 않는 경우 비상 계획은 게으른 인스턴스화입니다.,
Lazy Days
위의 구현과 많은 차이가 없습니다. 주요한 차이는 정적 변수는 처음에 선언 null,단지 내에서 인스턴스화getInstance()경우 방법과하는 경우에만-인스턴스의 변수가 null 로 유지시에 확인합니다.
이것은 하나의 문제를 해결하지만 다른 하나는 여전히 존재합니다. 두 개의 서로 다른 클라이언트가 밀리 초에 바로 싱글 톤 클래스에 동시에 액세스한다면 어떨까요?, 글쎄,그들이 확인하는 경우에는 인스턴스가 null,같은 시간에 찾을 수 있습니다 그것은 사실,그리고 그렇게 만들 것이 두 개의 클래스의 인스턴스에 대한 각각의 요청에 의해 두 개의 클라이언트입니다. 이 문제를 해결하려면 스레드 안전 인스턴스화를 구현해야합니다.
(Thread)안전은 키
Java,키워드 동기화에 사용되는 방법이나 객체를 구현하는 스레드에 안전하는 단 하나의 스레드는 특정 리소스에 액세스 중 하나에서 시간입니다. 클래스 인스턴스화는 주어진 시간에 하나의 클라이언트 만 메소드에 액세스 할 수 있도록 동기화 된 블록 내에 배치됩니다.,
동기화 된 메소드의 오버 헤드가 높으면 전체 작업의 성능이 저하됩니다.
경우,예를 들어,인스턴스의 변수 이미 인스턴스화한 다음 각 시간이 어떤 클라이언트에 액세스하는getInstance()방법을synchronized방법은 실행하고 성능이 떨어진다. 이것은 단지instance변수의 값이 null 인지 확인하기 위해 발생합니다. 그것이 있다는 것을 알게되면 메소드를 떠납니다. 이 오버 헤드를 줄이려면 이중 잠금이 사용됩니다., 체크하기 전에 사용되는synchronized방법뿐만 아니라면 이 값은 null,혼자는synchronized방법을 실행합니다.
이제 다음 분류에.
유형 2:구조상-장식한 디자인 패턴
나는 당신에게 작은 시나리오게 더 나은 컨텍스트가 사용해야 하는 장식 패턴이다.
말은 당신의 자신의 커피숍와 같은 어떤 사용자의 시작 단지 두 가지 유형의 보통 커피,집에 혼합하고 어두운 로스트., 청구 시스템에는 음료 추상 클래스를 상속하는 다른 커피 블렌드에 대해 하나의 클래스가있었습니다. 사람들은 실제로 와서 당신의 멋진(씁쓸하지만?)커피. 그런 다음 신이 금지 한 설탕이나 우유를 원하는 커피 뉴브가 있습니다. 커피에 대한 그런 여행!! ??
지금 당신은 메뉴와 불행하게도 결제 시스템에 모두뿐만 아니라 그 두 가지 추가 기능을해야합니다. 원래,당신의 IT 사람은 설탕,다른 우유를 포함한 두 커피의 하위 클래스를 만들 것입니다., 그런 다음 이후로 고객에게는 항상 옳다 하는 말이 두려워 말
“을 얻을 수 있습니 우유,커피,설탕을까요?”
???
다시 당신의 얼굴에 웃고 청구 시스템이 간다. 글쎄,다시 드로잉 보드로….
그런 다음 IT 사람은 설탕이 든 우유 커피를 각 부모 커피 클래스에 다른 하위 클래스로 추가합니다. 달의 나머지 부분은 부드러운 항해,사람들이 일렬로 당신의 커피,당신은 실제로 돈을 버. ??
하지만 잠깐,더있다!
세상은 다시 한번 당신을 반대합니다., 경쟁자는 4 가지 유형의 커피뿐만 아니라 10 가지 이상의 부가 기능뿐만 아니라 길 건너편에서 열립니다! ?
을 구입하는 모든 사람들과 더 많은,더 나은 판매하는 커피 자신이며,단지 그 기억을 잊을 하는 업데이트 dratted 결제 시스템입니다. 당신은 아마도 할 수 없습니다 무한한 수의 서브 클래스에 대한 모든 조합의 모든 기능을 추가,새로운 커피 블렌드 too. 말할 것도없고,최종 시스템의 크기.??적절한 청구 시스템에 실제로 투자 할 시간입니다., 당신을 찾아 새로운 직원에게 실제로 그들이 무엇을 알고 있는 그들은 말;
“왜,이는 너무 쉽게 될 것입니다 작은 경우 사용되는 장식 패턴이다.”
지구상에서 그게 뭐야?
장식한 디자인 패턴으로 카테고리 구조,그 상품으로 실제 구조의 클래스가 여부,상속에 의해,조합니다. 이 디자인의 목표는 런타임에 객체의 기능을 수정하는 것입니다. 이것은 추상 클래스와 컴포지션과의 인터페이스를 활용하여 원하는 결과를 얻는 많은 다른 디자인 패턴 중 하나입니다.,
수학에게 기회를 줍시다(전율? 준)이 모든 관점으로;
4 개의 커피 블렌드와 10 추가 기능. 만약 우리가 붙어 세대의 서브 클래스에 대한 각각 다른 모든 조합에 대한 추가 기능을 한 종류의 커피입니다. 그;
(10-1)2=92=81 서브 클래스가
우리는 빼기 1 에서 10,으로 결합할 수 없습니다 하나가 다른 동일한 유형의 설탕,설탕과 바보 소리. 그리고 그것은 단지 하나의 커피 블렌드를위한 것입니다. 그 81 을 4 로 곱하면 무려 324 개의 다른 하위 클래스를 얻을 수 있습니다!, 그 모든 코딩에 대해 이야기하십시오…
하지만 데코레이터 패턴을 사용하면이 시나리오에서 16 개의 클래스 만 필요합니다. 싶어 내기?
경우 우리는 우리의 시나리오에 따른 클래스 다이어그램을 위 우리는 4 클래스를 위한 4 개의 커피 블렌드,10 에 대한 각각의 추가 및 1 에 대한 추상적인 요소이며 1 위해 더 추상적인 장식. 참조! 16!, 이제 그 100 달러를 넘겨주세요.?? (jk 지만,그것을 거부할 수 없습니다 주어진다면 그냥 말하는)
에서 볼 수 있듯이 위로,콘크리트 커피 블렌드는 하위 클래스로 음료의 추상 클래스,애드온에 추상 클래스를 상속하는 방법이다. 해당 하위 클래스 인 추가 기능은 필요할 때 기본 객체에 기능을 추가하는 새로운 메소드를 상속합니다.
사용중인 패턴을 보려면 코딩에 가자.,
첫 번째를 추상적인 음료 클래스에는 모든 다른 커피 블렌드를 상속 하는 것입니다.
다음에 추가로 콘크리트 커피 블렌드 클래스입니다.
AddOn abstract 클래스는 Beverage abstract 클래스에서도 상속됩니다(아래에서 자세히 설명합니다).
이제 구체적인 구현에서는 이 추상 클래스:
위에서 볼 수 있듯이,우리는 전달할 수 있습의 모든 하위 클래스로 음료의 모든 하위 클래스는 애드온을 얻을 추가 비용을 뿐 아니라 업데이트한 설명이 있습니다. 그리고 애드온 클래스는 본질적으로 유형 음료이므로 애드온을 다른 애드온으로 전달할 수 있습니다., 이런 식으로,우리는 특정 커피 블렌드에 어떤 수의 부가 기능을 추가 할 수 있습니다.이제 이것을 테스트 할 코드를 작성하십시오.
최종 결과:
It works! 우리는 할 수 있었다 추가 더 이상의 추가에는 커피 블렌드와 성공적으로 업데이트를 최종 비용과 설명이 필요하지 않음 무한한 서브 클래스에 대한 각각의 추가 조합에 대한 모든 커피를 이용할 수 있습니다.
마지막으로,마지막 카테고리로.,
유형 3:행동은 명령어 디자인 패턴
행동 디자인 패턴는 방법에 초점을 맞추고 있는 클래스 및 객체를 서로 통신한다. 주요 초점을 명령의 패턴은 가르치다 높은 수준의 느슨한 카플링 사이의 관련 당사자(읽기:클래스).
Uhhhh…그게 뭐야?
커플 링은 서로 잘 상호 작용하는 두 개(또는 그 이상)클래스가 상호 작용하는 방식입니다. 이러한 클래스가 상호 작용할 때 이상적인 시나리오는 서로 크게 의존하지 않는다는 것입니다. 즉 느슨한 커플 링입니다., 따라서 느슨한 커플 링에 대한 더 나은 정의는 서로 연결되어 서로를 가장 적게 사용하는 클래스가 될 것입니다.
이 필요한 패턴이 일어났을 때 요청하는 데 필요한 보낼 수 없는 의식적으로 알고 당신이 무엇을 요청하는 사람 또는 수신기입니다.
이 패턴에서 호출 클래스는 실제로 작업을 수행하는 클래스에서 분리됩니다. 호출자 클래스에는 클라이언트가 요청할 때 필요한 명령을 실행하는 호출 가능한 메소드 실행 만 있습니다.
멋진 식당에서 식사를 주문하는 기본적인 실제 예를 들어 보겠습니다., 으로 흐름을 간다,당신은 당신의 순서로(명령)을 웨이터(호출자),누가 손을 통해 요리사(receiver),그래서 당신은 음식을 얻을 수 있습니다. 간단하게 들릴지 모르지만…
아이디어 아주 간단하지만 코딩은 코입니다.,
의 흐름 작업을 기술적 측면에서는,당신은 구체적인 명령을 구현하는 명령 인터페이스,요청의 수신기를 완료하는 작업,그리고 보낼 경우에도 명령을 호출자. 호출자는이 명령을 내릴 때를 아는 사람입니다. 요리사는 특정 명령/순서가 주어 졌을 때해야 할 일을 아는 유일한 사람입니다., 그래서 때,실행 방법의 호출자는,그것은,차례차례로,원인은 명령 객체의 실행 방법에서 실행하는 수신기,따라서 완료 필요한 작업입니다.,
우리가 무엇을 구현해야 할;
- 인터페이스는 명령
- 기 위해 클래스를 구현하는 명령어 인터페이스
- 클래스 웨이터(호출자)
- 클래스 요리사(receiver)
게 코딩은 다음과 같습니다.
요리사 수신기
명령 인터페이스
public interface Command {public abstract void execute();}순서,구체적인 명령
,웨이터를 호출자
public class Waiter {private Order order;public Waiter(Order ord) {this.order = ord;}public void execute() {this.order.execute();}}당신은 클라이언트
위에서 볼 수 있듯이,클라이언트에게는 순서와 설정합 수신기로 요리사가 있습니다., 주문은 웨이터에게 보내지며,주문을 언제 실행해야하는지(즉,요리사에게 요리 명령을 내릴 때)알 수 있습니다. 호출자가 실행되면 Orders’execute 메소드가 수신기에서 실행됩니다(즉,요리사가 요리 파스타 중 하나에 명령을 받습니까? 아니면 케이크를 구워?).,
Quick recap
이 글에서는 우리를 통해 갔다.
- 어떤 디자인 패턴은 정말,
- 다른 형태의 디자인 패턴과 그들은 왜 다른
- 중 하나 기본적인 또는 일반적인 디자인 패턴에 대한 각 유형
이 도움이되었다.
게시물의 코드 repo 를 찾으십시오.피>