Design Patterns A General reusable solution to a commonly occurring problem in software design. Creational: Deal with object creation mechanisms – Example: Abstract Factory Structural: Simplify design by identifying a simple way to realize relationships between entities. – Example: Bridge Behavioral: Identify common communication patterns between objects and realize these patterns. – Example: Strategy

Abstract Factory

Abstract Factory (Creational) Applying context: A client or application may want to use different types of objects with common behavior and easily change between those types before or during execution. Problem: Changing types of objects through the application is difficult because instantiation requires to know the type of object to be declared. Also different types might have different methods to use their functionality.

Abstract Factory (Creational) Solution: Isolate the client code from object creation by having client just ask for (and handle) a factory object. This factory object is an abstract data type which can only be used through an interface. Discussion: By having the client dependant just on the interface of the Abstract Type Product provided by the Abstract Factory. Each Concrete Product must be able to work under the interface that the Abstract Product provides. The client is able to change the Concrete Type Product by changing the Concrete Factory that is being used. This change is usually done by changing one line in one file.

Factory Classes

Product Classes

Client

Bridge Design Pattern

Problem The use of subclasses to provide additional implementation has caused the “hardening of the software arteries.” This limits the ability to independently extend the abstraction and the implementation.

UML Class Diagram

Purpose To “decouple abstraction from its implementation.” To “publish interface in an inheritance hierarchy, and bury implementation within it’s own inheritance hierarchy.”

Disadvantages Although it provides more flexibility, it increases the complexity of the software. Might have performance issues due to longer communication path between the abstraction and implementation.

Strategy Context: Your system has lots of different behaviors that can change in runtime and not easily manageable.

“Strategy”’s Strategy Separate behavior from implementation (encapsulate behavior). index.php?title=TheStrategyPattern /images/f/ff/Ff13-paradigm.jpg

class StrategyExample { public static void main(String[] args) { Context context; context = new Context(new ConcreteStrategyAdd()); int resultA = context.executeStrategy(3,4); context = new Context(new ConcreteStrategySubtract()); int resultB = context.executeStrategy(3,4); context = new Context(new ConcreteStrategyMultiply()); int resultC = context.executeStrategy(3,4); } } interface Strategy {int execute(int a, int b); } class ConcreteStrategyAdd implements Strategy { public int execute(int a, int b) { System.out.println("Called ConcreteStrategyAdd's execute()"); return a + b;} } class ConcreteStrategySubtract implements Strategy { public int execute(int a, int b) { System.out.println("Called ConcreteStrategySubtract's execute()"); return a - b;} } class ConcreteStrategyMultiply implements Strategy { public int execute(int a, int b) { System.out.println("Called ConcreteStrategyMultiply's execute()"); return a * b;} } class Context { private Strategy strategy; public Context(Strategy strategy) {this.strategy = strategy; } public int executeStrategy(int a, int b) { return strategy.execute(a, b); } }

Strategy v Bridge Same UML DiagramDifferent IntentStrategy = BehaviorBridge = Structure