Design Patterns
Because Design Patterns are part of the assignment and exam (also in other Sun exams), you need to know about them. A Design Pattern defines a named design strategy and model outlining solution that addresses a set of responsibilities in a popular context. In short, a Design Pattern constitutes a model that helps meet a recurring need. Most Pattern books say it this way: a solution for a recurring problem in a given context. This popular definition is based on E. Gamma, R. Helm, R. Johnson, and J. Vlissides' book Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995), which applies Christopher Alexander's (A Pattern Language, Oxford University Press, 1977) seminal architecture innovation of Patterns to software.
The confidence in the merit of a given Pattern increases with the number of times it has been used successfully. It is straightforward to formalize a pattern after it has been used extensively in the industry. This is helpful when software designers share their secrets with others. Design Patterns are a guide that should survive functional changes that are handled at the implementation level. Patterns give a rationale for their context of applicability.
Good design starts with requirements (wish list), moves to responsibilities (set of objects that fulfill requirements), and ends with functionality (behavior within objects that meets responsibilities). The requirements are given to the designer, and the functionality is the details of an implementation. Between these are the responsibilities—the focus of patterns.
A pattern canonizes a design approach for a set of responsibilities. You could propose Window as a pattern that defines how to design user interfaces. Indeed, computers could use better interfaces, but Window is so broad and encompasses so many responsibilities that it loses utility. At the other extreme, you could propose a pattern named Choice that defines how to write code that makes decisions. It would provide some guidance beyond using a switch statement, but Choice is too close to implementation. It is too narrow in scope and tries to address a responsibility that occurs in too many contexts. Another bad candidate would be MyCompany Customer Manager, which addresses the need to manage one particular company's flat file database that stores customer information. Although it is complex, too few programmers would use it because it deals with a proprietary situation.
Another wrong idea is the Overcharge Alert pattern, which sends an email to collections when a customer overcharges his credit card. It is proprietary and has only one responsibility. The Overcharge Alert is too specific to be a pattern. Real patterns are between all these. For example, the Façade pattern tells how to design one interface that acts as a mediator for many others. It reduces to one the number of interfaces that a client faces. The Façade defines a parent interface making a subsystem easier to use. The Façade has fewer responsibilities than Windows and MyCompany Customer Manager. It has a context that is encountered by more programmers than MyCompany Customer Manager and Overcharge Alert. It is more general than the Overcharge Alert.
For the assignment, it is recommended that you employ two Design Patterns: Model-View-Controller (MVC) and Data Access Object (DAO). These are rather high-level Patterns, but the ones that Sun is probably looking for in your submission. MVC (java.sun.com/blueprints/patterns/j2ee_patterns/model_view_controller/index.html) addresses the need to support multiple enterprise clients, the very thing that this assignment describes. MVC will help you design a JFC/Swing interface to a database server over a network. MVC allows you to separate core data access functionality from the presentation and control logic. This separation allows multiple views to share the same enterprise data model.
Your assignment instructions will include the requirement that you design the user interface with the expectation of future functionality enhancements, and it should establish a control scheme that will support this with minimal disruption to the users when this occurs. In other words, use MVC. The model represents the database and has access and update rules for the data. The view is the Swing GUI. The assignment instruction reads as if it is lifted right out of the MVC definition. The view's responsibility is to maintain consistency in its presentation when the model changes. The controller translates interactions with the view into actions that the model performs. In the stand-alone GUI client, the user's clicks will cause the controller to respond by selecting an appropriate view. See Figure 20.1 for a representation of the MVC architecture as it is being used here.
Figure 20.1. The relationship between the model, the view, and the controller in the MVC architecture.
The second Pattern you need is DAO. The database is a group of classes for reading and writing to a random access file. Most databases are the same under the hood. Your assignment download will likely include this piece. However, it is incomplete. You will need to add functionality to complete the assignment. Be careful to observe the DAO Pattern. The main thing to know about DAO is that it decouples business logic from data access logic. This approach makes it easy to change the actual database file and access logic, or to change the other end: the business logic piece.