Question

I know this question was asked for many times, and it may look like the question is a duplicate, but i tried to understand the posts on SO, Google, GoF and didn’t found the answer for me…

I understand the difference between the Factory Method and Builder:
Factory Method – Creates objects that derive from a particular base class, decoupling concrete implementation from client

Builder Method – Hides the complexity of the object creation from client

Now I see example that i found on internet (Abstract Factory Design Pattern for Dependency Injection), it’s about an Abstract Factory, but it doesn’t matter for my question. It’s just one of many articles that i viewed

//Abstract Factory for Dependency Injection
//Factory interface
public interface Module1ServiceFactory {
 ComponentA getComponentA();
 ComponentB getComponentB();
}

//Concrete factory
public class Module1ServiceFactoryImpl {
 private Module1ServiceFactory instance;

 private Module1ServiceFactoryImpl() {}

 public static synchronized Module1ServiceFactory getInstance() {
  if (null == instance) {
   instance = new Module1ServiceFactoryImpl();
  }

return instance;
 }

*** SUBJECT METHOD ***
 public ComponentA getComponentA() {
  ComponentA componentA = new ComponentAImpl();
  ComponentB componentB = getComponentB();
  componentA.setComponentB(componentB);
  return componentA;
 }

 public ComponentB getComponentB() {
  return new ComponentBImpl();
 }
}

What I see in that example, ComponentA is a complex type that getComponentA() method used to build it.

1. So why this is called Factory and not Builder??? Or it means that Module1ServiceFactoryImpl implement Factory AND Builder patterns?
2. Is it correct (commonly used) to create classes/objects that implements more than one design pattern in software architecture design?

And sorry for my English 🙂

Answer 1

So why this is called Factory and not Builder??? Or it means that
Module1ServiceFactoryImpl implement Factory AND Builder patterns?

It’s called factory, because it’s factory, and only factory

*** SUBJECT METHOD ***
 public ComponentA getComponentA() {
  ComponentA componentA = new ComponentAImpl();
  ComponentB componentB = getComponentB();
  componentA.setComponentB(componentB);
  return componentA;
 }

 public ComponentB getComponentB() {
  return new ComponentBImpl();
 }

I see no builder here. Sure, this isn’t simplest approach, but it’s definitely not that complex as it would be, if builder pattern were introduced. This is more like JavaBean-way and using setters on freshly created object. Builder pattern requires creation of object in last step, to make it impossible for creating object to be in state between ready-to-use and not-ready-yet.

Is it correct (commonly used) to create classes/objects that
implements more than one design pattern in software architecture
design?

Yes, it’s correct and used, sometimes. Not that commonly, because every pattern adds some complexity, and multiple patterns add multiple complexity 🙂 But, of course, you can mix builder with factory (builder needs some parts that are factored), facory with builder (factory encapsulates usage of create objects with builder). Patterns are good in working together. MVC is good sample:

The GoF (Gang of Four) do not refer to MVC as a design pattern, but rather consider it a “set of classes to build a user interface”. In their view, it’s actually a variation of three other classical design patterns: the Observer (Pub/Sub), Strategy and Composite patterns. Depending on how MVC has been implemented in a framework, it may also use the Factory and Decorator patterns.

http://addyosmani.com/blog/understanding-mvc-and-mvp-for-javascript-and-backbone-developers/