Midterm Reminders. Design Pattern #6: Facade. General Idea. The Situation

Transcription

1 Midterm Reminders The midterm is next Tuesday: March 4, 7-9 p.m. If you have a conflict and haven't told us, send TODAY! (conflicts with other Queens courses or exams) Location: Stirling Hall rooms A, B and C By last name (regardless of section): Last Name Room A-J Stirling A K-O Stirling B P-Z Stirling C Midterm covers all material up through today. Readings for all topics on web site. Monday: review, Q&A Design Pattern #6: Facade The last of the 6 design patterns we are studying in CISC 323 There are many more From Merriam-Webster Dictionary: Main Entry: fa cade Variant(s): also fa çade /f&-'säd/ Function: noun Etymology: French façade, from Italian facciata, from faccia face, from (assumed) Vulgar Latin facia Date: circa :the front of a building; also : any face of a building given special architectural treatment <a museum's east facade> 2:a false, superficial, or artificial appearance or effect CISC 323, Winter 2003, Design Patterns 1 CISC 323, Winter 2003, Design Patterns 2 The Situation General Idea You have a subsystem composed of several related classes The subsystem can accomplish a task or a group of tasks Each class in the subsystem does a piece of the task To do the task, a user must know about all (or many) of the classes inside a subsystem can be quite complicated. For most uses of the subsystem, all that knowledge isn't necessary Provide a "false front" for the subsystem: make it appear to the user like a single class with a simple interface client classes subsystem classes Facade CISC 323, Winter 2003, Design Patterns 3 CISC 323, Winter 2003, Design Patterns 4 1

2 Example: Keyboard Input To read from the keyboard with Java API: get the "standard input" object from the System class create a BufferedReader object from the standard input read single char or string from the BufferedReader any I/O operations can throw exceptions you must catch and handle (even though most are unlikely from keyboard) More complication: java.io package contains many other classes for: text, binary, serialized input reading from files and other kinds of input streams buffered or unbuffered input makes learning to do simple I/O confusing An Easier Way Depending on when you took CISC 121, you learned how to do keyboard input with a special input package: either SavitchIn or Stdin SavitchIn or Stdin: reads text from keyboard re-prompts or aborts in case or errors very easy to use for this purpose not flexible: many features not included Each of these classes provide a façade to hide the complexity of the Java I/O system Methods inside SavitchIn or Stdin create objects of various API classes and call their methods hidden from user CISC 323, Winter 2003, Design Patterns 5 CISC 323, Winter 2003, Design Patterns 6 Façade Doesn't Hide Classes Advanced users can still use java.io classes directly to access features not provided by the façade Example: Stdin.readChar() skips white space no way to read the next char including spaces and newlines Beginning users appreciate the simpler interface Even advanced users find it useful much of the time Another Example (From Gamma et al) A compiler consists of many pieces: Scanner: characters tokens Parser: tokens parse tree may consist of a director and a tree builder SemanticAnalyzer: checks and annotates parse tree, builds symbol table CodeGenerator: parse tree machine code Optimizer: machine code faster machine code A compiler might make all these pieces available for other programs to use CISC 323, Winter 2003, Design Patterns 7 CISC 323, Winter 2003, Design Patterns 8 2

3 Advantages Gives a program maximum flexibility A program could use just part of the compiler: scanner through semantic analysis as a checker scanner through parser as a front end to a pretty-printer build parse tree by hand and submit to code generator skip optimization phase for faster compilation Each phase will have options (parameters to methods): recognise optional language features or not what kinds of checking to perform how much optimization, what kinds User can specify all these options Disadvantage: Complexity The typical program just wants to compile a program Doesn't care about fancy options, other uses of compiler parts Learning about all the components of the compiler subsystem is a lot of work, error-prone CISC 323, Winter 2003, Design Patterns 9 CISC 323, Winter 2003, Design Patterns 10 Solution: A Compiler Facade public class Compiler { public static boolean compile( String infile, String outfile) { <open stream for infile, outfile> TokenStream tokens = Scanner.scan(in stream); TreeBuilder builder = new TreeBuilder(); Parser parsedir = new Parser(builder); parsedir.construct(tokens); builder.finish(); ParseTree tree = builder.getparsetree(); SemanticAnalyzer.analyze(tree); CodeStream code = CodeGenerator.gen(tree); Optimizer.optimize(code); <write code to output file> <return true if we finished without errors> } } CISC 323, Winter 2003, Design Patterns 11 Options Compiler façade class could include a few extra parameters to compile method for most common options: level of error checking level of optimization Or more than one compile method: normal compile compile with extra optimization etc. CISC 323, Winter 2003, Design Patterns 12 3

4 Users The average user who just wants to compile a program would use the Compiler façade and not have to learn about all the classes in the compiler subsystem. An advanced user who wanted all the fancy options could still use the individual classes A user who wants to build a different tool with pieces of the compiler can still do so No functionality lost, easier interface provided for the typical user One More Example: Java Dialogs To create GUIs in Java, use javax.swing package Many classes and methods, takes a while to learn Suppose we just want a simple pop-up question: This is called a modal dialog "modal" means program suspends until user answers question CISC 323, Winter 2003, Design Patterns 13 CISC 323, Winter 2003, Design Patterns 14 Steps For Creating a Pop-Up Dialog Create a new JDialog object specify that it's a modal object (program suspends until user responds) create components to go into the dialog: question text, text input box, two buttons specify layout of components on the dialog, size and shape of dialog specify actions to take when buttons are clicked includes retrieving text from input box, returning value to user Facade Problem: This is a lot of steps for a simple dialog! Most dialogs fall into one of a few general patterns: yes/no question fill in a blank type "OK" in response to a message Solution: Java package provides a façade for creating simple dialogs: class JOptionPane JOptionPane provides methods for creating typical, frequently-used kinds of dialogs CISC 323, Winter 2003, Design Patterns 15 CISC 323, Winter 2003, Design Patterns 16 4

5 A JOptionPane Method String name = JOptionPane.showInputDialog( "What is your name? "); Another JOptionPane Method int answer = JOptionPane.showConfirmDialog(null, "Do you really want to exit?"); answer gets 0 for yes, 1 for no, 2 for cancel CISC 323, Winter 2003, Design Patterns 17 CISC 323, Winter 2003, Design Patterns 18 One More JOptionPane Method JOptionPane.showMessageDialog(null, "You made an error; try again"); Value of JOptionPane basic methods in JOptionPane are easy enough for a beginner to use building a dialog from scratch takes a while to learn JOptionPane is a great convenience even for advanced users JDialog class is still there if you want complete control: layout not covered by a JOptionPane method customized appearance (colors, fonts, etc.) There are more such methods in JOptionPane other kinds of dialogs extra options CISC 323, Winter 2003, Design Patterns 19 CISC 323, Winter 2003, Design Patterns 20 5

6 Differences Between Adapter & Facade both are structural patterns with the goal of providing a "better" interface to some existing functionality differences? Difference Between Adapter & Facade both are structural patterns with the goal of providing a "better" interface to some existing functionality differences? adapter is providing an alternate interface to one class; façade is providing an interface to a collection of classes "better" interfaces in a slightly different sense façade: better means simpler adapter: better means more suited to a particular situation (i.e. using a linked list as a queue) CISC 323, Winter 2003, Design Patterns 21 CISC 323, Winter 2003, Design Patterns 22 Summary of Design Patterns Discussed Performance Issues creational pattern: Builder structural patterns: Adapter Composite Façade behavioral: Iterator Visitor Quality Attributes: readability modularity usability reusability performance In general, most design patterns improve some quality attributes (modularity, reusability, etc) expense is possible minor performance penalties (time and/or memory) due to creating more objects, extra method calls Usually small performance penalties won't matter Be very cautious about putting performance first: modern computers are very fast compilers are smart and getting smarter may optimize away a lot of overhead performance is very hard to predict: not intuitive CISC 323, Winter 2003, Design Patterns 23 CISC 323, Winter 2003, Design Patterns 24 6

7 Interactions Between Design Patterns Large OO systems may use lots of different design patterns, sometimes in combinations Examples: Composite pattern to define parse tree structure with: Iterators to visit all children of a node Visitors for tree traversals Builder for generating parse tree Façade to provide easy use of a Director/Builder pair Adapter to adapt the general Enumeration interface for a particular purpose (i.e. an Enumeration over a collection of Strings should return Strings, not Objects) CISC 323, Winter 2003, Design Patterns 25 7