Оба абстрактных шаблона метода Factory и Factory представляют собой шаблоны создания, которые решают проблемы создания объектов в разных сценариях.
В соответствии с шаблоном GOF Factory
Определите интерфейс для создания объекта, но пусть подклассы решают, какой класс необходимо создать. Метод Factory позволяет классу отложить создание экземпляра подкласса.
Мое понимание: Мотивация Клиент заключается в том, чтобы получить метод, присутствующий в базовом классе Factory, который будет выполняться, который зависит от объекта, чей конкретный класс сейчас неизвестен (в этом случае либо при предоставлении программного обеспечения для клиента он будет определен, или сам клиент будет писать конкретную реализацию, скорее всего, в случае Framework). Неизвестный (или может измениться) Продукт предоставляется абстрактный тип: IProduct и установка контракта, который в будущем любая реализация для продукта должна реализовать этот интерфейс.
Интерфейс IProduct
package com.companyx;
public interface IProduct {
public void serve();
}
Factory класс с "методом", который необходимо выполнить
package com.companyx;
public abstract class Factory {
public abstract IProduct createProduct();
private void performCriticalJob(){
IProduct product = createProduct();
product.serve();
}
public void executeJob(){
//some code
performCriticalJob();
//some more code
}
}
Некоторое конкретное изделие
package com.companyx;
class AppAProductFeatureX implements IProduct{
@Override
public void serve() {
//some code
}
}
Factory конкретного продукта
package com.companyx;
public class AppAFeatureXProductFactory extends Factory{
@Override
public IProduct createProduct() {
return new AppAProductFeatureX();
}
}
Клиентский код
package com.clientcompany;
import com.companyx.AppAFeatureXProductFactory;
import com.companyx.Factory;
public class Client {
public static void main(String[] args) {
Factory fact = new AppAFeatureXProductFactory();
fact.executeJob();
}
}
В соответствии с GOF Абстрактный Factory шаблон
Предоставить интерфейс для создания семейств связанных или зависимых объектов без указания их конкретных классов.
Мое понимание Клиент заинтересован в продуктах, здесь этот шаблон помогает в обеспечении продукта, скрывая конкретные классы продуктов по классам Factory.
Тип продукта, запрашиваемый клиентом
package com.companyb;
public interface IProductA {
public void performAJob();
}
Реализация продукта
package com.companyb;
//can be named better, but lets go with this name for this time
public class ProductAVersion1 implements IProductA{
@Override
public void performAJob() {
// some code
}
}
Factory интерфейс, (он может быть также абстрактным классом)
package com.companyb;
public interface IFactory {
public IProductA createProduct();
}
Конкретная реализация Factory o создать ProductA
пакет com.companyb;
public class FactoryA implements IFactory{
@Override
public IProductA createProduct() {
return new ProductAVersion1(); // concrete class of product is hidden
}
}
Код клиента
package com.clientcompany.productprovider;
import com.companyb.IFactory;
import com.companyb.IProductA;
public class SomeClientClass {
private IFactory factory;
private IProductA product;
public void doSomeJobWithProductA() {
// some code
product.performAJob();
//someCode();
}
public void setFactory(IFactory factory) {
this.factory = factory;
this.product = factory.createProduct();
}
}
package com.clientcompany.productprovider;
import com.companyb.FactoryA;
public class SomeOtherClientCode {
public static void main(String[] args) {
SomeClientClass someClientClass = new SomeClientClass();
someClientClass.setFactory(new FactoryA());
someClientClass.doSomeJobWithProductA();
}
}
Q1. Является ли семейство связанного продукта необходимым в абстрактном Factory patter, не будет ли этот шаблон актуальным, если существует только один вид продукта (например, выше) с различными подтипами но не различные родственные типы?
Q2 Является ли мое понимание выше правильного?
Q3 Вышеприведено еще одно сомнение: более подходит ли метод Factory для фреймворков (где клиент может предоставить реализацию продуктов) и точно так же, как шаблон метода шаблона, Factory вызывает createProduct() конкретная реализация формы, предоставляемой пользователем. Бетонная реализация Factory?
Также аналогично Abstract Factory больше подходит для развития библиотеки, где конкретные классы продуктов (вероятно, будут меняться) скрыты за более стабильными классами Factory?