팩토리와 추상 팩토리 디자인 패턴의 기본 차이점은 무엇입니까? [닫은]
팩토리 패턴과 추상 팩토리 패턴의 기본 차이점은 무엇입니까?
공장 패턴을 사용하면 구현의 인스턴스 (생산 Apple, Banana, Cherry, 말 - 특정 인터페이스의 등) IFruit.
추상 팩토리 패턴을 사용하면 누구나 자신의 팩토리를 제공 할 수있는 방법을 제공합니다. 이웨어 하우스가 될 수 있습니다 어느 쪽 IFruitFactory또는 IJuiceFactory과일이나 주스에 대해 알 창고를 요구하지 않고,.
이 정보의 출처 : http://java.dzone.com/news/intro-design-patterns-abstract
추상 팩토리 vs. 팩토리 메소드
추상 팩토리의 메소드는 팩토리 메소드로 구현됩니다. 추상 팩토리 패턴과 팩토리 메소드 패턴은 추상 유형 및 팩토리를 통해 클라이언트 시스템을 실제 구현 클래스에서 분리합니다. 팩토리 메소드는 추상 팩토리가 컴포지션을 통해 오브젝트를 작성하는 상속을 통해 오브젝트를 작성합니다.
추상 팩토리 패턴은 AbstractFactory, ConcreteFactory, AbstractProduct, ConcreteProduct 및 Client로 구성됩니다.
구현하는 방법
팩토리 메소드 패턴, 프로토 타입 패턴 또는 싱글 톤 패턴을 사용하여 추상 팩토리 패턴을 구현할 수 있습니다. ConcreteFactory 객체는 하나의 ConcreteFactory 객체 인스턴스 만 필요하므로 Singleton으로 구현할 수 있습니다.
팩토리 메소드 패턴은 추상 팩토리 패턴의 단순화 된 버전입니다. 팩토리 메소드 패턴은 한 제품군에 속하는 제품을 작성하는 반면 추상 팩토리 패턴은 여러 제품군을 처리합니다.
팩토리 메소드는 인터페이스와 추상 클래스를 사용하여 클라이언트를 생성기 클래스와 결과 제품에서 분리합니다. Abstract Factory에는 여러 팩토리 메소드를위한 컨테이너 인 생성기가 있으며 클라이언트와 생성기 및 제품을 분리하는 인터페이스가 있습니다.
팩토리 메소드 패턴을 사용하는 경우
클라이언트를 사용하는 특정 제품에서 클라이언트를 분리해야하는 경우 팩토리 메소드 패턴을 사용하십시오. 팩토리 메소드를 사용하여 제품 인스턴스 작성 및 구성에 대한 책임을 클라이언트에게 줄이십시오.
추상 팩토리 패턴을 사용하는 경우
클라이언트가 제품 클래스에서 분리되어야하는 경우 추상 팩토리 패턴을 사용하십시오. 프로그램 구성 및 수정에 특히 유용합니다. Abstract Factory 패턴은 다른 클래스와 함께 사용해야하는 클래스에 대한 제한 조건을 시행 할 수도 있습니다. 새로운 콘크리트 공장을 만드는 것은 많은 작업 일 수 있습니다.
예 :
추상 팩토리 예 1
파스타 제조업체에서 디스크가 다른 유형의 파스타를 준비하기위한이 사양은 Abstract Factory이며 각 특정 디스크는 Factory입니다. 모든 팩토리 (파스타 메이커 디스크)는 추상 팩토리에서 속성을 상속합니다. 각 개별 디스크에는 파스타를 만드는 방법에 대한 정보가 포함되어 있지만 파스타 메이커에는 없습니다.
추상 팩토리 예제 2 :
스탬핑 장비는 추상 제품 객체를 생성하는 작업을위한 인터페이스이므로 Abstract Factory에 해당합니다. 다이는 콘크리트 제품을 만들 때 콘크리트 팩토리에 해당합니다. 각 부품 범주 (후드, 도어 등)는 추상 제품에 해당합니다. 특정 부품 (즉, 99 캠리 용 운전자 측면 도어)은 콘크리트 제품에 해당합니다.
공장 방법 예 :
완구 회사는 팩토리를 사용하여 제품 오브젝트를 작성할 수 있으므로 Creator에 해당합니다. 특정 유형의 장난감 (말 또는 자동차)을 제조하는 장난감 회사의 부서는 ConcreteCreator에 해당합니다.
팩토리 패턴 : 팩토리는 IProduct 구현을 생성합니다
추상 팩토리 패턴 : 팩토리 팩토리는 IFactories를 생성하며, 이로 인해 IProducts가 생성됩니다.
[의견에 따라 업데이트]
내가 이전에 쓴 것은 적어도 위키 백과 에 따르면 정확하지 않습니다 . 추상 팩토리는 단순히 팩토리 인터페이스입니다. 이를 통해 런타임에 팩토리를 전환하여 다른 컨텍스트에서 다른 팩토리를 허용 할 수 있습니다. OS, SQL 공급자, 미들웨어 드라이버 등의 팩토리가 다를 수 있습니다.
추상 팩토리 패턴
구체적인 클래스를 지정하지 않고 관련 또는 종속 객체의 패밀리를 작성하기위한 인터페이스를 제공하십시오.
추상 팩토리 패턴은 팩토리 메소드 패턴과 매우 유사합니다. 두 가지 차이점 중 하나는 Abstract Factory 패턴을 사용하면 클래스가 컴포지션을 통해 객체 인스턴스화의 책임을 다른 객체에 위임하는 반면 Factory Method 패턴은 상속을 사용하고 원하는 객체 인스턴스화를 처리하기 위해 서브 클래스에 의존한다는 것입니다.
실제로, 위임 된 객체는 종종 팩토리 메소드를 사용하여 인스턴스화를 수행합니다!
공장 패턴
팩토리 패턴은 생성 패턴의 예입니다
창작 패턴은 객체 인스턴스화 프로세스를 추상화합니다. 객체 생성 방식을 숨기고 객체 생성 및 구성 방식과 무관하게 전체 시스템을 구성하는 데 도움이됩니다.
클래스 생성 패턴은 상속을 사용하여 인스턴스화 할 객체를 결정하는 데 중점을 둡니다.
객체 생성 패턴은 다른 객체로의 인스턴스화 위임에 초점을 둡니다.
참조 : 팩토리 vs 추상 팩토리
팩토리 메소드 : 특정 기본 클래스에서 파생 된 오브젝트를 작성하는 팩토리가 있습니다.
추상 팩토리 : 다른 팩토리를 작성하는 팩토리가 있으며이 팩토리 는 기본 클래스에서 파생 된 오브젝트를 작성합니다. 팩토리 메소드와 같이 단일 객체를 만들지 않고 관련 객체 컬렉션을 만들려는 경우가 종종 있습니다.
추상 팩토리는 관련 객체를 만들기위한 인터페이스이지만 팩토리 방법은 방법입니다. 추상 팩토리는 팩토리 메소드로 구현됩니다.
기본 차이 :
팩토리 : 인스턴스화 로직을 클라이언트에 노출시키지 않고 객체를 만듭니다.
팩토리 메소드 : 객체를 생성하기위한 인터페이스를 정의하지만 서브 클래스가 인스턴스화 할 클래스를 결정하도록합니다. Factory 메소드는 클래스가 서브 클래스에 대한 인스턴스화를 연기하게합니다
Abstract Factory : 구체적인 클래스를 지정하지 않고 관련 또는 종속 객체의 패밀리를 작성하기위한 인터페이스를 제공합니다.
AbstractFactory 패턴은 컴포지션을 사용하여 객체 생성 책임을 다른 클래스에 위임하는 반면 Factory 메소드 패턴은 상속을 사용하고 파생 클래스 또는 서브 클래스를 사용하여 객체 생성
에서 oodesign 기사 :
팩토리 클래스 다이어그램 :
예 : StaticFactory
public class ShapeFactory {
//use getShape method to get object of type shape
public static Shape getShape(String shapeType){
if(shapeType == null){
return null;
}
if(shapeType.equalsIgnoreCase("CIRCLE")){
return new Circle();
} else if(shapeType.equalsIgnoreCase("RECTANGLE")){
return new Rectangle();
} else if(shapeType.equalsIgnoreCase("SQUARE")){
return new Square();
}
return null;
}
}
FactoryMethod 예제를 구현하는 비 정적 팩토리는이 게시물에서 사용할 수 있습니다.
디자인 패턴 : 팩토리 vs 팩토리 메소드 vs 추상 팩토리
사용시기 : 클라이언트는 클래스 만 필요하며 어떤 구체적인 구현을하고 있는지 상관하지 않습니다.
팩토리 메소드 클래스 디 가람 :
사용시기 : 클라이언트는 런타임에 어떤 구체적인 클래스를 작성해야하는지 알지 못하지만 작업을 수행 할 클래스를 얻으려고합니다.
사용시기 : 시스템이 여러 제품군을 작성해야하거나 구현 세부 사항을 노출하지 않고 제품 라이브러리를 제공하려는 경우.
위 기사의 소스 코드 예제는 개념을 명확하게 이해하는 데 매우 좋습니다.
코드 예제와 관련된 SE 질문 :
차이점 :
- 추상 팩토리 클래스는 종종 팩토리 메소드로 구현되지만 프로토 타입을 사용하여 구현할 수도 있습니다.
- 디자인은 Factory Method (더 복잡하지 않고 사용자 정의가 가능하며 서브 클래스가 확산 됨)를 사용하여 시작하여 더 많은 유연성이 필요한 다른 생성 패턴 (보다 유연하고 더 복잡한)으로 발전합니다.
- 팩토리 메소드는 일반적으로 템플리트 메소드 내에서 호출됩니다.
다른 유용한 기사 :
sourcemaking의 factory_method
abstract_factory sourcemaking에서
journaldev의 추상 공장 디자인 패턴
추상 팩토리의 예 / 시나리오
나는 장마에는 비가 내리고 겨울에는 눈이 내리고 여름에는 덥고 햇볕이 잘 드는 곳에 살고 있습니다. 나는 요소로부터 자신을 보호하기 위해 다른 종류의 옷이 필요합니다. 그렇게하기 위해 나는 집 근처의 가게에 가서 자신을 보호하기 위해 의복 / 아이템을 요청합니다. 상점 주인은 주머니의 환경과 깊이에 따라 적절한 품목을 제공합니다. 그가 나에게 준 아이템은 같은 수준의 품질과 가격대입니다. 그는 내 표준을 알고 있기 때문에 쉽게 할 수 있습니다. 그러나 길 건너에서 부자가 똑같은 요구 사항을 제시하면 비싸고 브랜드 인 아이템을 얻습니다. 눈에 띄는 것은 품질, 표준 및 비용이라는 용어로 그가 나에게 보완하는 모든 항목입니다. 그들은 서로 간다고 말할 수 있습니다. 이 부자가 얻는 아이템도 마찬가지입니다.
위의 시나리오를 살펴보면 이제 상점 주인의 효율성에 감사합니다. 이 가게 주인을 초록 가게로 바꿀 수 있습니다. 우리는 추상적 인 아이템과 함께 얻을 수있는 아이템과 투시 클라이언트로 풍부합니다. 우리가 필요한 것은 우리의 요구에 맞는 제품 / 항목입니다.
이제 수많은 고객에게 일련의 서비스를 제공하는 온라인 상점을 고려하고있는 것을 쉽게 알 수 있습니다. 각 클라이언트는 세 그룹 중 하나에 속합니다. 프리미엄 그룹 사용자가 사이트를 열면 훌륭한 UI, 고도로 맞춤 설정된 광고 창, 메뉴의 더 많은 옵션 등이 제공됩니다. 이러한 동일한 기능 세트는 골드 사용자에게 제공되지만 메뉴의 기능은 적고 광고는 대부분 관련이 있습니다. 그리고 약간 덜 경제적 인 UI. 마지막으로 '무료 그룹'사용자 인 제 종류의 사용자입니다. 나는 기분이 상하지 않도록 충분히 봉사를 받았다. UI는 최소한으로, 광고는 너무 많이 나가서 무엇이 들어 있는지 알지 못합니다. 마지막으로 메뉴는 로그 아웃했습니다.
이 웹 사이트와 같은 것을 만들 기회가 있다면 추상 팩토리 패턴을 확실히 고려할 것입니다.
추상 제품 : 광고 창, 메뉴, UI 페인터.
Abstract Factory : 웹 스토어 사용자 경험
공장 구성 : 프리미엄 사용자 경험, 골드 사용자 경험, 일반 사용자 경험.
많은 사람들이 놀랄 것 같지만이 질문은 잘못되었습니다 . 면접 중에이 질문을 듣는 경우 면접관이 혼란이있는 부분을 이해하도록 도와야합니다.
"공장"이라고하는 구체적인 패턴이 없다는 사실부터 시작하겠습니다. "Abstract Factory"라는 패턴이 있고 "Factory Method"라는 패턴이 있습니다.
그렇다면 "공장"은 무엇을 의미합니까? 다음 중 하나입니다 (참조의 범위에 따라 모두 올바른 것으로 간주 될 수 있음).
- 어떤 사람들은 이것을 " Abstract Factory " 의 별칭 (바로 가기)으로 사용합니다 .
- 어떤 사람들은 이것을 " Factory Method " 의 별칭 (바로 가기)으로 사용합니다 .
- 어떤 사람들은 그것을 모든 공장 / 창조 패턴의보다 일반적인 이름으로 사용합니다. 예를 들어 "Abstract Factory"와 "Factory Method"는 모두 팩토리입니다.
그리고, 불행하게도 , 많은 사람들이 공장 또는 공장 (또는 인터페이스)를 생성 공장의 다른 종류를 표시하기 위해 "공장"을 사용합니다. 그들의 이론을 바탕으로 :
Product는 Factory에서 생성 한 IProduct를 구현하고, IFactory는 AbstractFactory에서 생성합니다.
이것이 얼마나 어리석은지를 이해하려면 방정식을 계속합시다.
AbstractFactory는 다음에 의해 생성 된 IAbstractFactory를 구현합니다. AbstractAbstractFactory ???
나는 당신이 요점을 볼 수 있기를 바랍니다. 혼동하지 말고, 존재하지 않는 것을 발명하지 마십시오.
-
추신 : Factory for Products는 AbstractFactory이며, Factory for Abstract Factories는 AbstractFactory의 또 다른 예일뿐입니다.
//Abstract factory - Provides interface to create factory of related products
interface PizzaIngredientsFactory{
public Dough createDough(); //Will return you family of Dough
public Clam createClam(); //Will return you family of Clam
public Sauce createSauce(); //Will return you family of Sauce
}
class NYPizzaIngredientsFactory implements PizzaIngredientsFactory{
@Override
public Dough createDough(){
//create the concrete dough instance that NY uses
return doughInstance;
}
//override other methods
}
교과서 정의는 이미 다른 답변에서 제공됩니다. 나는 그것의 예를 제공 할 것이라고 생각했다.
여기 관련된 제품군을 만드는 방법을 제공 PizzaIngredientsFactory하는 추상 팩토리 가 있습니다.
추상 팩토리의 각 메소드 는 그 자체 가 팩토리 메소드 입니다. Like createDough()는 그 자체로 구체적인 구현이 같은 서브 클래스에 의해 제공 될 팩토리 메소드입니다 NYPizzaIngredientsFactory. 따라서이 각각의 다른 위치를 사용하면 해당 위치에 속하는 구체적인 재료의 인스턴스를 만들 수 있습니다.
공장 방법
구체적인 구현 사례 제공
예에서 :
- createDough()- 반죽을위한 구체적인 구현을 제공합니다. 이것은 공장 방법입니다
추상 공장
관련 객체 군을 생성하기위한 인터페이스 제공
예를 들면 다음과 같습니다
.- PizzaIngredientsFactory는 Dough,, Clams등 의 관련 개체 집합을 만들 수있는 추상 팩토리 Sauce입니다. 각 객체 패밀리를 생성하기 위해 팩토리 메소드를 제공합니다.
다음과 같이 John의 답변에 기여할 몇 가지 요점이 있습니다.
초록 공장은 공장의 공장입니다!
(그냥 "공장"모호하기 때문에) "공장 방법"으로, 당신은 구현 (생산 Lemon, Orange말하자면 - 특정 인터페이스의 등) IFruit. 이 팩토리를 호출 할 수 있습니다 CitricFruitFactory.
그러나 이제 CitricFruitFactory가 만들 수없는 다른 종류의 과일을 만들고 싶습니다. CitricFruitFactory당신 Strawberry이 그것을 만들면 코드가 이해 가되지 않을 것입니다 (딸기 과일은 구연산 과일이 아닙니다!).
당신이라는 새로운 공장 만들 수 있도록 RedFruitFactory생산 Strawberry, Raspberry등
존 페미 넬라 (John Feminella)가 말했듯이 : "Abstract Factory 패턴을 사용하면 특정 Factory 인터페이스를 구현할 수 있습니다 IFruitFactory. 예를 들어, 각각은 다른 종류의 과일을 만드는 방법을 알고 있습니다."
의 implementatios은 IFruitFactory이다 CitricFruitFactory와 RedFruitFactory!
: 내 소스는 StackOverflow, tutorialspoint.com, programmers.stackexchange.com와 CodeProject.com.
Factory Method(라고도 함 Factory)는 Interface구현의 클라이언트 분리를위한 것입니다. 샘플을 위해 우리는이 Shape두 가지와 인터페이스 Circle및 Square구현. 인터페이스의 Type새로운 관련 구현과 같은 결정자 매개 변수를 사용하여 팩토리 메소드를 사용하여 팩토리 클래스를 정의했습니다 Shape.
Abstract Factory여러 팩토리 구현에 의한 여러 팩토리 메소드 또는 팩토리 인터페이스를 포함합니다. 다음 위의 예제를 들어 우리는이 Color두 가지와 인터페이스 Red및 Yellow구현. 우리는 정의가 ShapeColorFactory두 사람과 함께 인터페이스를 RedCircleFactory하고 YellowSquareFactory. 이 개념을 설명하기위한 다음 코드 :
interface ShapeColorFactory
{
public Shape getShape();
public Color getColor();
}
class RedCircleFactory implements ShapeColorFactory
{
@Override
public Shape getShape() {
return new Circle();
}
@Override
public Color getColor() {
return new Red();
}
}
class YellowSquareFactory implements ShapeColorFactory
{
@Override
public Shape getShape() {
return new Square();
}
@Override
public Color getColor() {
return new Yellow();
}
}
차이 여기 FactoryMethod와 AbstractFactory. Factory Method단순히 인터페이스의 구체적인 클래스를 Abstract Factory반환 하지만 return factory of factory. 즉 Abstract Factory, 일련의 인터페이스의 다른 조합을 반환합니다.
내 설명이 도움이 되길 바랍니다.
그 공장들에서 가장 큰 차이점은 당신이 공장으로하고 싶은 일과 그것을 사용하고 싶을 때입니다.
때로는 IOC (제어의 반전, 예를 들어 생성자 주입)를 수행 할 때 솔리드 객체를 만들 수 있다는 것을 알고 있습니다. 과일의 위 예에서 언급했듯이 과일 개체를 만들 준비가되면 간단한 팩토리 패턴을 사용할 수 있습니다 .
그러나 많은 경우 솔리드 객체를 생성하지 않으려는 경우 나중에 프로그램 흐름에서 나옵니다. 그러나 구성은 객체를 생성하는 대신 시작시 사용할 팩토리 종류를 알려줍니다. 공통 팩토리 클래스에서 파생 된 팩토리를 IOC의 생성자로 전달할 수 있습니다.
개체 수명과 생성에 대해서도 생각합니다.
모두 Factory Method와 Abstract Factory구체적인 유형에서 분리 클라이언트를 유지한다. 둘 다 객체를 생성하지만 Factory메소드는 상속을 Abstract Factory사용하고 컴포지션을 사용합니다.
는 Factory Method반면 콘크리트 객체 (제품)을 만들 서브 클래스에 상속 Abstract Factory관련 제품과 이러한 인터페이스의 서브 클래스의 가족을 만들기위한 인터페이스를 제공하는 관련 제품을 만드는 방법을 정의합니다.
그런 다음 인스턴스화 될 때 이러한 서브 클래스는 추상 유형으로 사용되는 제품 클래스로 전달됩니다. 의 관련 제품 Abstract Factory은 종종를 사용하여 구현됩니다 Factory Method.
존 페미 넬라 (John Feminella) 답변 확장 :
Apple, Banana, Cherry구현 FruitFactory하고 호출하는 방법이 Create사과 또는 바나나 또는 체리를 만드는 전적으로 책임이있다. Factory방법 이 끝났습니다 .
이제 Create과일에서 특별한 샐러드 를 만들고 싶고 Abstract Factory가 있습니다. Abstract Factory는 Apple, Banana 및 Cherry에서 특별한 샐러드를 만드는 방법을 알고 있습니다.
public class Apple implements Fruit, FruitFactory {
public Fruit Create() {
// Apple creation logic goes here
}
}
public class Banana implements Fruit, FruitFactory {
public Fruit Create() {
// Banana creation logic goes here
}
}
public class Cherry implements Fruit, FruitFactory {
public Fruit Create() {
// Cherry creation logic goes here
}
}
public class SpecialSalad implements Salad, SaladFactory {
public static Salad Create(FruitFactory[] fruits) {
// loop through the factory and create the fruits.
// then you're ready to cut and slice your fruits
// to create your special salad.
}
}
정의에 따라 두 가지 차이점을 끌어낼 수 있습니다.
팩토리 : 객체를 만드는 데 인터페이스가 사용되지만 서브 클래스는 인스턴스화 할 클래스를 결정합니다. 필요한 경우 객체 생성이 완료됩니다.
추상 팩토리 : 추상 팩토리 패턴은 다른 팩토리를 생성하는 수퍼 팩토리 역할을합니다. Abstract Factory 패턴에서 인터페이스는 구체적인 클래스를 지정하지 않고 관련 객체 또는 종속 객체 세트를 작성합니다.
따라서 위의 정의에서 특정 차이점을 강조 할 수 있습니다. 즉, 팩토리 패턴은 오브젝트 작성을 담당하고 Abstract Factory는 관련 오브젝트 세트 작성을 담당합니다. 분명히 인터페이스를 통해.
공장 패턴 :
public interface IFactory{
void VehicleType(string n);
}
public class Scooter : IFactory{
public void VehicleType(string n){
Console.WriteLine("Vehicle type: " + n);
}
}
public class Bike : IFactory{
public void VehicleType(string n) {
Console.WriteLine("Vehicle type: " + n);
}
}
public interface IVehicleFactory{
IFactory GetVehicleType(string Vehicle);
}
public class ConcreteVehicleFactory : IVehicleFactory{
public IFactory GetVehicleType(string Vehicle){
switch (Vehicle){
case "Scooter":
return new Scooter();
case "Bike":
return new Bike();
default:
return new Scooter();
}
}
class Program{
static void Main(string[] args){
IVehicleFactory factory = new ConcreteVehicleFactory();
IFactory scooter = factory.GetVehicleType("Scooter");
scooter.VehicleType("Scooter");
IFactory bike = factory.GetVehicleType("Bike");
bike.VehicleType("Bike");
Console.ReadKey();
}
}
추상 공장 패턴 :
interface IVehicleFactory{
IBike GetBike();
IScooter GetScooter();
}
class HondaFactory : IVehicleFactory{
public IBike GetBike(){
return new FZS();
}
public IScooter GetScooter(){
return new FZscooter();
}
}
class HeroFactory: IVehicleFactory{
public IBike GetBike(){
return new Pulsur();
}
public IScooter GetScooter(){
return new PulsurScooter();
}
}
interface IBike
{
string Name();
}
interface IScooter
{
string Name();
}
class FZS:IBike{
public string Name(){
return "FZS";
}
}
class Pulsur:IBike{
public string Name(){
return "Pulsur";
}
}
class FZscooter:IScooter {
public string Name(){
return "FZscooter";
}
}
class PulsurScooter:IScooter{
public string Name(){
return "PulsurScooter";
}
}
enum MANUFACTURERS
{
HONDA,
HERO
}
class VehicleTypeCheck{
IBike bike;
IScooter scooter;
IVehicleFactory factory;
MANUFACTURERS manu;
public VehicleTypeCheck(MANUFACTURERS m){
manu = m;
}
public void CheckProducts()
{
switch (manu){
case MANUFACTURERS.HONDA:
factory = new HondaFactory();
break;
case MANUFACTURERS.HERO:
factory = new HeroFactory();
break;
}
Console.WriteLine("Bike: " + factory.GetBike().Name() + "\nScooter: " + factory.GetScooter().Name());
}
}
class Program
{
static void Main(string[] args)
{
VehicleTypeCheck chk = new VehicleTypeCheck(MANUFACTURERS.HONDA);
chk.CheckProducts();
chk= new VehicleTypeCheck(MANUFACTURERS.HERO);
chk.CheckProducts();
Console.Read();
}
}
여기를 확인하십시오 : http://www.allapplabs.com/java_design_patterns/abstract_factory_pattern.htm Factory 메소드는 추상 클래스가 아닌 추상 클래스를 기본 클래스로 사용하는 것 같습니다. 또한 추상 클래스 대신 인터페이스를 사용하면 결과적으로 추상 팩토리 패턴의 구현이 달라집니다.
:디
Abstract Factory는 다른 유형의 인터페이스를 만들기위한 템플릿입니다. 수량, 가격 및 품목별 정보를 포함하는 다양한 유형의 csv 파일을 초콜릿과 관련된 과일에 대한 데이터가 포함 된 것과 같이 분석 한 다음 구문 분석 한 후 해당 데이터베이스에서이 정보를 업데이트해야하는 프로젝트가 있다고 가정합니다. 파서 및 수정 자 공장을 반환하는 하나의 추상 공장이 파서 팩토리는 초콜릿 파서 객체, 과일 파서 객체 등을 반환 할 수 있으며 마찬가지로 Modifier Factory는 초콜릿 한정자 객체, 과일 수정 자 객체 등을 반환 할 수 있습니다.
Java8 예제 코드를 보면이 두 가지의 차이점을 이해할 수 있다고 생각합니다.
interface Something{}
interface OneWhoCanProvideSomething {
Something getSomething();
}
interface OneWhoCanProvideCreatorsOfSomething{
OneWhoCanProvideSomething getCreator();
}
public class AbstractFactoryExample {
public static void main(String[] args) {
//I need something
//Let's create one
Something something = new Something() {};
//Or ask someone (FACTORY pattern)
OneWhoCanProvideSomething oneWhoCanProvideSomethingOfTypeA = () -> null;
OneWhoCanProvideSomething oneWhoCanProvideSomethingOfTypeB = () -> null;
//Or ask someone who knows soemone who can create something (ABSTRACT FACTORY pattern)
OneWhoCanProvideCreatorsOfSomething oneWhoCanProvideCreatorsOfSomething = () -> null;
//Same thing, but you don't need to write you own interfaces
Supplier<Something> supplierOfSomething = () -> null;
Supplier<Supplier<Something>> supplierOfSupplier = () -> null;
}
}
Now the question is which way of creation should you use and why: The first way (no pattern, just plain constructor): creating by yourself is not a good idea, you have to do all the work, and your client code is tied to the particular implementation.
The second way (using Factory pattern): provides you the benefit that you can pass any type of implementation, which can provide different type of something based on some condition (maybe a parameter passed to creational method).
The third way (using Abstract Factory pattern): This gives you more flexibility. You can find different types of creators of something based on some condition (maybe a parameter passed).
두 가지 조건을 결합하여 (코드 복잡성을 약간 증가시키고, 커플 링함으로써) 항상 Factory 패턴을 사용할 수 있다는 점에 유의하십시오. 따라서 Abstract Factory 패턴의 실제 사용 사례는 거의 보이지 않습니다.
'development' 카테고리의 다른 글
| JavaScript 함수에서 전역 변수 정의 (0) | 2020.02.14 |
|---|---|
| TypeError : 'module'개체를 호출 할 수 없습니다 (0) | 2020.02.14 |
| Node.js에서 스택 추적을 인쇄하는 방법은 무엇입니까? (0) | 2020.02.14 |
| Visual Studio“Any CPU”대상은 무엇을 의미합니까? (0) | 2020.02.14 |
| "[False, True]의 not (True)"이 False를 반환하는 이유는 무엇입니까? (0) | 2020.02.14 |