Design Pattern

Java Design Pattern repository

Creational Design Pattern

Singleton

• Only one instance created
• Guarantees control of resources
• Lazily loaded
• Examples: Runtime, Logger, Spring Beans, Graphic Manager
• Design Considerations
  • Class is responsible for lifecycle
  • Static in nature
  • Needs to be thread safe
  • Private instance
  • Private Constructor
  • no parameters required for construction
• Excercise
  • Create Singleton
  • Demonstrate only one instance created
  • Lazily Loaded
  • Thread safe
• Pitfalls
  • Often overused
  • Difficult to unit test
  • If not careful, not thread-safe
  • Sometimes confused with factory. If need to pass parameter to create instance method, it's not single while factory
  • java.util.Calendar in NOT Singleton, it's prototype
• Contrast to Other Pattern

Singleton	Factory
Returns the same instance as one constructor method with no-args	Returns various instances i.e. Multiple constructors
No Interface	Instance Driven
	Easily adaptable

Summary

• Guarantee one instance
• Easy to implement
• Solves a well defined problem

Builder

• Handles complex constructors
• Large number of parameters
• Immutability
• Examples: StringBuilder, DocumentBuilder, Locale.Builder
• Design Considerations
  • Flexible over telescoping constructors
  • Static inner class
  • Calls appropriate constructor
  • Negates the need for exposed setters
• Excercise
  • Exposed Setters
  • Create Builder
• Pitfalls
  • Immutable
  • Inner static class
  • Designed first
  • Complexity
• Contrast to Other Pattern

Builder	Prototype
Handles complex constructors	Implemented around a clone
No Interface	Avoids calling complex construtors
Works with Legacy code	Difficult to implement in Legacy code

Summary

• Creative way to deal with complexity
• Easy to implement
• Can refactor in a separate class

Prototype

• It is used when object creation is a constly affair and requires al lot of tine and resources and you have similar object already existing.
• Creating new objects by cloning (shallow or deep copy) other objects.
• Avoids subclassing
• Typically doesn't use "new"
• Often utilizes an interface"
• Usually implemented with Registry
• When there are many potential classes that you want to only use if needed at runtime
• Reduces the need for creating subclasses
• Example: If there is an object that is responsible to load the data from database and data needs to be modify multiple times. So it is not better idea to create the object using new and load the data form database to multiple calls to database. The prototype design pattern supports shallow and deep object cloining.
• Pitfalls
  • It is often not used because sometimes not clear when to use
  • Shallow vs Deep cooy
• Contrast to Other Pattern

Prototype	Factory
Lighter weight construction i.e. Copy constructor or Clone	Flexible Objects i.e. Multiple constructors
Shallow or Deep	Concrete Instance
Copy of itself	Fresh Instance

Summary

• Guarantee to create unique instance
• Helps with performance issues instead of creating heavy weight objects
• Always look for an opportunity to go for Prototype despite often jump to Factory pattern

Factory

• It doen't expose an instantiation logic as the client knows nothing about implementaion
• It defers instantiation and creation logic to subclass
• The client only knows about common interface that is exposed by Factory
• Examples: Calendar, ResourceBundle and NumberFormat
• Design Considerations
  • Factory is responsible for managing object's lifecycle
  • Object created are referenced through common interface
  • Refer multiple concrete classes
  • The method to request object are typically parameterized
• Excercise
  • Create pages
  • Create website
  • Create Concrete Classes
  • Create Factory
  • Enum
• Pitfalls
  • Complexity
  • Creation of subclass
  • Not to be refactoring, so generally needs to be designed in the begining
• Contrast to Other Pattern

Singleton	Factory
Returns same instance i.e. One Constructor method - no args	Returns various instances i.e. Multiple constructors
No Interface	Instance Driven
No Subclasses	Subclasses
	Easily adaptable

Summary

• Parameter Driven
• Solves complex creation
• Opposite of a Singleton

AbstractFactory

• Factory of factories
• Factory of related objects
• Common Interface
• Defer to Subclasses
• Examples: DocumentBuilder, Frameworks
• Design Considerations
  • Groups Factories together
  • Factory is responsible for lifecycle
  • Common Interface
  • Concrete Classes
  • Parameterized create method
  • Composition
• Excercise
  • AbstractFactory
  • Factory
  • Product
• Pitfalls
  • Complexity
  • Runtime switch
  • Pattern within a pattern
  • Starts as a Factory
• Contrast to Other Pattern

AbstractFactory	Factory
Implemented with Factory	Returns various instances i.e. Multiple constructors
Hides the factory	Instance Driven
Abstract environment	Subclasses
Built through composition	Easily adaptable

Summary

• Groups of similar factories
• Solves complex creation
• Heavy abstraction
• Framework pattern

Structural Design Pattern

Adapter

• Plug adapter
• Convert interface to another interface
• Legacy
• Translate requests
• Clinet, Adaptor, adaptee
• Examples: Arrays -> List, Streams
• Design Considerations
  • Client centric
  • Integrate new with old
  • Interface but not required
  • Concrete Classes
  • Adaptee can be the implementation
• Excercise
  • Create Adapter
  • Not to become Decorator
  • Another Adapter
• Pitfalls
  • Not complicated
  • Multiple Adapter
  • It doesn't addd functionality
• Contrast to Other Pattern

Adapter	Bridge
Works after code is designed	Designed upfront
Legacy	Abstraction and implementation vary
Retrofitted	Built in advance
Provides different interfaces	Both adapt multiple systems

Summary

• Simple solution
• Easy to implement
• Integrate with Legacy
• Can provide multiple adapter

Bridge

• Similar to adapter but difference is that it works with new code while adapter works with Legacy code
• Decouple Abstraction and implemention
• Encapsulation, Composition, Inheritance
• Changes in abstraction won't affect client
• Examples: Driver, JDBC Driver
• Design Considerations
  • Uses interfaces and abstract classes
  • Composition over inheritance
  • More than composition
  • Expect change from both sides
• Excercise
  • Color and Shape
  • Color and Shape Bridge
  • Create Bridge
  • Another Bridge
• Pitfalls
  • Not complicated
  • Multiple Adapter
  • It doesn't addd functionality
• Contrast to Other Pattern

Adapter	Bridge
Works after code is designed	Designed upfront
Legacy	Abstraction and implementation vary
Retrofitted	Built in advance
Provides different interfaces	Both adapt multiple systems

Summary

• Simple solution
• Easy to implement
• Integrate with Legacy

asd

• Can provide multiple adapter