Weekly Outcomes

This is an old version of this course, from Winter 2016-2017. A newer version is available here.

Acknowldgement

The outcomes for this class were taken from Dr. Mark Hornick's previous rendition of the class.

Modifications will be made throughout the quarter, with changes usually highlighted.

Optional goodies

Enterprise Architect

• How to install Enterprise Architect 11. (Including the license key.) You must be logged in to the Hub to see this.
• To edit an item, press F2
• To add attributes or operations to a class without opening the dialog, use Ctrl-Shift-F9 (or F10). To open the dialog, just press F9 or F10.
• To insert a new attribute or operation after a selected one, you will need to bind the "Element" Category command "Insert New After Selected. Instructions for doing this are at the sparxsystems website. (I mapped mine to Ctrl-F10, which was unnassigned.)
• To make parameter names visible in Enterprise Architect, use menu Diagram → Properties, (Or right-click on the diagram background and select properties) go to the Features tab, look for the parameters drop-down Show Parameter Detail and select Full Details (source)

Week 1

Strategy Pattern

• Write a method necessary to implement the Strategy pattern
• Re-write a UML diagram to apply the Strategy pattern to a new problem

Design Goals

• Describe how a given pattern favors composition over inheritance
• Modify code to favor encapsulation over extension
• Describe how a pattern programs to an interface
• Modify code to program to an interface
• Explain and apply the paradigm of "Program to an Interface". This principle can also apply to programming to an Abstract Class for cases where Abstract Classes are used instead of Interfaces.
• Explain and Demonstrate Programming to an Interface (or abstraction)
• Compare and contrast cohesion and coupling
• Describe how a given application exhibits cohesion or coupling

Factory Method Pattern

• Describe the goals of the Factory Method Pattern
• Describe how the Factory Method Pattern accomplishes its goal
• Compare and contrast the Factory Method Pattern with the Simple Factory Idiom
• Re-write a UML diagram to apply the Factory Method Pattern to a new problem
• Write a method necessary to implement the Factory Method Pattern
• Compare and contrast the Strategy Pattern and Factory Method Pattern.
• Given an application of one of the patterns covered so far (Strategy, Factory), provide its name.

Threading

• Analyze code to determine whether it is thread-safe
• Describe three ways to create secondary threads in Java
• Modify code to make it thread-safe
• Describe the purpose of a Java monitor
• Describe the monitor used for synchronized methods (both instance and static) and statements
• Describe the steps taken when synchronize statements are entered or exited, or notify, wait, or join is called.
• Write code to create and start a thread
• Translate synchronized methods to synchronized statements
• Write code using synchronized methods and statements
• Describe the function of the thread methods notify and wait
• Write or correct code using notify and wait
• Describe the cost of synchronization
• Describe the three ways to create new threads in Java
• Write code to create a new thread or timer and execute it
• Explain and apply the SwingUtilities.invokeLater() method to invoke a method on the UI dispatch thread of a Swing GUI application

• Explain the context, intent, and motivation of the Singleton Pattern
• Explain the concept of Eager vs. Lazy initialization of the Singleton's object
• Describe the specific consequences (advantages/disadvantages) of the Singleton Pattern
• List the principal methods of each main Singleton class
• Explain how a Singleton instance is created in the absence of a Singleton constructor
• Implement the principal methods of the main classes
• Describe why and how static context is used in the Singleton implementation
• Identify candidate applications that could implement the Singleton pattern
• Apply the Singleton pattern to a specified application
• Explain the performance issues associated with declaring a Singleton's getInstance() method synchronized, and how double-checked locking is used to overcome this problem.
• Describe errors in double-locked implementations
• Explain why the volatile keyword is needed in a double-locked implementation.

Week 4-b

• Explain the advantage, in the Observer pattern, of allowing multiple observers of the same subject.
• Explain the context, intent, and motivation of the Observer Pattern
• Explain why the Observer pattern is useful when programming as a team.
• State the two principal interfaces comprising the Observer Pattern
• List the principal methods defined by the Observer and Subject interfaces
• Implement the principal methods of the each interface in concrete classes
• Explain the concept of Push vs. Pull with respect to how an Observer acquires an update from a Subject
• Describe the specific consequences (advantages/disadvantages) of the Observer Pattern
• Identify candidate applications that could implement the Observer pattern
• Apply the Observer pattern to a specified application
• Explain the concept of coupling between classes, and the motivation for minimizing coupling
• Explain the general concept of I/O streams and their purpose
• Apply File-based I/O streams to reading and writing Files
• Explain the concept of piped I/O streams and their purpose.
• Apply piped I/O streams to exchanging data between synchronized threads
• Explain the concept of Socket-based I/O streams
• Apply socket-based I/O streams to exchanging data between processes on the same computer as well as between processes distributed among networked computers.

Week 6

• Explain the context, intent, and motivation of the Decorator Pattern
• List the principal attribute defined within the abstract class that defines an Abstract Decorator which concrete Decorates extend
• Explain and apply the paradigm of the Favor Composition over Extend principle with respect to the Decorator Pattern.
• Describe how the Decorator Pattern is applied in the java.io package to various Java I/O classes, such as OutputStream, FileOutputStream, FilterOutputStream, along with the corresponding InputStream-related classes
• Apply the Decorator pattern to implement a FilterOutputStream-based or FilterInputStream-based I/O concrete Decorator class that manipulates the data within an output or input stream.
• Apply the Decorator pattern to extend the behavior of graphical shapes.
• Identify and make use of appropriate connectors in UML class diagrams that illustrate generalization (Java extends), realization (Java implements), composition, and usage, along with labeling connectors to indicate navigability (arrows), multiplicity (numbers), and end roles (attribute names)

Week 7

• Describe how the Composite Pattern is applied to create hierarchical structures composed of nodes known as Parts (or Leaf's) and Composites, which both implement the behavior defined by the abstract Component class.
• Explain how the Composite Pattern allows all objects (Parts and Composites) of a hierarchy to be treated uniformly, since they both implement Component behavior.
• Identify the principal behaviors defined by the Component abstraction.
• Illustrate the relationships between the primary classes of the Composite Pattern.
• Apply the Composite pattern to create hierarchies of objects such as computer components and subsystems.
• Apply the Composite pattern to create hierarchies of graphical shapes.
• Explain how the ability for a client application to treat all elements of a Composite Pattern uniformly (also known as transparency) violates the Cohesion Principle, since the Component abstraction defines both Part (Leaf) and Composite behavior, and also weakens Type Safety.

Week 8

• Explain the purpose of each element of the Command Pattern's structure
• Refactor code to decrease coupling, using the Command Pattern
• Implement undo with the command pattern
• See commands as closures -- a method with associated data
• List potential applications of the Command pattern in practice.
• Implement the command pattern with Lambda expressions instead of classes
• (possibly) Describe why the command pattern CANNOT be implemented with lambda expressions if you want undo functionality
• Identify key situations where you would want to apply the Command pattern
• Select the Command pattern among other patterns when it is appropriate for a design.
• Describe how the Command Pattern represents a request to an object (that is, a command) as another type of object, which can be stored and passed around like any other object.
• Identify the primary classes of the Command Pattern: the Command interface, one or more concrete Commands which implement the interface, a command Invoker, and a context-specific Receiver.
• Identify the principal behaviors defined by the Command interface and the Invoker abstraction.
• Illustrate the relationships between the primary elements of the Command Pattern in a UML class diagram.
• Explain how the Invoker may "buffer" concrete Command object references in a Stack or other data structure for purposes such as deferred execution, or supporting "undo".

Week 9

• Describe why, if A happens-before B, A may not actually happen before B at runtime.
• Describe why, if A actually happens before B at runtime, A may not happen-before B.
• Determine if two events have a chain of happens-before relationships between them
• Apply the same-thread, synchronize-block, and volatile read-write happens-before rules.
• Define "conflicting statements" as in the Java language specification.
• Describe when two conflicting statements have a data race
• Determine if a short program has race conditions or not, and describe where those race conditions occur.

Week 10

• Describe how the Facade Pattern simplifies the interface to complex system of classes by providing a centralized interface to clients of the subsystem.

More Cut Questions

(Beyond this point, no objectives covered this year.)

Week 5

• Explain the context, intent, and motivation of the Proxy Pattern
• Define the function of each of the following proxies: Stub Proxy, Virtual Proxy, Remote Proxy
• Describe the contexts in which the Stub Proxy, Virtual Proxy, and Remote Proxy patterns apply
• Apply Socket-based I/O streams to implement the Remote Proxy Pattern in a distributed client-server application
• Implement Java code that creates a server-side TCP socket.
• Implement Java code that creates a client-side socket that connects to a server-side socket.
• Implement sending and receiving data between a Remote Proxy and Real Subject using socket I/O.
• Implement serialization of an object using socket I/O.

Week 9

• Describe how the Visitor Pattern encapsulates algorithms that need to be performed on an object (or more than one object) as objects known as Visitors.
• Apply the Visitor pattern to computing various metrics to a hierarchical structure of components (which implement the Composite Pattern).
• Describe the principal behavior defined by the Visitor interface as object visitation, which requires the object to implement a method that allows it to accept a Visitor.
• Explain how implementing the Visitor pattern breaks the principle of "Extend, don't Modify" by requiring modification to classes that will support being visited (since the acceptVisitor() method must be implemented in such classes).
• Explain how encapsulation may be compromised on classes that support Visitors, since those classes may have to provide sufficient access (via public methods or public attributes) for a Visitor to perform its intended function.
• Explain how a the problem above may be reduced by having a class that permits Visitors to visit it may instead provide access via a nested inner class that is only provided to Visitors.
• Illustrate the relationships between the primary elements of the Visitor Pattern in a UML class diagram.
   
• Describe how the Iterator Pattern hides the internal structure of a complex hierarchy from a client by providing a mechanism (the iterator) which can traverse the hierarchy and deliver the constituent objects to the client.
   
• Describe how the Builder Pattern is used to encapsulate the construction of complex objects from the actual representation of the complex objects.
• Explain how the Builder Pattern separates the construction of an object from its representation.
• Identify the primary classes of the Builder Pattern: the Builder interface, one or more concrete Builder which implement the interface, and a one or more Directors that execute methods of one or more concrete Builders to build variants of one or more complex objects.
• Explain how the Builder Pattern isolates the details of construction of complex object from the client application, and promotes loose coupling between the client application code and the objects being constructed.
• Explain how different Directors can use the same concrete Builder to create variations of the complex object.
• Explain how the Director and Builder classes are tightly-coupled, since the Director needs to know how to use the Builders.
• Identify the principal behaviors defined by the Builder interface and the Director abstraction.
• Illustrate the relationships between the primary elements of the Builder Pattern in a UML class diagram.
   

Week 10

• Describe the principal behavior defined by the Facade interface as context-specific, which depends on the behaviors being presented to the client.
• Illustrate the relationships between the primary elements of the Facade Pattern in a UML class diagram.
• Explain how the Facade Pattern allows the the internal classes to change freely, since the client only "sees" the facade interface.
• Explain how the Facade Pattern supports the Principle of Least Knowledge in order to promote loose coupling
   
• Describe how the Adapter Pattern translates the interface to a given class to appear such that it appears to be the interface of another class.
• Illustrate the relationships between the primary elements of the Adapter Pattern in a UML class diagram.
• Explain how the Adapter Pattern provides a way to avoid changes to the legacy code of a client application by providing a transparent means for a client to adapt to a new set of dependent classes.