cs 350 – software design abstract factory pattern – chapter 11 provides an interface for...
TRANSCRIPT
CS 350 – Software DesignCS 350 – Software Design Abstract Factory Pattern – Chapter 11 Abstract Factory Pattern – Chapter 11
Provides an interface for creating families of related or dependent objects without Provides an interface for creating families of related or dependent objects without specifying their concrete classes.specifying their concrete classes.
Imagine you had a computer system with a High and low resolution display driver Imagine you had a computer system with a High and low resolution display driver as well as a high and low resolution print driver.as well as a high and low resolution print driver.
For DriverFor Driver In a Low Capacity MachineIn a Low Capacity Machine In a High Capacity MachineIn a High Capacity Machine
DisplayDisplay LRDDLRDD HRDDHRDD
Low Resolution Display DriverLow Resolution Display Driver High Resolution High Resolution Display DriverDisplay Driver
PrintPrint LRPDLRPD HRPDHRPD
Low Resolution Print DriverLow Resolution Print Driver High Resolution Print DriverHigh Resolution Print Driver
While in this case the items are mutually exclusive, this is not always the case. A While in this case the items are mutually exclusive, this is not always the case. A mid-range computer system might use a LRDD and a HRPD.mid-range computer system might use a LRDD and a HRPD.
CS 350 – Software DesignCS 350 – Software Design Abstract Factory Pattern – Chapter 11 Abstract Factory Pattern – Chapter 11
A simple solution is to use switch statements as in the A simple solution is to use switch statements as in the following code:following code:
//JAVA CODE FRAGMENT//JAVA CODE FRAGMENT
Class ApControl {Class ApControl { . . . . . . public void doDraw() {public void doDraw() { . . . . . . switch (RESOLUTION) {switch (RESOLUTION) { case LOW: case LOW:
//use LRDD//use LRDD case HIGH:case HIGH:
//use HRDD//use HRDD }} }} public void doPrint() {public void doPrint() { . . . . . . switch (RESOLUTION) {switch (RESOLUTION) { case LOW: case LOW:
//use LRPD//use LRPD case HIGH:case HIGH:
//use HRPD//use HRPD }} }}}}
Why is this bad?
Obviously I have said switch statements are not good, but that’s the superficial answer.
The problem is that the code has to decide over and over again and in multiple places what driver it has to use.
This leads to tight coupling and weak cohesion.
CS 350 – Software DesignCS 350 – Software Design Abstract Factory Pattern – Chapter 11 Abstract Factory Pattern – Chapter 11
Let’s apply inheritance to the problem by having two different Let’s apply inheritance to the problem by having two different ap controllers.ap controllers.
CS 350 – Software DesignCS 350 – Software Design Abstract Factory Pattern – Chapter 11 Abstract Factory Pattern – Chapter 11
What’s wrong with the previous approach?What’s wrong with the previous approach?
Combinatorial explosion.Combinatorial explosion.
Instead as we said before, it is better to favor aggregation.Instead as we said before, it is better to favor aggregation.
Instead, let’s have two classes with inheritance.Instead, let’s have two classes with inheritance.
CS 350 – Software DesignCS 350 – Software Design Abstract Factory Pattern – Chapter 11 Abstract Factory Pattern – Chapter 11
Ap controller now can use the two classes and not have to perform switches to Ap controller now can use the two classes and not have to perform switches to determine which driver to use.determine which driver to use.
CS 350 – Software DesignCS 350 – Software Design Abstract Factory Pattern – Chapter 11 Abstract Factory Pattern – Chapter 11
The improved Ap controller code follows:The improved Ap controller code follows:
//JAVA CODE FRAGMENT//JAVA CODE FRAGMENT
Class ApControl {Class ApControl {
. . . . . .
public void doDraw() {public void doDraw() {
. . . . . .
myDisplayDriver.draw();myDisplayDriver.draw();
}}
public void doPrint() {public void doPrint() {
. . . . . .
myPrintDrive.draw();myPrintDrive.draw();
}}
}}