Factory 메소드는 객체 생성과 관련된 생성 디자인 패턴입니다. Factory 패턴에서는 생성 로직을 클라이언트에 노출시키지 않고 객체를 생성하고 클라이언트는 동일한 공통 인터페이스를 사용하여 새로운 유형의 객체를 생성합니다.
아이디어는
을 생성하는 정적 멤버 함수 (정적 팩토리 메서드)를 사용하는 것입니다. div id = “b5d7d479ba”>
는 인스턴스를 반환하여 사용자에게 클래스 모듈의 세부 정보를 숨 깁니다.
팩토리 패턴은 클라이언트가 개체를 만들 수 있도록 개체를 만드는 핵심 디자인 원칙 중 하나입니다. 라이브러리의 클래스 계층 구조와 밀접하게 연결되지 않도록 라이브러리 (아래에 설명).
라이브러리와 클라이언트에 대해 이야기 할 때 무엇을 의미합니까?
라이브러리 일부 공용 API를 노출하고 클라이언트가 해당 작업을 완료하기 위해 해당 공용 API를 호출하는 일부 타사에서 제공하는 것입니다. 매우 간단한 예는 Android OS에서 제공하는 다양한 종류의 뷰일 수 있습니다.
왜 팩토리 패턴인가요?
예를 들어 이해해 봅시다.
출력 :
I am two wheeler
위 디자인의 문제점은 무엇입니까?
위의 예에서 관찰했듯이 클라이언트는 TwoWheeler의 객체를 생성합니다. 또는 객체를 구성하는 동안 일부 입력을 기반으로 FourWheeler.
예를 들어, 라이브러리는 3 륜 차량을 통합하는 새로운 클래스 ThreeWheeler를 도입합니다. 무슨 일이 일어날 지? 클라이언트는 ThreeWheeler의 개체를 생성하기 위해 조건부 래더에있는 경우 새로운 else를 연결하게됩니다. 클라이언트를 다시 컴파일해야합니다. 따라서 라이브러리 측에서 새로운 변경이 이루어질 때마다 클라이언트는 끝에 해당하는 변경을 수행하고 코드를 다시 컴파일해야합니다. 나쁘게 들리나요? 이것은 매우 나쁜 디자인 관행입니다.
문제를 피하는 방법은 무엇입니까?
정답은 정적 (또는 팩토리) 메서드를 만드는 것입니다. 아래 코드를 보겠습니다.
출력 :
I am three wheeler
위 예제에서는 클라이언트에서 개체 생성을위한 유형 선택을 완전히 분리했습니다. 이제 라이브러리는 입력을 기반으로 생성 할 객체 유형을 결정해야합니다. 클라이언트는 라이브러리의 팩토리 Create 메소드를 호출하고 객체 생성의 실제 구현에 대해 걱정하지 않고 원하는 유형을 전달하기 만하면됩니다.
위의 설명을 제공해 주신 Rumplestiltskin에게 감사드립니다.
공장 방법의 다른 예 :
- ‘그리기’시스템에서 사용자의 입력에 따라 정사각형, 직사각형, 원형과 같은 다른 그림을 그릴 수 있다고 말합니다. 여기서는 팩토리 메서드를 사용하여 사용자 입력에 따라 인스턴스를 만들 수 있습니다. 새로운 유형의 모양을 추가하기 위해 고객의 코드를 변경할 필요가 없습니다.
- 다른 예 : 여행 사이트에서 기차표와 버스 표 및 항공권을 예약 할 수 있습니다. 이 경우 사용자는 자신의 여행 유형을 ‘bus’, ‘train’또는 ‘flight’로 지정할 수 있습니다.
여기에는 사용자의 여행 유형에 따라 정적 멤버 함수 ‘GetObject’가있는 추상 클래스 ‘AnyTravel’이 있습니다. ‘BusTravel’또는 ‘TrainTravel’의 & 반환 개체를 만듭니다. ‘BusTravel’또는‘TrainTravel’에는 승객 이름, 출발지, 목적지 매개 변수와 같은 공통 기능이 있습니다.
처음 두 가지 예를 제공하는 Abhijit Saha에게 감사드립니다.
