13/3/2018 Design Patterns - Exercises

Design Patterns
Exercises
1. Are design patterns a form of reuse? If so, what are you reusing?

Ans. Design patterns allow you to reuse architecture and design.

2. Do design patterns provide architecture?

Ans. No. You might say that design patterns provide micro­architecture but architecture refers to how the components of the system as a whole
work together. Design patterns offer solutions to specific problems that are only part of the whole system.

3. What makes coupling "loose"?

Ans. An object is loosely coupled if it is dependent on only a few other objects and/or the dependencies are abstract. For example, in the Observer
design pattern the observed object is loosely coupled to the observer objects not because the observed object has few dependencies (there might
be hundreds of observers). The observed object is loosely coupled to its observers because it is dependent only on the abstract interface Observer.

4. How are design patterns different from programming idioms?

Ans. Idioms are reoccurring solutions to common programming problems. For example, here is the Java idiom for ending a program when the
window is closed:

addWindowListener(
  new WindowAdapter() {
    public void windowClosing(WindowEvent e) {
      System.exit(0);
    }
  }
);

Idioms are low­level patterns specific to a programming language. Design patterns are high­level and language independent.

During implementation you look for idioms. During design you look for patterns.

5. How are design patterns different from frameworks?

Ans. Frameworks are semi­complete applications. For example, the Microsoft Foundation Classes (MFC's) are a framework for writing C++
windows applications. Frameworks may include design patterns, but aren't by themselves design patterns. Design patterns are more general than
frameworks. A framework can't be used to generate an architecture or solution to a problem­­the framework is the architecture. Design patterns are
generative. This means that you can generate a specific solution from a design pattern.

6. How are design patterns different from principles and strategies? For example, "components should have strong cohesion and weak coupling" is an object
oriented design principle.

Ans. Principles and strategies are more general than design patterns. The same principle or strategy can be applied to many different types of
problems. A design pattern solves a specific problem. A principle doesn't include all the elements of a design pattern. For example, a principle
doesn't explain how to achieve the desired state.

7. How are design patterns different from algorithms and data structures?

Ans. There is a different focus. Algorithms and data structures are focused on time and space efficiencies. Design patterns are focused on
architectural issues such as maintainability and extendibility. Algorithms and data structures provide solutions to computational problems like sorting
and searching. Patterns provide solutions to architectural problems like interchanging sorting algorithms without disrupting other code.

Put another way, design patterns answer the main question asked at design time: "how do I organize or modularize the code that will make up the
solution?" Algorithms and data structures answer the main question asked at implementation time: "how do I implement the code efficiently?" Few
algorithms or data structures are more then one module.

8. Is a hash table a design pattern?

Ans. No. A hash table is a data structure. A hash table is a specific solution, not a design generalization that can be applied in different contexts. A
design pattern is more abstract than a data structure.

9. How are design patterns different from class libraries?

Ans. Class libraries are specific solutions written for a specific environment/language. You use class libraries. You apply design patterns.

10. Can any design solution be a design pattern?

Ans. No. To be a design pattern the problem it solves should be reoccurring. The solution should also have been tested on multiple problems in
different contexts. The design pattern should have undergone some scrutiny.

Design patterns form an exclusive club. Membership is reserved for crusty old solutions that have been around for awhile.

11. (True / False)  You can't draw a sequence diagram for a design pattern. You need a context.

Ans. Taken literally the answer is true. However, it's common to communicate design patterns with a class and sequence diagram. A design pattern
isn't an implementation so you can't document it with a sequence diagram. You can, however, show an example of a design pattern with a
sequence diagram. This is a common way to explain a design pattern.

12. An example was given for each design pattern discussed in this chapter. How is the "design pattern" different from the example of the design pattern?

http://sce2.umkc.edu/BIT/burrise/pl/design-patterns/qanda.html 1/9
13/3/2018 Design Patterns - Exercises
Ans. The design pattern is more general. The design pattern is limited to the essential architecture elements given in the example.

13. [Extra for Experts] There is a significant performance penalty for declaring a method synchronized. In general adding the keyword synchronized to a
method slows the invocation of the method by a factor of 6. A common programming idiom used to avoid synchronization in the common case is double check
locking.

Can the double­check locking idiom be used with the singleton pattern to avoid synchronizing every time the static instance method is called? For example, is
the following valid:

public class Singleton {

    private Singleton() { }

    static private Singleton instance = null;

    static public Singleton instance() {

        // Double check locking idiom
        // The synchronization is done internally
        // rather than on the method. This avoids
        // the expense of synchronizing for the
        // common case.
/*12*/  if( instance == null ) {
            synchronized( Singleton.class ) {
                // Second check
                if( instance == null ) {
/*16*/               instance = new Singleton( );
                 }
            }
        }
/*20*/  return instance;
    }
}

Ans. No. It might work some of the time but it's not guaranteed to work all of the time.

Key to understanding why is understanding that memory reads and writes may be reordered. For example, given the following code:

x = 1;
y = 2; 

The write to y may occur before the write to x. Reads and writes are regularly reordered by the compiler and runtime system to improve
performance. Reordering the two writes above seems harmless because there are no obvious dependencies between these two statements.
However, in a multi­threaded environment you can't assume the assignments will be made in the order they are listed here. For example, if the
writes are reordered one thread may assign y a value and be swapped out. If a second thread sees that y has a value and assumes x will also, this
false assumption could lead to a very difficult to detect error.

A similar situation can cause problems for the double­checked locking solution proposed above. To see why consider two threads calling instance().
The first finds the local variable instance null so proceeds to line 16 where the constructor for Singleton is initiated. Further, assume that the
compiler inlined the contents of the Singleton() constructor. Since reads and writes can be reordered it 's possible for the value of the reference to
the new object to be assigned at line 16 before all the writes in the constructor have been committed to memory. A second thread could then find
instance != null at line 12 and a reference to a partially constructed instance would be returned at line 20. The object doesn't get created twice by a
thread could get a reference to a partially constructed singleton object.

To avoid problems like this you must synchronize (1) whenever you read data written by another thread and (2) whenever you write data that will be
read by a different thread. You synchronize in the first case so the local memory will be refreshed (read from shared memory), and you synchronize
in the second case so local memory will be written to shared memory. This will guarantee correctness according to Java's memory model. Java's
memory model allows optimizations like this to improve runtime performance.

14. [Extra for Experts] Show that it is possible to avoid the overhead of a synchronized method using static data initialization. What are the limitations of this
solution compared with the general case?

Ans. 

public class Singleton {

    private Singleton() { }

    static private Singleton instance = new Singleton( );

    static public Singleton instance() {

        return instance;
    }
}

The primary limitation is that any data needed to initialize the instance of the singleton class must be available during static initialization. Note, using
static initialization is not necessarily any less efficient than the general case. Static initialization doesn't occur until the class is referenced.

15. There are two methods for propagating data to observers with the Observer design pattern: the push model and the pull model. Why would one model be
preferable over the other? What are the trade­offs of each model?

Ans. The push model requires subjects to be aware of what data the observers need. This increases coupling between subject and observers. The
pull method decreases coupling but may be less efficient. The observers will need to calculate what changes were made or assume anything could
have changed. Note, in both cases the observers must have some knowledge of the subject they are observing (either to interpret the parameter
passed on the update method or to query the subject for its updated state). Coupling can be reduced if the observers know the subject via an
abstract class.

http://sce2.umkc.edu/BIT/burrise/pl/design-patterns/qanda.html 2/9
13/3/2018 Design Patterns - Exercises
16. Does the following code fragment implement the Factory Method design pattern?

public class XMLReaderFactory {

    // This method returns an instance of a class
    // that implements the XMLReader interface.
    // The specific class it creates and returns is
    // based on a system property.
    public static XMLReader createXMLReader();
}

public interface XMLReader {

    public void setContentHandler(ContentHandler handler):
    public void parse(InputStream is);
}

Ans. It might follow the spirit of the pattern but it doesn't follow the literal definition of the Factory Method design pattern. It does create a class in a
way that is independent of the client but it doesn't define an abstract factory method.

17. The Abstract Factory design pattern often uses the Factory Method design pattern to create objects but it doesn't have to. Rewrite the abstract music
factory example given in this chapter to use the Prototype design pattern (not discussed in this chapter) rather than Factory Method to create products.

Ans.

// In this example the abstract factory design pattern

// is implemented using the prototype design pattern
// rather than the factory method design pattern.

class PrototypeMusicFactory {
    private Player player;
    private Media media;
    public PrototypeMusicFactory(Player p, Media m) {
        player = p;
        media = m;
    }
    public Player createPlayer() {
        return (Player)player.clone();
    }
    public Media createMedia() {
        return (Media)media.clone();
    }
}

abstract class Player implements Cloneable {

    public abstract void play(Media m);
    public Object clone() {
        Object o = null;
        try {
            o = super.clone();
        } catch (CloneNotSupportedException e) {
            // Should never get here since Cloneable
            // is implemented above.
            System.out.println("Clone not supported");
        }
        return o;        
    }
}

class RecordPlayer extends Player {

    public void play(Media m) {
        System.out.println("Playing " + m + " on a record player");
    }
}

class CDPlayer extends Player {

    public void play(Media m) {
        System.out.println("Playing " + m + " on a CD player");
    }
}

abstract class Media implements Cloneable {

    public abstract String toString();
    public Object clone() {
        Object o = null;
        try {
            o = super.clone();
        } catch (CloneNotSupportedException e) {
            // Should never get here since Cloneable
            // is implemented above.
            System.out.println("Clone not supported");
        }
        return o;        
    }
}

http://sce2.umkc.edu/BIT/burrise/pl/design-patterns/qanda.html 3/9
13/3/2018 Design Patterns - Exercises

class Album extends Media {

    public String toString() {
        return "an album";
    }
}

class CD extends Media {

    public String toString() {
        return "a CD";
    }
}

public class PrototypeMusicFactory {

    public static void main(String[] args) {
        PrototypeMusicFactory pmf = new
            PrototypeMusicFactory(new CDPlayer(), new CD());
        listenToMusic(pmf);

        pmf = new PrototypeMusicFactory(new RecordPlayer(), new Album());

        listenToMusic(pmf);
    }

    public static void listenToMusic(PrototypeMusicFactory pmf) {

        Player p = pmf.createPlayer();
        Media m = pmf.createMedia();
        p.play(m);
    }
}

18. Why does the update method in the Observer interface include a reference to the object being observed? Doesn't the observer know what object it is
observing?

public interface Observer {

    void update(Observable o, Object arg);
}

Ans. The observer may be observing more than one object. The Observable parameter identifies the object which has been updated.

19. Identify the coupling between the classes (client, iterator, aggregate) with the iterator design pattern.

Ans. There is weak coupling client<­­>iterator and client<­­>aggregate. There is strong coupling iterator<­­>aggregate. The iterator must have
detailed knowledge of the aggregate data structure.

20. What is the difference between the observer design pattern and the publish­subscribe design pattern?

Ans. Nothing, these are two names for the same pattern. Occasionally patterns evolve to be associated with different names.

21. The following abstract diagram illustrates the dependencies between components of the model­view­control design pattern. Which arrow type (dashed or
solid) represents strong coupling? Which represents loose coupling? What is the nature of the relationships between the components that results in these
dependencies? For extra credit, describe a variation of the MVC design pattern that has a different set of dependencies.

Ans. Solid arrows represent strong coupling and dashed arrows represent weak coupling. Strong coupling implies a reference to a specific class, a
concrete class. Weak coupling implies a reference to an abstract class or interface. The dashed arrows in the above diagram represent references
to Observers, that is objects that implement the Observer interface.

Model is weakly coupled to view because model knows about generic observers that want to be notified when there is a change in the model. View
is strongly coupled to Model because View needs to get the details of Model for display to the user. View is weakly coupled to Controller because
view only needs to inform controller of UI events that have occurred. Controller is strongly coupled to View because Controller may need to get/set
specific values from/of View. Controller is strongly coupled to Model because Controller may need to change the details of Model based on events
from View.

22. Do design patterns have to be object oriented (i.e. rely on inheritance and/or polymorphism)?

Ans. No. For example, the singleton design pattern isn't object oriented.  However, most design patterns are object oriented. One explanation is
that object oriented design is harder and therefor more dependent on documented solutions. Another explanation is that object oriented techniques
are an essential part of good design.

23. This question describes an imaginary situation and you are to decide which design pattern or patterns apply.

Imagine your surprise this Christmas when, instead of traditional presents under the tree, you find boxes with labels and handles. When you pull a handle a
present comes out. The present is unique but it matches the category label on the box. Some boxes are labeled with age ranges. These boxes will produce
http://sce2.umkc.edu/BIT/burrise/pl/design-patterns/qanda.html 4/9
13/3/2018 Design Patterns - Exercises
different types of presents, but they all match the age range.

What design pattern or patterns are evident in this scene?

Ans. The boxes represent two design patterns: Factory Method and Abstract Factory. The boxes
with age ranges represent the Abstract Factory class because each product is related to a family
of products. The box with a single label represents the the Factory Method design pattern.

24. In keeping with the holiday theme, use the Decorator design pattern to model a Christmas tree as
a base component (the tree) and optional decorations or adornments such as bulbs, candy and
garland. Initially it's enough for your solution to model just the printing or display of the tree along with
its adornments. You can also assume that each type of decoration is added all at once.

Show the class diagram for your solution and the runtime organization of objects for different configurations of adornments.

Ans.  

Give the above design, you would create and display different tree arrangements like:

Ornament o = new Bubs ( new Garland ( new Tree()));

o.show();

Ornament o = new Garland ( new Bubs ( new Candy ( new Tree())));

o.show();

Give the statements above, the runtime configuration would be:

http://sce2.umkc.edu/BIT/burrise/pl/design-patterns/qanda.html 5/9
13/3/2018 Design Patterns - Exercises

25. Which component in the MVC triad is the most reusable?

Ans. Probably the model. The model had methods for changing its state, for querying its state and for notifying listeners when the state changes. If
the model isn't pushing changes to listeners there is very little coupling between the model and the view and the model and the controller. The next
most reusable component is probably a view that doesn't allow input. It is less reusable because it either relies on the model pushing data to it or an
interface on the model for retrieving data for display.

26. Is the separate model architecture used with AWT components? In other words are AWT components backed by a separate model?

Ans. No, no. Swing components are implemented in the native operating system.

27. Every Swing component has a default model which can be replace with a model created and managed within the application. Replacing the default model
with one managed in the application is advantages only for a few components. Explain why and list the components that might benefit from an application­level
model.

Ans. It's only advantageous for data­rich components. Using an application­level data structure as a component model reduces the amount of
redundant data that has to be maintained. When the default model is used the data for the model is represented in the application but also has to
be added and removed from the component as the internal data structure changes. If the internal data structure is used as the model the data only
has to be stored in one place. There is a certain amount of overhead to converting an internal data structure into a component model so doing so is
only advantageous for components with lots of data. The benefits of avoiding data redundancy should be greater than the cost of making an
internal data structure a model. The benefits are greater when more data is involved.

28. Design patterns, architecture styles and frameworks are all very similar. How do each of these techniques compare in terms of the type of reuse they
enable?

Ans. Design patterns enable design reuse. Architecture styles enable architecture reuse and frameworks enable architecture and application logic
reuse.

29. The programming idiom given for simulating enumerated types doesn't provide all the features of an enumerated type. Specifically, the suggested
programming idiom doesn't support type checking and has no restriction on the range of values that can be assigned to a simulated enumerated type variable.
For example, in the following program the value 4 is assigned to the variable color which is outside the types intended for the simulated enumerated type.

interface Colors {
    public static final int RED = 0;
    public static final int GREEN = 1;
    public static final int BLUE = 2;
}

public class test implements Colors {

    public static void main(String args[]) {
        int color = RED;
        color = 4; // Danger! No type checking
    }
}

Suggestion another idiom for simulating enumerated type in Java that is type safe and limits the range of values that can be assigned to a simulated
enumeration variable. (Hint: object identity.)

Ans. The following solution uses object identity to achieve type checking and limit allowable values.

class Color {
    private Color(){}
    public static final Color RED = new Color();
    public static final Color GREEN = new Color();
    public static final Color BLUE = new Color();
}

public class test {

    public static void main(String args[]) {
        Color color = Color.RED;
        switch (color) { // Error. Color isn't an integral type

http://sce2.umkc.edu/BIT/burrise/pl/design-patterns/qanda.html 6/9
13/3/2018 Design Patterns - Exercises
            . . .
        }
    }
}

The above solution provides type checking and limits the range of allowable values but at the expense of ordering. One consequence is simulated
enumerated variables of type Color can't be used in switch statements. There are other more complex Java programming idioms that provide all
three: ordering, type checking and value range limits.

30. Could the model­view­controller design pattern also be considered a 3­tier architecture style? Can it be considered a 3­layered architecture style?

Ans. No to both. It's not a 3­tier architecture because the there components (model, view, controller) aren't "lateral" components. They don't pass
data back and forth between source and sink. It's not a 3­layered architecture style because the components don't represent layers of abstraction.
The three components in the model­view­controller design pattern are "peer" components.

You could make the argument that the model­view­controller design pattern should really be considered an architecture style because it permeates
the UI logic of an application. In other words, it's too encompassing to be considered a design pattern.

31. If you write a program that includes an efficient novel solution to a common design problem, can you declare it a design pattern without applying the
solution to other programming problems?

Ans. No. What's missing is experience with the pattern in different contexts. Efficient novel solutions to design problems can't be declared design
patterns until they have been applied to different programming problems. A design pattern is a solution to a design problem but must also include
the consequences and trade­offs in using the pattern in possibly different ways.

32. Does use of the Singleton design pattern create a glorified global? How does use of the Singleton design pattern compare and contrast with the use of
global variables?

Ans. Both are available globally, but so are all public class definitions. Creation of an instance of a singleton class is controlled by the singleton
class. All access to a singleton object are controlled by methods on the singleton class. Clients of a global variable have uncontrolled access to the
value of the variable. They can read and write values directly.

33. Explain how the Model­View­Controller design pattern can be considered a programming idiom, a design pattern or an architecture style?

Ans. When using the specific version of MVC provided by the Smalltalk programming language, it can be considered an idiom because it is
language specific. When used to design the UI of a larger program with large complex models with their own design, it would be considered a
design pattern because the GUI is a small part of the overall software system. When used as the principle means of returning dynamic web pages it
can be considered an architecture style because it represents the organization of the whole system.

34. (T/F) The Facade design pattern encapsulates the classes that define the interfaces that it simplifies.

Ans. False. The Facade design pattern is not about encapsulation. The classes that define the interfaces that the Facade design pattern simplifies are
available for direct use. The Facade design pattern reduces coupling with encapsulating. It reduces coupling because clients are dependent on a more
complex interface. It doesn't encapsulate because clients aren't prevented from accessing the more complex interface.

Q. The Java API includes a class called WindowAdapter with the following implementation. (Note, the implementation isn't elided in the code below, the
methods are defined, but actually have zero statements.)

public abstract class WindowAdapter implements WindowListener {

  public void windowOpened(WindowEvent e) {}
  public void windowClosing(WindowEvent e) {}
  public void windowClosed(WindowEvent e) {}
  public void windowIconified(WindowEvent e) {}
  public void windowDeiconified(WindowEvent e) {}
  public void windowActivated(WindowEvent e) {}
  public void windowDeactivated(WindowEvent e) {}
}

Is WindowAdapter an example or instance of the adapter design pattern?

Ans. No. The term adapter is also used in the Java API to refer to a convenience class that provides empty implementation for all the methods of an
interface. These convenience classes are useful when you want to implement an interface but are interested in only a few methods of the interface.
Rather than implement the interface and write a bunch of empty methods, you can extend the interface's adapter class and override only the methods
you are interested in.

xx. Aggregate types in the first version of the Java programming language returned an iterator of type Enumeration. Client code wanting to process the
elements of any aggregate accepted a parameter of type Enumeration.

public void processElements(Enumeration e) {

    . . .
}

interface Enumeration {
}

Version 1.2 of the language added new aggregate types such as LinkedList and a new type of iteration called Iterator. These new aggregate types only
supported the newer form of iteration.

class LinkedList {
    public Iterator iterator();
    . . .
}

interface Iterator {
}

http://sce2.umkc.edu/BIT/burrise/pl/design-patterns/qanda.html 7/9
13/3/2018 Design Patterns - Exercises
Old code expecting an iterator of type Enumeration is incompatible with newer aggregates such as LinkedList. To remedy this, write an adapter class
IterationAdapter that will convert iterators of type Iterator to work with code expecting an iterator of type Enumeration. Here is some sample code using the
adapter that should help clarify what is expected:

 
import java.util.*;

public class AdapterExample {

     public static void main(String[] args) {

        LinkedList container = new LinkedList();
        container.add(new Integer(1));
        container.add(new Integer(2));

        Iterator iterator = container.iterator();

        IterationAdapter iterationAdapter = new IterationAdapter(iterator);

       client(iterationAdapter);
    }

     // This client only understands the older

    // interface Enumeration
    public static void client(Enumeration e) {
        while (e.hasMoreElements()) {
            System.out.println(e.nextElement());
        }
    }
}

// Implement this class:

class IterationAdapter . . .

Version 1.2 of the language added a complete collection framework.   A collection framework defines abstract interfaces, specific classes that implement the
abstract interfaces, and algorithms written to these abstract interfaces..

Ans. Adapter Pattern. If the interface changes, your changes will be confined to the class acting as an adapter for the actual interface.

35. You are working on software that interacts with a new hardware device and are anxious to test against the actual hardware. The hardware manufacture has
a beta version of the driver they plan to release but is warning the interface of the device driver could change between now and the release date. The device
driver is used throughout your code and you are concerned about writing code to an interface that is subject to change. What design pattern can be used to
mitigate the risks involved? Describe what the risks are and how the design pattern mitigates these risks.

Ans. Adapter Pattern. If the interface changes, your changes will be confined to the class acting as an adapter for the actual interface.

36. Which design pattern does the best at upholding the principle of favoring composition over inheritance? Which does the worst? (TBD add some examples:
Delegation, Factory Method)

Ans. Best: Adapter class style. Worst: Factory method, Adapter object style.

37. Assume you have an existing class Observer that contains the behavior needed to make classes observable in the style of the Observer design pattern.

class Observer {
 
   public attachObserver(Observer o);
   public detachObserver(Observer o); 
   public notifyObservers();  
}  

There is another class S that you want to make Observable, but S already extends class A.
class S extends A {  
   . . .  
}  

The language you are using doesn't support multiple inheritance so the class S can't extend both Observer and A. Show how you can use composition and
delegation to reuse features of class Observer in order to make S observable.

38. A photon is a quantum of light. Photons exhibit properties of both waves and particles. Would the State design pattern be appropriate for modeling the
behavior of a photon?

 Ans. No. Photons exhibit properties waves and particles simultaneously. The State design pattern is is for constructs with mutually exclusive states.

39. The following before and after code fragments were used to introduce the Factory Method pattern. In the after fragment, a new interface, CCPService, was
created. Lines 26­28 mention that the source code to FinancialTrustCCP was modified to implement the abstract interface CCPService. If FinancialTrustCCP
was a third party service, it would be unlikely you would have the chance to make changes or request changes be made to the source code. If it was
impossible to make changes to FinancialTrustCCP, what well­known design pattern could be used to allow FinancialTrustCCP to be used in the new design
without making any code changes to it? Justify your answer.

Before:

http://sce2.umkc.edu/BIT/burrise/pl/design-patterns/qanda.html 8/9
13/3/2018 Design Patterns - Exercises

After:

 Ans. Adapter. The adapter class would wrap FinancialTrustCCP and implement the interface CCPService. The adapter class would have a method
post() that would delegate to the post() method of FinancialTrustCCP.

39. Explain how the open/close principle applies to the Observer design pattern.

 Ans. The pattern is open for extension but closed for modification because you can add a new observer without modifying the subject or other
observers.

 39. (True / False) The Façade design pattern introduces a new interface..

 Ans. T

39. (True / False) The Façade design pattern introduces new functionality.

 Ans. F

39. (True / False) When a Façade object is used with a subsystem, the subsystem is aware of the façade object.

 Ans. False. There is no reason for the subsystem to know about the facade object. The facade object simply delegates requests to the subsystem. It is a
one­way relationship.

http://sce2.umkc.edu/BIT/burrise/pl/design-patterns/qanda.html 9/9