1 / 6

CS 350 – Software Design Abstract Factory Pattern – Chapter 11

CS 350 – Software Design Abstract Factory Pattern – Chapter 11. Provides an interface for creating families of related or dependent objects without specifying their concrete classes.

ellie
Download Presentation

CS 350 – Software Design Abstract Factory Pattern – Chapter 11

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CS 350 – Software Design Abstract Factory Pattern – Chapter 11 Provides an interface for creating families of related or dependent objects without specifying their concrete classes. Imagine you had a computer system with a High and low resolution display driver as well as a high and low resolution print driver. For Driver In a Low Capacity Machine In a High Capacity Machine Display LRDD HRDD Low Resolution Display Driver High Resolution Display Driver Print LRPD HRPD Low Resolution Print Driver High Resolution Print Driver 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.

  2. 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 Design Abstract Factory Pattern – Chapter 11 A simple solution is to use switch statements as in the following code: //JAVA CODE FRAGMENT Class ApControl { . . . public void doDraw() { . . . switch (RESOLUTION) { case LOW: //use LRDD case HIGH: //use HRDD } } public void doPrint() { . . . switch (RESOLUTION) { case LOW: //use LRPD case HIGH: //use HRPD } } }

  3. CS 350 – Software Design Abstract Factory Pattern – Chapter 11 Let’s apply inheritance to the problem by having two different ap controllers.

  4. CS 350 – Software Design Abstract Factory Pattern – Chapter 11 What’s wrong with the previous approach? Combinatorial explosion. Instead as we said before, it is better to favor aggregation. Instead, let’s have two classes with inheritance.

  5. CS 350 – Software Design Abstract Factory Pattern – Chapter 11 Ap controller now can use the two classes and not have to perform switches to determine which driver to use.

  6. CS 350 – Software Design Abstract Factory Pattern – Chapter 11 The improved Ap controller code follows: //JAVA CODE FRAGMENT Class ApControl { . . . public void doDraw() { . . . myDisplayDriver.draw(); } public void doPrint() { . . . myPrintDrive.draw(); } }

More Related