Design Patterns: Factory Method.
Uma
Caracterização Bibliográfica
João Paulo Costa Rua
Escola de Ciências e Tecnologia
Universidade de Trás-os-Montes e Alto Douro
Vila Real, Portugal
al70407@alunos.utad.pt
Abstract—This essay presents an introduction,
differentiation, study and contextualization of the applicability
of the object-oriented Design Pattern, Factory Method. The
strategy to arrive at the analysis and framing of the use cases
where it can be used is based on the perception of the problems
it solves, using theoretical and practical scenarios as support.
The analysis with other Design Patterns is done in order to
demonstrate the Factory Method's differentiation from other
alternatives. The research carried out also compares different
implementations and structuring in terms of code and
application design. The results demonstrate the applicability
and flexibility of this Pattern in different projects, allowing to
observe the possibility of reusing its structure in different
solutions or other Patterns.
Keywords—Factory Method, Design Patterns, Object-
Oriented Techniques, Java, Abstract Factory, Prototype
Resumo—Este ensaio apresenta uma introdução,
diferenciação, estudo e contextualização da aplicabilidade do
Design Pattern, orientado a objetos, Factory Method. A
estratégia para chegar à análise e enquadramento dos casos de
uso onde pode ser usado é baseada através da perceção dos
problemas que resolve, utilizando para tal cenários teóricos e
práticos como suporte. A análise com outros Design Patterns é
feita com o intuito de demonstrar a diferenciação do Factory
Method perante outras alternativas. A pesquisa realizada
compara, também, diferentes implementações e estruturações
ao nível de código e desenho da aplicação. Os resultados
demonstram a aplicabilidade e flexibilidade deste Pattern em
diferentes projetos, permitindo observar a possibilidade de
reutilizar sua estrutura em diferentes soluções ou outros
Patterns.
I. INTRODUÇÃO
Ao longo da história do desenvolvimento de software,
várias abordagens sobre como estruturar o Código para
resolução de problemas foram e continuam sendo
concebidas. No entanto, em outubro de 1994, um grupo
composto por 4 pesquisadores da área da computação, cujo
grupo ficou popularmente conhecido como GoF – Gang of
Four, elaborou o livro intitulado “Design Patterns: Elements
of Reusable Object-Oriented Software”. É possível
compreender, nesta literatura, o termo Design Pattern como
“[…] descrição de comunicação de classes e objetos que são
customizados para resolver um problema geral de design em
um contexto particular” [1].
Neste, enumeraram originalmente um total de vinte e três
padrões de design orientado a objetos, cada um com o intuito
de ser uma solução genérica e reutilizável para um
determinado problema no contexto de design de software. As
2022 IEEE
Hugo Andrade
Escola de Ciências e Tecnologia
Universidade de Trás-os-Montes e Alto Douro
Vila Real, Portugal
al70833@alunos.utad.pt
soluções foram dividas em 3 grupos: criacional, estrutural e
comportamental.
Dentre os padrões criacionais, um de extrema
importância foi destilado: o Factory Method, também
conhecido como Construtor Virtual. Trata-se de um Design
Pattern onde o escopo é feito nas classes e não nos objetos.
Assim sendo, define uma interface para criar um objeto,
deixando as subclasses decidirem qual classe instanciar.
O Factory Method permite que uma classe adie a
instanciação para subclasses. É, portanto, uma “Fábrica de
Métodos”, onde uma superclasse agrega funcionalidades
gerais e as subclasses encapsulam procedimentos
específicos.
Ao longo deste ensaio, serão trabalhadas implicações,
abordagens e possíveis utilizações deste design num estudo
de carácter teórico e prático, com o objetivo de alcançar uma
compreensão sobre o Design Pattern.
II. ESTRUTURAÇÃO
Para o sucesso do Factory Method é necessário declarar
uma interface A, comum para todos os objetos que podem
ser produzidos pela hierarquia de uma superclasse B. Os
herdeiros desta superclasse B podem implementar diferentes
implementações da interface A.
A superclasse B declara um método abstrato, Factory
Method, que irá retornar um novo objeto que implementa a
interface A. No final, obtêm-se várias classes finais
reescrevendo a base do método para que retorne diferentes
tipos de produtos.
A. Aplicabilidade
O Factory Method pode ser usado em situações onde uma
classe não consegue antecipar a classe do objeto que deve
criar, ou pretende que a sua subclasse especifique o objeto
que cria. Deve, também, ser usado para quando se pretende
saber qual subclasse helper está delegado.
Como este é um método que se baseia em hierarquias,
torna a implementação de novos componentes que estendem
e/ou complementam componentes já presentes num processo
mais facilitado, o que leva a uma maior compreensão e
redução de tempo de correção de erros.
Por este se basear fortemente em hierarquias, torna o
reuso de objetos já existentes mais fácil, o que faz com que
se poupe em recursos de sistema, uma vez que não é preciso
estra a reconstruir estes.
B. Participantes
Existem 4 principais participantes, sendo o primeiro o
produto, que define a interface de objetos que o Factory
Method cria. O segundo, ConcreteProduct, fica responsável
por implementar a interface do produto. O Creator fica
responsável por declarar o Factory Method, que retorna um
objeto do tipo Product. Este pode, também, chamar o Factory
Method para criar um objeto do tipo Product. Por fim, o
ConcreteCreator faz override do Factory Method para
retomar uma instância de um ConcreteProduct.
C. Panorama
Considerando os participantes citados, monta-se um
modelo de estruturação a ser seguido, de forma a garantir a
colaboração entre os diferentes participantes. Esta
colaboração dá-se pelo criador depender de suas subclasses
para definir o Factory Method, para que assim ele possa
retornar uma instância de um produto concreto apropriado.
Fig. 1: Estrutura Proposta Para o Design Pattern Factory Method [1]
A classe Product não permite instanciação, por ser
abstrata. Por isto, é necessário criar classes concretas que a
herdem. O mesmo pode ser dito da classe Creator, e
consequentemente, do método FactoryMethod. Assim, a
implementação do método é dada nas classes concretas, que
selecionam via escopo de classe qual classe do tipo Product
deve ser instanciada.
É possível notar, também, que chamadas do método
abstrato FactoryMethod podem ser realizadas em outros
lugares da classe abstrata Creator, sem prejuízo de
funcionalidades, garantindo assim maior abstração e
facilidade no momento de instanciar objetos.
Formula-se, deste modo, uma esquematização estrutural
tanto do modelo conceitual quanto do prático. No modelo da
Fig.1, o desenho é baseado em classes, seus relacionamentos,
e.g, herança, e chamadas de métodos como conexão entre as
classes Creator e Product.
D. Consequências
O Factory Method elimina a necessidade de vincular
classes específicas da aplicação no código, conecta
hierarquias de casses paralelas e prevê hooks para as
subclasses. Uma possível desvantagem é que clientes podem
ter de instanciar subclasses da classe Creator apenas para
criar um objeto de um Concrete Product em particular.
Uma das grandes consequências de utilizar o Factory
Method, é a flexibilidade em criar objetos em classes, ao
invés de criar este objeto diretamente, uma vez que é
fornecido hooks para subclasses, para que possam estender
versões de objetos.
No momento que uma classe delega uma porção das suas
responsabilidades para uma separação de classes, é gerado
uma hierarquia de classes paralelas. Quando se pretende, por
exemplo, manipular interactivamente uma figura, será
necessário armazenar e atualizar diversas informações que
são armazenadas, que é apenas necessário durante este
processo de manipulação. Com este problema, seria
vantajoso usar uma classe própria para a manipulação, com
um objeto para começar o estado de manipulação, com
subclasses para diferentes manipulações.
III. USOS NA INDÚSTRIA
O Factory Method é preferível, em relação a outros
Design Patterns, uma vez que este define uma interface que
está encarregue de criar um objeto, que deixa subclasses
decidir qual classe instanciar.
Com a popularidade e eficiência deste Factory Method,
várias frameworks e modos padrões de executar uma
atividade foram surgindo. Muitos destes são padrões e
referência para a indústria de software e é possível notar,
desta forma, que há muitos anos o Factory Method tem usos
relevantes no mercado.
Estas frameworks são, por exemplo, a .NET, com classes
como System.Data.Common. Quanto ao Java, temos a classe
DocumentBuilderFactoryQuant. Nos sistemas Apple, temos
a implementação de uma aplicação que permite desenhar
uma interface gráfica que apresente documentos através do
MacApp. Já para a criação de GUIs multiplataforma, o Qt,
software bastante estabelecido no mercado, utiliza este
Design Pattern numa funcionalidade central – criação de
Popups personalizados.
A seguir, segue-se a aplicação do Factory Method em
cada uma das frameworks e soluções enumeradas.
A. ADO.NET 2.0
ADO.NET 2.0, foi introduzido como um namespace para
a classe System.Data.Common, para a framework .NET, da
Microsoft, com o objetivo de tratar informações, data,
incluindo classes abstratas básicas, como DbConnection,
DbCommand e DbDataAdapter. [16]
A classe DbProviderFactories oferece métodos estáticos
para que se possa criar a instância DbProviderFactory, que
vai ficar responsável por retornar objetos baseados nas
informações provindas e na string conectada.
B. DocumentBuilderFactory
A classe DocumentBuilderFactory, do Java, tem como
função definir a API fábrica, que permite aplicações a obter
parsers que produzem árvores dos objetos de DOM, a partir
de documentos XML. Esta classe é publica e abstrata, que
estende outra classe, Object, que é a raiz da hierarquia. [17]
[18]
C. Qt
O Qt é um software multiplataforma para a criação de
interfaces gráficas (GUI – Graphic User Interfaces) e
aplicações multiplataforma que correm em diversos sistemas,
tais como Windows, Linux, MacOS, Android e sistemas
embarcados (Embedded Systems) com pouca ou nenhuma
necessidade de mudança na base de código interna, enquanto
permite aceder a funcionalidades e velocidade nativas [19].
Numa de suas principais classes, QMainWindow,
responsável pela criação da janela principal, o método
createPopupMenu é um Factory Method declarado
internamente na framework, mas que pode ser sobrescrito no
código da própria aplicação. Este método é responsável por
criar um menu de popup padrão, mas pode ser personalizado
através do overriding.
D. Sistemas Apple
No contexto de uma aplicação para desenhar uma
interface gráfica, onde precisa desenhar um determinado
documento, uma futura subclasse Documento a instanciar
depende do tipo da aplicação.
Assim, a classe Aplicação não consegue definir qual
subclasse de Documento instanciar. Isto cria um dilema, uma
vez que o projeto deve permitir instanciar classes, mas este
apenas conhece as classes abstratas [1].
Para resolver este dilema, o Factory Method encapsula o
conhecimento de qual subclasse Documento criar e move o
conhecimento para fora da Framework, abstraindo a solução.
O Factory Method é encontrado em diversas frameworks
deste tipo, em especial no MacApp, que permite, dentre
outras funcionalidades, desenhar interfaces gráficas em
diversos ambientes da Apple, especificamente nos MacOS
clássicos. Apesar de antigo, é um bom exemplo de caso de
uso deste Design Pattern.
IV. DIFERENCIAÇÃO
Alguns Design Patterns guardam semelhanças com o
Factory Method, mas são utilizados em contextos e com
finalidades diferentes. A seguir seguem diferenciações com
alguns destes Patterns.
A. Diferenciação com o Abstract Factory
Apesar destes design patterns terem Factory no nome,
existem três grandes diferenças entre eles. Enquanto o
Factory Method é um método e pode ser overrided por uma
subclasse, o Abstract Factory é um objeto em si.
O Factory Method difere, também, nos componentes que
expõem, sendo que este expõe um método ao cliente para
que possa criar o objeto, e o Abstract Factory expõe uma
família de objetos relacionados que podem consistir desses
Factory Methods.
A última grande diferença entre estes dois, é que o
Factory Method consiste numa classe de Fábrica com um
método de Criação que pode produzir apenas um tipo de
objeto. Por outro lado, o Abstract Factory cria abstração da
classe Factory usando interface, que pode produzir diferentes
tipos de objetos.
B. Diferenciação com o Prototype
Para uma boa implementação do Factory Method, será
necessário criar um número considerável - minimamente
quatro, de classes e subclasses, com um esquema de
hierarquia, no qual consiste precisamente a diferença com o
Prototype.
O Prototype, por definição, gera cópias da própria classe,
clonando seus valores - não sua referência em memória, o
que requer uma inicialização, por vezes complexa, do objeto
clonado. Assim, este Design Pattern não se utiliza através de
distintas hierarquias, algo característico no Factory
Method.[15]
V. IMPLEMENTAÇÃO
De forma a propor uma implementação prática do
Factory Method para exemplificar a utilização e,
consequentemente, facilitar o entendimento, é feita a
elaboração de um cenário com determinado problema. Será
seguido de uma análise, identificação dos participantes,
estrutura e código necessário para devido funcionamento da
amostragem. A plataforma de desenvolvimento foi a IDE
NetBeans, da Oracle. A linguagem de programação utilizada
foi Java versão 19.
Design Patterns do catálogo GoF costumam independer
da linguagem de programação, desde que esta seja orientada
a objetos. Existem algumas exceções, por exemplo a
linguagem Go, que não possui classes e objetos. Ao invés
disso, as estruturas (Structs) de dados podem ter métodos
declarados associados, permitindo assim a implementação
dos diversos padrões, com adaptação às suas limitações [9].
A. Contexto
Pretende-se implementar uma aplicação multiplataforma,
ou seja, deve rodar em várias plataformas, nomeadamente
Windows ou Android. A aplicação, deve, primariamente,
permitir criar e enviar notificações independentemente da
plataforma.
Cada notificação deve ser composta, minimamente, de
um método para suportar o evento de clique do botão e,
principalmente, um método que permita enviar a notificação,
sendo o conteúdo passado via parâmetro.
B. Análise do Contexto
Observando o contexto proposto, é notável a necessidade
de utilizar um Design Pattern do tipo criacional. Prototypes
são usualmente utilizados para fazer clonagem de objetos,
Builders são usados quando existem várias etapas para a
construção do objeto e Singletons tem o objetivo de manter
apenas uma instância da classe; portanto estas opções são
excluídas. Assim sendo, os dois únicos padrões criacionais
que restam no panorama são Abstract Factories e Factory
Methods.
É possível aplicar Abstract Factories neste cenário.
Entretanto aumentaria desnecessariamente a complexidade
de implementação, por ter de criar uma abstração da classe
factory e implementar a abstração para finalmente ter acesso
a uma factory concreta, onde pode construir os objetos da
família que deseja.
Portanto, a melhor opção, dado o contexto, é a utilização
de Factory Methods. Os Factory Methods permitem unir
duas hierarquias de classes e manufaturar os objetos através
de um método abstrato a ser implementado por subclasses.
Adequa-se, assim, aos requisitos solicitados, não adicionando
complexidade desnecessária ao software.
Num contexto de Factory Method, é necessário definir os
integrantes da estrutura do Pattern, de forma a assegurar o
entendimento dos papéis e respetivo funcionamento das
classes e objetos.
No que concerne às classes, é notável a necessidade de
implementar duas subclasses da classe da aplicação -
Application, referentes às respetivas plataformas, D. Código Desenvolvido
WindowsApplication e AndroidApplication. O mesmo é Utilizando as ferramentas e tecnologias citadas, procede-
aplicável às notificações, onde tanto WindowsNotification se a demonstração de um código capaz de resolver o
quanto AndroidNotification implementarão a interface problema citado de forma efetiva e expositiva do Factory
Notification. Method como resolução prática do problema.
Assim, são geradas diferentes hierarquias das classes
Notification e Application, as quais são relacionadas através
de um Factory Method, de forma que a aplicação consiga public abstract class Application {
gerar novas notificações independentemente da plataforma
selecionada.
Prosseguindo à identificação dos papéis dos integrantes, public void SendNotification(String
considerando o modelo de estruturação já apresentado no msg){
tópico II, pode-se interpretar da seguinte forma: A classe var notification =
Notification atua como Product, uma vez que define a CreateNotification();
interface de objetos que o Factory Method pretende
instanciar. notification.send(msg);
Os ConcreteProduct são as classes WindowsNotification }
e AndroidNotification, uma vez que implementam a classe
Notification.
public abstract Notification
A classe Application é identificada como o Creator, CreateNotification();
devido a ser a superclasse abstrata dos outros Creators, e,
portanto, definirá o Factory Method em si. Por consequência,
os ConcreteCreators serão WindowsApplication e }
AndroidApplication, que irão sobrescrever o Factory
Method, decidindo qual classe do tipo Notification deve ser
instanciada. public class AndroidApplication
extends Application{
C. Tecnologias Utilizadas
A linguagem Java foi concebida tendo em mente o
paradigma de orientação a objetos, facilitando definições de @Override
classes e seus relacionamentos, e abstraindo alguns aspetos
public Notification
presentes em outras linguagens. Somando-se a isto sua
CreateNotification() {
latente popularidade na indústria, robustez, qualidade e
consolidação, torna-se a candidata ideal para uma return new
implementação de Design Patterns do protocolo GoF e, não AndroidNotification();
excludente, do Factory Method, como demonstrado a seguir.
}
Umas das vantagens do Java referente ao funcionamento
é que o código implementado é compilado para Java
Bytecodes e interpretado ou executado em uma máquina }
virtual Java (JVM), de forma a isolar o ambiente a uma
máquina virtual dedicada apenas a sua execução. Deste
modelo de virtualização surgiu o conceito de “Write once, public class WindowsApplication
run anywhere”, cunhado pela Sun Microsystem justamente extends Application {
em referência ao Java.
Este processo utiliza tanto ferramentas de compilação
quanto de interpretação, unindo suas melhores @Override
características. Logo, o Java não pode ser classificado como public Notification
apenas compilado ou interpretado, sendo na realidade uma CreateNotification() {
mistura eficiente de ambos.
return new
Uma IDE é um ambiente de desenvolvimento integrado WindowsNotification();
que reúne características e ferramentas de apoio no
desenvolvimento do Software com a intenção de agilizar este }
processo.
A escolha da IDE NetBeans, Oracle, para }
desenvolvimento do código fundamenta-se no facto de
possuir suporte especializado para Java, além de ser a
ferramenta indicada pela equipa de manutenção do Java,
pertencente também a Oracle.
Lista 1. Código com a classe abstrata Application e suas subclasses para
Windows e Android implementadas
 public class
Proposta_implementacao_fabric_method {
public interface Notification {
public static void main(String[]
void send(String msg); args) {
void onClick(); var android = new
} AndroidApplication();

android.SendNotification("Mensagem
public class WindowsNotification de Teste 1");
implements Notification{

var windows = new

@Override WindowsApplication();
public void send(String msg) {
System.out.println("Sending windows.SendNotification("Mensagem
message on Windows: " + msg); de Teste 2");
} }
}
@Override Lista 3. Código com as chamadas de função para gerar notificações em
public void onClick() { diferentes plataformas

System.out.println("Windows
notification clicked"); E. Discussão sobre a implementação
Com a base de código definida, é possível notar algumas
} relações características do Factory Method, principalmente
referentes à conexão das duas hierarquias.
} O método responsável por manufaturar os objetos, ou
seja, o Factory Method em si, pode ser identificado
facilmente como o método CreateNotification. Este é
public class AndroidNotification abstrato na classe Application, que delega às suas subclasses
implements Notification{ decidirem qual tipo de Notificação instanciar. (Lista 1)
Isto possui algumas implicações convenientes a nível de
aplicação de conceito no código. Isto é, no caso de haver um
@Override método dentro da classe Application que crie e utilize uma
public void send(String msg) { notificação, este não consegue saber qual tipo de notificação
deve ser tratada – Windows ou Android. Assim, é possível
System.out.println("Sending notar uma das consequências deste Pattern: a providência de
message on Android: " + msg); hooks para subclasses, fazendo com que estas decidam qual
} tipo de notificação enviar.
No método SendNotification, da classe Application, é
instanciada uma nova aplicação, que será resultado da função
@Override abstrata CreateNotification. Como métodos abstratos não
public void onClick() { podem ser instanciados, a delegação de criação de
notificações para as subclasses torna-se evidente, pois são
System.out.println("Android elas que devem implementar a funcionalidade. Assim, o
notification clicked"); método SendNotification faz a chamada de envio da
} notificação mesmo sem conhecer a classe concreta com a
qual trabalha.
O desenho da implementação, Fig. 2, abaixo
} representado, tem fortes referências à estrutura padrão do
Design Pattern, descrito na secção II.

Lista 2. Código com a interface Notification e suas subclasses para

Windows e Android implementadas.
 Um agradecimento especial a Universidade de Trás-os-
Montes e Alto Douro, em especial a Escola de Ciências e
Tecnologia, ECT, por proporcionar esta oportunidade de
investigação aos estudantes.
[1]
Fig. 2: Diagrama de Classes da Implementação
[2]
Desta forma, ao rodar o programa da função main (Lista
3), a mensagem de teste 1 é enviada pelo sistema Android e a [3]
mensagem de teste 2 é enviada pelo sistema Windows,
provando o sucesso da implementação, apresentado na Fig. [4]
3.
[5]
[6]
Fig. 3: Valores de Saída ao Executar o Programa
[7]
VI. CONCLUSÃO
Ao fim deste ensaio, são explicitados resultados
conceptuais a nível de definição e localização do Factory [8]
Method como solução reutilizável de problemas.
A exposição da estrutura, diferença entre outros padrões
e usos na indústria permitem uma ampla e clara visão da
[9]
relevância e cenário em qual se enquadra e pode ser
utilizado, bem como definir conceitos teóricos referentes ao [10]
Factory Method.
Através da proposta de implementação, fica
exemplificada a formulação a nível de código, embarcando a [11]
componente prática com uma análise do problema do ponto
de vista teórico, comparando possíveis alternativas presentes
no catálogo GoF e explicando o porquê de sua utilização e
vantagens, primariamente referentes a conexão de diferentes [12]
hierarquias de objetos e delegação do tipo de classe a se
instanciar às subclasses.
[13]
Conclui-se, desta maneira, a obtenção de uma
compreensão abrangente em relação ao Design Pattern
Factory Method. O estudo realizado demonstra que, por seu
[14]
carácter criacional e abrangência, este Pattern pode ser
aplicado em diferentes cenários e em diferentes sistemas, até
mesmo em alguns que não suportem diretamente orientação [15]
a objetos, para onde foi projetado inicialmente.
[16]
Portanto, este estudo, em suma, caracteriza o que é o
Factory Method, suas motivações, estruturação, relevância
através de exemplos de uso na indústria, diferenciação, [17]
conceitos e possíveis implementações.
[18]
VII. AGRADECIMENTOS
Gostaríamos de agradecer aos professores da cadeira de [19]
Arquitetura e Padrões de Software: ao Prof. Dr. Hugo
Paredes, da componente teórica, pela orientação e atribuição [20]
do tema; e ao Prof. Dr. Luís Barbosa, pela exposição do
Design Pattern.
[21]
VIII. REFERÊNCIAS
Helm, R., Johnson, R., Vlissides, J., & Booch, G. (1994). Design
Patterns: Elements of Reusable Object-Oriented Software (1st ed.).
Addison-Wesley Professional.
Wikipedia contributors. (2022a, August 3). Design Patterns.
Wikipedia. https://en.wikipedia.org/wiki/Design_Patterns
Wikipedia contributors. (2022c, October 21). Software design pattern.
Wikipedia. https://en.wikipedia.org/wiki/Software_design_pattern
Refactoring.Guru. (2022b, January 1). Factory Method.
https://refactoring.guru/design-patterns/factory-method
Rost, J. (2004). Is “Factory Method” really a pattern? ACM
SIGSOFT Software Engineering Notes, 29(5), 1–1.
https://doi.org/10.1145/1022494.1022519
Paolo, Í. F. D., Cordeiro, T. D., Sena, J. A. S., Fonseca, M. C. P., Jr,
W. B., Barreiros, J. A. L., Silva, O. F., Rodrigues, É. S., Pardauil, A.
A. B., & Moreira, D. C. ([s.d.]). PADRÃO DE PROJETO FACTORY
METHOD APLICADO À MODELAGEM E ESTUDOS DA
DINÂMICA DE SISTEMAS ELÉTRICOS DE POTÊNCIA.
Ellis, B., Stylos, J., & Myers, B. (2007). The Factory Pattern in API
Design: A Usability Evaluation. 29th International Conference on
Software Engineering (ICSE’07), 302–312.
https://doi.org/10.1109/ICSE.2007.85
Chantarasathaporn, K., & Srisa-an, C. (2006). Energy conscious
factory method design pattern for mobile devices with C# and
intermediate language. Proceedings of the 3rd International
Conference on Mobile Technology, Applications & Systems -
Mobility ’06, 29. https://doi.org/10.1145/1292331.1292364
Refactoring.Guru. (2022, January 1). Factory Method in Go.
https://refactoring.guru/design-patterns/factory-method/go/example
What are the differences between Abstract Factory and Factory
design patterns? (2011, April 21). Stack Overflow.
https://stackoverflow.com/questions/5739611/what-are-the-
differences-between-abstract-factory-and-factory-design-patterns
Satpathy, S. (2022, July 6). Difference between Factory and Abstract
Factory | bitMountn. Medium.
https://medium.com/bitmountn/factory-vs-factory-method-vs-
abstract-factory-c3adaeb5ac9a
Essentials, Part 1, Lesson 1: Compiling & Running a Simple
Program. (n.d.). Retrieved November 4, 2022, from
https://www.oracle.com/java/technologies/compile.html
Nykonenko, A. A. (2012). Creational design patterns in
computational linguistics: Factory Method, Prototype, Singleton.
Cybernetics and Systems Analysis, 48(1), 138–145.
https://doi.org/10.1007/s10559-012-9383-1
Fortuin, H. (2010). A Modern, Compact Implementation of the
Parameterized Factory Design Pattern. The Journal of Object
Technology, 9(1), 57. https://doi.org/10.5381/jot.2010.9.1.c5
Refactoring.Guru. (2022, January 1). Prototype.
https://refactoring.guru/design-patterns/prototype
(2022b, November 15). Factory Model Overview - ADO.NET.
Microsoft Learn. https://learn.microsoft.com/en-
us/dotnet/framework/data/adonet/factory-model-overview
DocumentBuilderFactory (Java 2 Platform SE 5.0). (n.d.-d).
https://docs.oracle.com/javase/1.5.0/docs/api/javax/xml/parsers/Docu
mentBuilderFactory.html
Object (Java 2 Platform SE 5.0). (n.d.-b).
https://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Object.html
Wikipedia contributors. (2022, November 21). Qt (software).
Wikipedia. https://en.wikipedia.org/wiki/Qt_(software)
Wikipedia contributors. (2022b, November 25). Factory method
pattern. Wikipedia.
https://en.wikipedia.org/wiki/Factory_method_pattern
The Qt Project. (n.d.). https://contribute.qt-project.org/doc/qt-
5.0/qtwidgets/qmainwindow.html