Design Patterns in JavaChapter 4Façade Summary prepared by Kirk Scott
Preliminary Note • This book takes the trouble to try and provide concrete examples • This is a great benefit, and at the same time this approach has a shortcoming • The shortcoming is that any applied example will have aspects that are not central to the topic at hand which have to be explained in order to understand the example • At various points in these overheads it will be necessary to dwell on these other aspects before being able to concentrate on the design pattern in question
Façade • The book starts with a review of the supposed benefits of object-oriented code development • The idea is that toolkits of classes are developed, and then application programs can be written which largely depend on the functionality implemented in the toolkits • In the broadest sense, you might think of the Java API as a toolkit
Taking that broad of a point of view illustrates one of the shortcomings of this approach • If the toolkit has too much in it to fully understand, how do you know what features to use or where to start when trying to use to implement an application? • The authors suggest that an IDE might help isolate a programmer from toolkit complexity, while still making the toolkit available for use
However, this implies taking the trouble to learn the IDE • Also, the authors concede that one result of this is that the IDE “automatically” generates a bunch of code for the application programmer—which the programmer may not understand • It’s bad enough when you don’t understand the toolkit • It’s may be worse when you don’t understand what is ostensibly your own code
The façade design pattern is an approach to managing the complexity of a toolkit • The book describes a façade as a “small amount” of code which provides a typical, no-frills usage of the classes in a class library • It expands this description by saying that a façade is class with a level of functionality between a toolkit and an application • This class offers simplified usage of the classes in a package or subsystem
The book states the intent of the façade pattern in this way • The intent of the Façade pattern is to provide an interface that makes a subsystem easy to use
The book will take two approaches to illustrating what a façade is • The first approach is to point out a class in the Java API which it says meets the definition of a façade • This Java API class is not simple • It provides an example of the idea where it would be impossible to delve into everything that went into its implementation
The second approach will be to give a concrete example including code • Although this example doesn’t really show the creation of a façade for a toolkit, it illustrates a use of the design pattern in software development that may be of even greater practical value • It is based on the idea that you may have a programming problem which will involve several different functionalities and will require several different classes to implement
At a very basic level, the first design question is, which classes will you have and which functionalities belong in which classes • A secondary, and equally realistic way of looking at this is that you made those design decisions and you don’t like the resulting code • The façade pattern can be used as a model for abstracting out certain functionalities into one class (the façade) and reorganizing the remaining functionalities in a set of classes that is more logical or convenient
Facades, Utilities, and Demos • If a class which fits the intent of the Façade design pattern consists entirely of static methods, then it is appropriate to refer to it as a utility • The book observes that the limitation this imposes is that you would be prevented from overriding static methods in future subclasses
This is another one of those book insights where my reaction is, “Why would you even have considered overriding static methods? I never even thought of that before.” • Maybe a more useful way of stating this is that if you do develop a façade, containing non-static methods, in theory you could extend the façade class to a different situation and override the methods in it if necessary
Next the book introduces the term demo • This is defined as an example that shows how to use a class or subsystem • Demos provide much of the same information or value to the programmer as a façade, but obviously they are not exactly the same thing • The difference can expressed in terms of the intent or in terms of the use to which they can be put
Challenge 4.1 • Write down two differences between a demo and a façade.
Solution 4.1 • Some differences to note between demos and facades are as follows. • A demo is usually a stand-alone application; a façade is usually not. • A demo usually includes sample data; a façade does not. • A façade is usually configurable; a demo is not • A façade is intended for reuse; a demo is not • A façade is intended for use in production; a demo is not
The book uses the JOptionPane class from the Java API as an example of a façade • If you look in the API documentation, this class has dozens of methods of its own and it inherits literally hundreds of others • It is in the javax.swing package, which implies that it can be used in the writing of graphical user interface code • God only knows how many discrete elements of the swing package the JOptionPane class is based on, or provides a way of using
The book provides example code for an application that pops up a confirm dialog box • It so happens that this is done with a static method call • There is no reason to look at the complete code
The one line of code in question looks like this • option = JOptionPane.showConfirmDialog(…); • This is what the code produces on the screen
The use of the JOptionPane should not be foreign to you, because it was used in unit 17 of CS 202 • In the code for Echo1.java there was a line of code like this • inputString = JOptionPane.showInputDialog(…); • This is what the code produces on the screen
Challenge 4.2 • The JOptionPane class makes it easy to display a dialog. Say whether this class is a façade, a utility, or a demo, and justify your answer.
Solution 4.2 • Note that it makes for poor reading on overheads, but I have been making it a practice to give the challenge solutions in their entirety, and will do so again here
The JOptionPane class is one of the few examples of a Façade in the Java class libraries. • It is production worthy, configurable, and designed for reuse. • Above all else, the JOptionPane class fulfills the intent of the Façade pattern by providing a simple interface that makes it easy to use the JDialog class. • You might argue that a façade simplifies a “subsystem” and that the solitary Jdialog class does not qualify as a subsystem. • But it is exactly the richness of this class’s features that make a façade valuable.
Sun Microsystems bundles many demos in with the JDK. • However, these classes are never part of the Java class libraries. • That is, these classes do not appear in packages with a java prefix. • A façade may belong in the Java class libraries, but demos do not.
JOptionPane has dozens of static methods that effectively make it a utility as well as a façade. • Strictly speaking, though, it does not meet the UML definition of a utility, which requires it to possess solely static methods.
Challenge 4.3 • Few facades appear in the Java class libraries. Why is that?
Here are a few reasonable but opposing views regarding the paucity of facades in the Java class libraries. • As a Java developer, you are well advised to develop a thorough knowledge of the tools in the library. Facades necessarily limit the way you might apply any system. They would be a distracting and potentially misleading element of the class libraries in which they might appear.
A façade lies somewhere between the richness of a toolkit and the specificity of a particular application. To create a façade requires some notion of the type of applications it will support. This predictability is impossible given the huge and diverse audience of the Java class libraries. • The scarcity of facades in the class librarires is a weakness. Adding more facades would be a big help.
Refactoring to Façade will be Delayed • The book next takes up the topic of restructuring a given design using the façade pattern as a model • Before finishing with that discussion, the book brings up the topic of parametric equations, which are used in the example code • I think it makes more sense to dispense with the parametric equations first, and then deal with refactoring to façade without interruptions
Parametric Equations • One example of a case where parametric equations would be useful is when you are interested in plotting a mathematical relationship which isn’t expressed as a function • For example, in Java, graphical objects are generally determined by (x, y, w, h)—in other words, their location is specificed by an (x, y) pair
The (x, y) equation for the circle centered at the origin with radius 1 is x2 + y2 = 1. • If you solve for y, you get y = ±√(1 – x2), which is not a function • However, if you convert to polar coordinates, for a circle of radius r, for any angle θ (consider the range 0 to 2π), these relationships hold: • sin = y / r • cos = x / r
Solving for x and y gives: • y = r sin θ • x = r cosθ • Polar coordinates arise as a natural alternative to Cartesian coordinates • When presented as given here, they illustrate parameterization • x and y are expressed in terms of a constant r, and a variable, or parameter, θ, and the expressions for x and y are functional in θ • There is no confusion about ± values
Converting a given equation to a parametric form can also be useful even if the equation is already a function • Consider some of the challenges of representing a mathematical function using the simple graphical capabilities of Java
A. You have to match up the actual width of the display panel in Java with the range of values x takes on in the function of interest • B. You have to do the same for y. • C. Also, you have to deal with the fact that in Cartesian coordinates, the positive y axis points up, while in Java, the positive y axis points down
By parameterizing an equation it is possible arrive at expressions for x and y that separately take into account the width and height of the display panel and the inversion of y • In general, this means that code can be written so that w and h themselves variables or input parameters to methods • This means that code for graphing can accommodate changes in w or h, namely, the dimensions of the display panel
The book’s example code involves displaying the trajectory of a shell • This is a projectile that is shot without any propellant of its own (it’s not a rocket) • If air resistance and wind are ignored, and if the shell doesn’t explode in mid-air and returns to earth, its flight path is a simple parabola
The book empirically derives some parametric equations for this scenario • In other words, it approaches the problem by example, using some implicit rules of thumb • It doesn’t go into any deep theory about parametric equations • The point is that the example code is implemented using the parametric equations that are derived
The first task in parameterizing is to decide on a parameter • In many physical cases it is customary to use the variable t, denoting time • In practice, t might range from some given starting time to some given ending time • In this example, it may be thought of as representing time—but not clock time
When parameterizing for the purposes of graphical display, it is useful have t start at 0 and end at 1 • Then any value of t between 0 and 1 represents the proportion of time that has passed between the beginning and the end of some physical process • It is not really necessary to think of this as time at all • It can also simply be regarded as a useful mathematical convenience and nothing more
Consider the x axis for a function and for display first • It runs positive from left to right in both Java and in Cartesian coordinates • The only aspect of parameterization that has to be taken care of for x is to make the range of values it takes on correspond to the amount of time that has passed—or, more importantly, to the width of the display panel
The book simply gives this parametric equation for x, which satisfies this requirement: • x = w * t • Clearly, as the value of t goes from 0 to 1, the value of x goes from 0 to w.
Taking care of y involves a few more steps • In general, a parabola has a quadratic equation of the general form y = x2. • However, if you refer to the diagram given earlier, unlike simple parabolas as initially illustrated in math textbooks, the vertex of a flight path parabola is not at the origin, and the parabola does not open upward
The parabola of interest has its vertex at the top center of the display panel, and the parabola opens downward • So the next challenge is to express y in terms of the parameter t • The first empirical observation that the book makes is that if the vertex appears at the midpoint of the panel, that would correspond to half of w, and in terms of t, it would correspond to half of t
This parametric equation for y has the vertex in the middle: • y = (t – .5)(t - .5) • When t = .5, y = 0 • When t = 0 or 1, y = (.5)(.5) = .25 • So far, so good • Not only is the vertex in the middle, but this result is convenient for a parabola that opens downward
The next, intermediate step, is to normalize the maximum value attained by y to 1 • To do this, you introduce a constant to offset the product giving a maximum value of .25 • In other words, you introduce a factor of 4 into the parametric equation: • y = 4(t - .5)(t - .5)
Now that the maximum value of y has been normalized to 1, it’s easy to include h as a variable so that the maximum value is h: • y = 4h(t - .5)(t - .5) • Together, then, these are the parametric equations: • w = wt • y = 4h(t - .5)(t - .5)
Keep in mind that although the parameter in the equations is t • This defines the quadratic relationship between x and y • The shape of the parabola as graphed will depend on the constant 4 and the variables w and h
The parameterization of a parabola as shown here is used in the implementation of the original, un-refactored example code given by the book • It is also used in the new code which results from refactoring using the Façade design pattern • That is why parameterization has been described here, so that there’s no mystery about how the graphing is being accomplished