Weekly Outcomes

This is an old version of this course, from Winter 2013-2014. A newer version is avaliable 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.

Week 1

• Define the meaning of the term Design Pattern.
• State the motivation behind Design Patterns.
• State the three primary classifications of Patterns, and explain them.
• Explain when it makes sense to provide some implementation in an abstract class, even though the class is not instantiable
• Explain when use of an abstract class may be more favorable than use of a pure interface
• Explain how the Strategy pattern delegates behaviors to separate classes.

Week 2

• Explain the meaning of the term coupling; explain low (loose) coupling vs. high (tight) coupling
• Explain the meaning of cohesion; explain low cohesion vs. high cohesion
• Explain why low coupling and high cohesion are characteristics of a good design
• Explain the principle of Extend, don't Modify (also called the Open-Closed Principle)
   
• Describe how the Factory Pattern is used to define an interface for object creation in that is implemented in a Factory class - the interface consists of methods known as Factory Methods.
• Describe the principal behavior defined by the Factory pattern as object creation.
• Explain that object creation cannot be effectively be implemented in the constructor method of an abstract Factory class, since constructors cannot be overridden in concrete subclasses.
• Explain how the Factory Pattern forces concrete Factory classes to implement Factory Methods by overriding the Factory Methods declared in the abstract Factory class
• Explain how the Factory Pattern delegates the creation of objects to the concrete Factory subclasses of the abstract Factory class..
• Identify the primary classes of the Factory Pattern: the abstract Factory class (or interface), and one or more concrete Factories which implement the Factory Methods.
• Illustrate the relationships between the primary elements of the Factory Pattern in a UML class diagram.
• Describe how the Abstract Factory Pattern method is used to create different types of concrete Factories, thus abstracting the process of creating the Factories.
• Illustrate the relationships between the primary elements of the Abstract Factory Pattern in a UML class diagram.
• Explain how the Abstract Factory Pattern supports the Dependency Inversion Principle, wherein a client application depends on (high-level) abstractions (abstract classes and interfaces) rather than (low-level) concrete components, but also that low-level components depend on behaviors defined within high-level abstractions
• (optional) Describe the subtle differences between the Simple Factory programming Idiom and the Factory Method Pattern (Tech article)

Week 3

• Explain the meaning of a Thread and its purpose.
• Apply multithreading using the Java API to create and run multiple Threads
• Apply Anonymous Inner Classes to the creation of Threads
• Explain the purpose of the Runnable interface and its association with Thread creation
• Explain the purpose of Thread synchronization.
• Create synchronized methods and synchronized blocks of code.
• Synchronize Threads using notify() and wait() methods from the Java API.
• Explain the concept of thread-safety as to how it pertains to non-thread-safe classes such as those of the JCF.

• 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
• 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.

Week 4-b

• Explain the context, intent, and motivation of the Observer Pattern
• 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 and apply the SwingUtilities.invokeLater() method to invoke a method on the UI dispatch thread of a Swing GUI application
• Explain the concept of coupling between classes, and the motivation for minimizing coupling
• 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)
• 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 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.
• 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.

Week 6

• 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

• 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 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 how the Facade Pattern simplifies the interface to complex system of classes by providing a centralized interface to clients of the subsystem.
• 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.