생성 패턴

3.1 싱글턴

Singleton은 단일 스레드 응용 프로그램이 일부 클래스의 단일 인스턴스를 갖도록 보장하고 이 인스턴스에 대한 전역 액세스 지점을 제공하는 일반적인 디자인 패턴입니다.

종종 초보 프로그래머는 유틸리티 메서드를 일부 정적 클래스(정적 메서드만 포함하는 클래스)로 어셈블하는 것을 좋아합니다. 이 접근 방식에는 여러 가지 단점이 있습니다. 예를 들어 이러한 클래스의 개체에 대한 참조를 전달할 수 없으며 이러한 메서드는 테스트하기 어렵습니다.

대안으로 싱글톤 클래스 솔루션이 제안되었습니다. 하나의 객체만 가질 수 있는 클래스입니다. 이 개체를 만들려고 하면 아직 존재하지 않는 경우에만 만들어지고 그렇지 않으면 이미 존재하는 인스턴스에 대한 참조가 반환됩니다.

많은 경우 더 많은 기능을 사용할 수 있으므로 클래스의 인스턴스를 사용할 수 있어야 합니다. 예를 들어 이 클래스는 일부 인터페이스를 구현할 수 있으며 해당 개체는 인터페이스 구현으로 다른 메서드에 전달될 수 있습니다. 일련의 정적 메소드로 수행할 수 없는 것.

장점:

• 메서드는 정적 클래스가 아닌 개체에 바인딩됩니다. 개체를 참조로 전달할 수 있습니다.
• 개체 메서드는 테스트하고 모의하기가 훨씬 쉽습니다.
• 객체는 필요할 때만 생성됩니다: 게으른 객체 초기화.
• 출시에 필요하지 않은 싱글이 많은 경우 프로그램의 초기 출시를 가속화합니다.
• 단독으로 템플릿 전략 또는 여러 개체로 추가 전환될 수 있습니다.

단점:

• 스레드 간 경쟁 및 지연을 제어하기가 더 어려워집니다.
• "머리에서" 멀티 스레드 "외톨이"를 작성하는 것은 어렵습니다. 이상적으로는 오랜 싱글 톤에 대한 액세스가 뮤텍스를 열지 않아야합니다. 더 나은 검증된 솔루션.
• 완료되지 않은 단일 스레드에 대한 두 스레드 간의 충돌로 인해 지연이 발생합니다.
• 개체가 오랫동안 생성되는 경우 지연이 사용자를 방해하거나 실시간을 방해할 수 있습니다. 이 경우 프로그램 초기화 단계로 생성을 전송하는 것이 좋습니다.
• 단위 테스트에는 특수 기능이 필요합니다. 예를 들어 라이브러리를 "non-lonely" 모드로 설정하고 테스트를 서로 완전히 격리합니다.
• 실행 가능성은 구성에 따라 달라지기 때문에 "가장 간단한 실행 가능성"이라는 개념조차 사라지기 때문에 완성된 프로그램을 테스트하기 위한 특별한 전술이 필요합니다.

3.2 공장[방법]

팩토리 메서드는 특정 클래스의 인스턴스를 생성하기 위한 인터페이스를 하위 클래스(클래스-상속자)에 제공하는 일반적인 디자인 패턴입니다. 생성 시 자손은 생성할 클래스를 결정할 수 있습니다.

즉, 이 템플릿은 개체 생성을 부모 클래스의 자손에게 위임합니다. 이를 통해 프로그램 코드에서 구체적인 클래스를 사용하지 않고 상위 수준에서 추상 개체를 조작할 수 있습니다.

이 패턴은 개체를 만들기 위한 인터페이스를 정의하지만 개체를 ​​기반으로 할 클래스를 결정하는 것은 하위 클래스에 맡깁니다. 팩터리 메서드를 사용하면 클래스가 하위 클래스 생성을 위임할 수 있습니다. 다음과 같은 경우에 사용:

• 클래스는 생성해야 하는 하위 클래스의 객체를 미리 알지 못합니다.
• 클래스는 생성하는 개체가 하위 클래스에 의해 지정되도록 설계되었습니다.
• 클래스는 여러 도우미 하위 클래스 중 하나에 책임을 위임하고 이러한 책임을 맡을 클래스를 결정할 계획입니다.

3.3 추상 공장

추상 팩토리는 구체적인 클래스를 지정하지 않고 관련되거나 상호 의존적인 개체군을 만들기 위한 인터페이스를 제공하는 일반적인 디자인 패턴입니다.

패턴은 시스템 구성요소를 생성하기 위한 인터페이스인 추상 클래스 Factory를 생성하여 구현됩니다(예: 창 인터페이스의 경우 창과 버튼을 생성할 수 있음). 그런 다음 이 인터페이스를 구현하는 클래스가 작성됩니다.

프로그램이 생성된 새 개체의 프로세스 및 유형과 독립적이어야 하는 경우에 사용됩니다. 동일한 컨텍스트에서 서로 다른 세트의 객체를 동시에 사용할 가능성을 제외하고 관련 객체의 패밀리 또는 그룹을 생성해야 하는 경우.

강점:

• 특정 클래스를 격리합니다.
• 제품군 교체를 단순화합니다.
• 제품 호환성을 보장합니다.

프로그램이 파일 시스템과 함께 작동한다고 가정해 봅시다. 그런 다음 Linux에서 작업하려면 LinuxFile, LinuxDirectory, LinuxFileSystem 객체가 필요합니다. 그리고 Windwos에서 작업하려면 WindowsFile, WindowsDirectory, WindowsFileSystem 클래스가 필요합니다.

Path.of()를 통해 생성되는 Path 클래스가 바로 그러한 경우입니다. Path는 실제로 클래스가 아니라 인터페이스이며 WindowsPath 및 LinuxPath 구현이 있습니다. 그리고 어떤 종류의 개체가 생성될지는 코드에서 숨겨지며 런타임에 결정됩니다.

3.4 프로토타입

프로토타입은 제너레이티브 디자인 패턴입니다.

이 패턴은 프로토타입 인스턴스를 사용하여 생성되는 객체의 종류를 정의하고 이 프로토타입을 복사하여 새로운 객체를 생성합니다. 구현에서 벗어나 "인터페이스를 통한 프로그래밍" 원칙을 따를 수 있습니다.

계층 구조의 맨 위에 있는 인터페이스/추상 클래스는 반환 유형으로 지정되며 자손 클래스는 이 유형을 구현하는 상속자를 대체할 수 있습니다. 간단히 말해서 생성자를 통해 생성하지 않고 다른 객체를 복제하여 객체를 생성하는 패턴입니다.

패턴은 다음 용도로 사용됩니다.

• 표준 방식(이 경우 전체 개체의 조상 계층 구조의 생성자도 호출되기 때문에 생성자를 사용하는 것을 의미)으로 객체를 생성하는 추가 노력을 피합니다.
• 추상 팩터리 패턴처럼 클라이언트 응용 프로그램에서 객체 생성자를 상속하지 마십시오.

프로그램이 제품을 생성, 구성 및 표시하는 방법에 관심이 없을 때 이 디자인 패턴을 사용합니다.

• 인스턴스화된 클래스는 예를 들어 동적 로딩을 사용하여 런타임에 결정됩니다.
• 제품 클래스 계층 구조와 평행한 클래스 또는 팩토리 계층 구조를 구축하지 않으려고 합니다.
• 클래스 인스턴스는 여러 상태 중 하나일 수 있습니다. 매번 적절한 상태로 클래스를 수동으로 인스턴스화하는 것보다 적절한 수의 프로토타입을 설정하고 복제하는 것이 더 편리할 수 있습니다.