Designing with Patterns — Decorator, Command, Proxy, Strategy, and Factory

# Designing with Patterns — Decorator, Command, Proxy, Strategy, and Factory

14.1 Good Design, Pattern Granularity, and Adapter Recap

14.1.1 Why Patterns and What Counts as Good Design

Design for object-oriented systems aims to standardize how a system is built so that design choices become repeatable and reviewable. A natural opening question is how to say a design is good and whether we can set criteria for that judgment. Patterns help answer it. They capture proven arrangements of classes and objects that improve cohesion — how focused a class is on one job — , low coupling — how little classes depend on each other's internals — , reuse, and clarity, and they give a shared vocabulary for discussing alternatives in any design problem.

Visual intuition: imagine two axes. The horizontal axis is granularity from "single statement" on the left to "whole application architecture" on the right. The vertical axis is reuse frequency. Idioms sit low-left, patterns sit in the middle-high hump — used in almost every project but never as a whole system — and frameworks sit far right. The takeaway: you will reach for patterns daily, but you will never build a system that is just one pattern.

Real-world and domain connection: In the NextGen POS case study developed throughout the course, tax calculators, credit authorization, inventory and accounting are all external services with incompatible APIs. The team does not write four different sales logics; they apply Adapter to present one stable ITaxCalculatorAdapter interface and Factory plus Singleton to create it. The domain benefit is immediate: the POS can switch from TaxMaster to GoodAsGoldTaxPro by changing a property file, with zero edits to Sale or Register. The same separation-of-concepts reasoning applies in any product line that must plug in external vendors.

14.1.2 Adapter Recap — Identifying the Need

Participants in words: Target is the interface the client depends on — for example ICan in the lecture's shorthand or ITaxCalculatorAdapter with getTaxes(Sale). Adaptee is the existing class with the useful behavior but the wrong interface — for example GoodAsGoldTaxPro or the external SAPSystem via SOAP over HTTPS. Adapter implements Target and forwards targetMethod() to adaptee.adapteeMethod() with argument and return translation. The client only sees Target.

Real-world anchor: power adapters convert one kind of plug and socket into another so an otherwise usable device can connect. The same idea holds in code: the source interface and the target interface needed by the client do not match, yet the underlying context and functionality are the same. The conversion is purely interfacial — no change to original functionality. The adapter converts from target to source by translating calls, adapting one interface to the required target interface while leaving the adaptee unchanged.

The problem description that points to Adapter therefore mentions an existing class whose behavior is exactly what is needed, but whose method names or signatures are incompatible with what the client expects. The solution is an intermediate converter that forwards target calls to the adaptee. A concrete illustration used last time involved an interface called ICan that needed to be used through a target container interface. The adapter translates every method of the target container interface into a call on the ICan interface.

Visual intuition: draw two rectangles, left is Target socket with three pins, right is Adaptee plug with two flat blades. The Adapter sits between them. Its left face has three holes, its right face has two slots, and inside there are three wires that re-route to the two slots plus a small transformer. Both axes are interface shape versus function: shape differs, function is preserved, and the takeaway is that only the shape changes.

14.1.3 Student Questions and Answers

14.2 Decorator Pattern — Adding Visual and Behavioral Enhancement Without Changing Core Behavior

14.2.1 Intent and Problem Context

The decorator answers the problem of adding functionality to many kinds of components without editing each component class. A common motivating example is scroll bars. Whenever a component becomes larger than the screen, horizontal and vertical scroll bars are needed. The same need appears for text areas, buttons, panels, and other widgets.

One naive solution is to add scroll bar logic inside every component class — a text area with scrolling, a button with scrolling, and so on. That approach duplicates code and forces a change to every class whenever a new kind of decoration is required, violating the Open-Closed Principle. A better solution keeps the core component unchanged and adds enhancements around it. Enhancement or addition of functionality while the basic functionality stays the same is called decoration. Responsibility for decoration is kept outside the component so the component stays closed for modification yet open for extension.

Real-world: the Java Swing library uses this pattern heavily. A GUI application built with Swing contains many decorators. The class JScrollPane decorates a component such as a JTextArea, a JButton, or any JComponent. After decoration, the result must still behave as a component so it can be placed in containers and treated uniformly. That is the central test the professor repeats: after decoration the object still behaves as a component.

14.2.2 Structure, Participants, and How Decoration Combines

Pseudocode that captures the forwarding idiom:

abstract class Decorator implements Component {
    protected Component wrapped;
    Decorator(Component c) { this.wrapped = c; }
    void operation() { wrapped.operation(); // then add decoration }
}
class JScrollPaneDecorator extends Decorator {
    void paint(Graphics g) {
        wrapped.paint(g);          // 1. render core text
        paintScrollBars(g);         // 2. add scroll decoration
        clipToViewport(g);
    }
}

Because both the component and the decorator share the same abstraction, decorating produces another component. That property allows any number of decorations to be stacked. You can start with a text area, wrap it in a scroll pane, then add a border, a color tint, a shadow, or any other visual or behavioral enhancement. Each new decorator wraps the previous result, and the outermost object still responds as a component. This supports an open-ended set of possible decorations that are not known when the component class is written. The Java Swing idiom new JScrollPane(myTextArea) is exactly this: the pane's constructor takes a JComponent and, because JComponent itself is a Container, it can add the wrapped component to itself and forward all GUI method calls.

The companion text shows the chaining explicitly: jp.add(new SlashDecorator(new CoolDecorator(new JButton("Dbutton")))); — a button decorated first as a cool-button that erases borders until mouse-over, then with a red diagonal line. Each layer intercepts paint and setBounds, saves state, calls super.paint(g), then draws its own embellishment. The setBounds interception matters because a decorator must remember the extent of the object it decorates.

Visual intuition: draw a set of concentric rectangles. Innermost is JTextArea with text. Next ring is JScrollPane adding vertical and horizontal bars on the right and bottom edges. Next ring is BorderDecorator adding a 2-pixel line border plus 4-pixel empty inset. The x-axis is nesting depth, the y-axis is visual responsibility added. The shape is additive stairs — each ring adds one feature without changing the inner rectangle's identity. The takeaway: transparency — the outermost ring still presents the Component interface, so any client expecting a Component cannot tell how many layers are inside.

14.2.3 Decorator Versus Composite — Same Diagram, Different Intent

One-sentence rule: if the description says "compose objects into tree structures" choose Composite; if it says "add scrolling/border/color to any component and still use it as a component" choose Decorator.

14.2.4 Worked Examples

Visual note on Example 2: if you screenshot before and after mouse hover, the left image shows a flat gray button with no border and a red slash, the right shows the same button with a raised border when mouse_over == true. The visual takeaway is that decoration is stateful — the same wrapped object looks different based on the decorator's mouse_over flag — while identity as JComponent never changes.

14.2.5 Student Questions and Answers

14.2.6 Professor Intuition and Analogies

The professor's Diwali-house image carries the entire abstract idea: enhancement without identity loss. Extend it: the electrical wiring is the paint() contract — unchanged after decoration; the decorative lights are added paintScrollBars() — visible only when the house (Component) is viewed. Where the analogy breaks — as already mapped — is that physical lights can be added without touching the walls, but a Decorator must intercept paint and forward; if forwarding is forgotten, decoration replaces rather than augments, which is a classic bug.

Another intuition offered is the usage test: check whether the object must remain usable exactly as before, with only added effects; if so, the structure of holding a reference and forwarding plus augmentation is the right mental model. Repetition in the lecture that enhancement should not change usage is an emphasis signal — exam questions often test whether the decorator's result can again be used as a component. A one-line answer template: "After decoration the object is still a Component; JScrollPane can be added to a Container where a JComponent was expected."

14.2.7 Industry Applications

Real-world: JScrollPane decorating JTextArea and other Swing components, JComponent as the component abstraction in Swing, and GUI toolkits where borders, scroll bars, and shadows are pluggable decorators. Beyond Swing, java.io.FilterInputStream family — BufferedInputStream, CheckedInputStream, DataInputStream, PushbackInputStream — is the textbook non-visual decorator chain. The broader practice is to keep component classes stable while providing a library of decorators for visual and behavioral enhancements, avoiding subclass explosion. For example, without Decorator, supporting 4 components times 5 decorations would require 20 subclasses; with Decorator it requires 4 + 5 classes and unlimited run-time combinations.

14.2.8 Exam Notes

14.3 Command Pattern — Turning Requests into Objects that Carry State and Behavior

14.3.1 Intent and Why Commands Are Objects

The command pattern treats a request as an object so that the request can carry both behavior — what to do — and state — whether it is enabled, what its icon is, and what its history is. In an object-oriented system, commands are not bare functions. They maintain state information together with the operation they perform. This is the decisive idea the lecture repeats: a Command is state plus behavior bundled as an object, not a callback.

A familiar illustration is an editor such as Microsoft Word with cut, copy, and paste. Paste is enabled only after cut or copy has placed something on the clipboard; otherwise it is disabled. The enable or disable state is not a property of the menu item alone but of the command's situation relative to other commands. Similarly, undo and redo operate over a history. The system maintains a list of previously executed commands so it can reverse a series of actions. Collecting commands as objects makes that history possible — a bare function pointer cannot remember which receiver and parameters were used last Tuesday.

Visual intuition: picture three layers left to right. Left: Invoker — JButton/JMenuItem with an Action. Middle: Command object with two compartments — top holds execute() arrow to the right, bottom holds a state dashboard with enabled: boolean, icon: Image, name: String. Right: Receiver — Document, Clipboard, Panel. The invoker's arrow points only to the command's execute(); the command's arrow points to the receiver's cut()/paste(). The takeaway: the invoker never sees the receiver; state sits on the slip, not on the button.

14.3.2 Structure, Participants, and Java Mapping

In Java Swing GUI programming, the same idea appears as the Action interface and ActionListener mechanism. Buttons and menu items are objects that wait for an action. An ActionListener is waiting for a particular action to happen; once a button is pressed, it becomes active and the action's behavior is executed. State methods such as isEnabled(), getEnabled(), setEnabled(), putValue(), getValue(), and removeProperty() let the framework query and change the enabled state, the icon, the name, and other properties of the action. There is an Action interface, an AbstractAction class that implements some of those methods, and a concrete class such as a greeting action that finally provides the specific behavior.

A demo example mentioned was a greeting command that produces Good Morning or Good Evening based on current timing, or a name-aware variant such as Good Morning, Mr. .... The pattern request is to learn how command execution is actually wired in Java — how execute() is triggered by the listener after the enabled check — by downloading and running small examples. The wiring is: AbstractAction stores a property map; JButton(Action a) copies a.getValue(NAME) and SMALL_ICON into the button model and registers an PropertyChangeListener so future a.putValue(...) updates the button automatically; on click, ButtonModel checks a.isEnabled() before firing actionPerformed.

Textbook note: an early simplification extends Button to also implement Command directly (class btnRedCommand extends Button implements Command), which eliminates the if-chain in actionPerformed, but the mature approach separates Command from Button via CommandHolder (setCommand/getCommand) so UI and action can vary independently — that separation is the true pattern.

14.3.3 Worked Examples

class GreetingAction extends AbstractAction {
    GreetingAction(String name) {
        super(name);
        putValue(NAME, "Greet");
        putValue(SMALL_ICON, new ImageIcon("greet.png"));
    }
    void actionPerformed(ActionEvent e) {
        int hour = Calendar.getInstance().get(HOUR_OF_DAY);
        String msg = (hour < 12 ? "Good Morning" : "Good Evening")
                     + ", " + name;
        JOptionPane.showMessageDialog(null, msg);
    }
}
JButton btn = new JButton(new GreetingAction("Mr. Lee"));

14.3.4 Student Questions and Answers

14.3.5 Industry Applications

Real-world: editor commands cut, copy, paste, undo, redo in word processors, and any toolbar or menu where an item's enabled state follows application state. In Swing, javax.swing.Action, AbstractAction, ActionListener, and button models such as JButton realize the pattern for GUI commands — the same CutAction backs Ctrl+X, the Edit menu item, and the toolbar button, keeping isEnabled() consistent without triplicate code. Drawing programs where each stroke is a DrawCommand with unDo() that pops DrawData. The companion's Undo demo draws successive red or blue diagonal lines and undoes them in last-in-first-out order. Beyond GUIs, job-queue systems, macro recorders, and transactional systems use Command to queue, log, and replay requests.

14.3.6 Exam Notes

14.4 Proxy Pattern — Controlling Access and Deferring Cost While Preserving the Client View

14.4.1 Intent and Problem Context

A proxy is a person or object authorized to act on behalf of another. The core idea is that the client does not want to interact with the real object directly, or the real object is expensive to create, so the client works with a proxy. Only when the real need arises does the proxy bring the real object into play. The client gets the same feeling as if it were working with the real object. The pattern is described as magical because it changes creation or access behavior without changing the client's interface — the magic is that timing and cost disappear behind a familiar face.

Two classic motivations were emphasized. First, delaying instantiation. Creating an object immediately can be wasteful if it will not be used for a while. A proxy can wait for a particular amount of time, an action, or a focus event before creating or activating the real object. Second, deferring expensive resource use. Loading videos or high-resolution images for every element on a web page is costly, and many images will never be viewed. The design therefore loads an image only when the user reaches that location or clicks a tab. Other costs include remote connections. Calling remote methods through Remote Method Invocation eagerly would hold connections and resources; a proxy can defer that work until required. In all cases the modification must not affect the client or the real subject from the user's point of view — that transparency is the contract.

The companion text adds two more proxy intents that help you recognize the pattern in questions: access control — the proxy validates hasPermission(user) before forwarding — and copy-on-write — the proxy initially shares the original large object and only copies it when a mutation occurs. If the description says "check rights," "validate access," or "copy only when changed," that is also Proxy, not Decorator.

14.4.2 Structure, Participants, and Collaboration

Pseudocode for the core forwarding pattern:

interface Subject { void request(); }
class RealSubject implements Subject {
    RealSubject() { loadHeavyResource(); } // expensive
    void request() { // real work }
}
class Proxy implements Subject {
    RealSubject real; // null until needed
    String filename;
    Proxy(String f) { filename = f; }
    void request() {
        if (real == null) real = new RealSubject(filename); // lazy creation
        // or: if (!checkAccess()) throw...
        real.request(); // same interface, same result
    }
}
Subject s = new Proxy("elliott.jpg"); // client sees Subject
s.request(); // triggers creation only now

In the Java image-proxy idiom, Proxy extends JPanel and the shared interface is paint(Graphics) / paintIcon. The proxy creates a MediaTracker to monitor loading, spawns a monitor thread, and on first paint either draws a placeholder rectangle or the loaded image — the client JPanel code that adds image to the layout never branches on proxy versus real.

Visual intuition: draw a timeline left to right. At time zero, the client holds a tiny hollow rectangle labeled Proxy with a dotted line to a large solid rectangle labeled RealSubject that is still dashed — not created. First paintIcon call at t=1: the proxy rectangle shows a thin black outline with text "loading..." and spawns a thread arrow downward to the real rectangle that materializes gradually from dashed to solid. At t=2, the hollow rectangle now contains the solid image. The x-axis is time, y-axis is memory cost. The shape is a step function: cost stays near zero until first access, then jumps to real cost. Takeaway: Proxy flattens expensive startup cost and shifts it to first use, which matters when only a minority of objects are ever touched.

14.4.3 Worked Examples

14.4.4 Professor Intuition

Two everyday images anchor the idea: making a proxy attendance entry for a class, and using a network proxy to reach a remote resource. Both involve an authorized stand-in that acts so the requester does not need to reach the real entity immediately. The war-sleep image used while describing the modification — the proxy may wait or sleep before delegating — signals that proxies are about when and how the real work happens, not about changing what the work is. A useful self-check the professor implies: ask "if I removed the proxy, would the observable result change?" If the answer is no — only timing or cost changes — it is Proxy. If the result should look different — border added, color changed — it is Decorator.

14.4.5 Industry Applications

Real-world: lazy image and video loading on web pages — IntersectionObserver patterns and placeholder <img> that loads only when scrolled into view; tab content that loads only on click; Java Remote Method Invocation where a generated stub is the proxy; EJB connection-pool proxies; copy-on-write for large document objects where a second instance shares storage until modified. Any scenario where initialization is expensive and many objects may never be viewed benefits from a proxy that presents a lightweight placeholder icon backed by on-first-paint loading. The companion also mentions enterprise connection proxies where the proxy validates access permissions before forwarding — a protection proxy.

14.4.6 Exam Notes

14.5 Strategy Pattern — Encapsulating Interchangeable Algorithms

14.5.1 Intent and Problem Context

Strategy captures the idea that there can be different strategies — related algorithms — to solve the same problem, and the system should be able to change the algorithm that is in use. Each algorithm is placed in its own class so variants are isolated, and the client can choose among them without modifying the interface through which the work is requested. The pattern is about algorithms and their variation. Whenever an algorithm needs to be executed and we wish to vary its concrete steps while keeping the surrounding context stable, Strategy applies.

Common drivers include families such as encryption algorithms, compression algorithms, layout algorithms, file storage formats, and sorting orders. The need to add a new algorithm without editing existing clients, and the need for clients to supply custom versions that replace a standard algorithm, both point to this pattern. The lecture explicitly calls Strategy an algorithm-family pattern: you can "create objects without making a change in the interface" and "clients want to replace the standard algorithm with custom versions."

The companion motivation lists five canonical Strategy situations: saving files in different formats, compressing with different algorithms, capturing video with different codecs, breaking lines with different strategies, and plotting the same data as line graph versus bar chart. All share the same form: one job, many ways to do it, client should choose.

14.5.2 Structure, Participants, and Collaboration

Pseudocode:

interface Strategy { void doWork(Context c); }
class Context {
    Strategy strategy;
    void setStrategy(Strategy s) { strategy = s; }
    void request() { strategy.doWork(this); } // delegation, no if
}
Strategy s = new GridLayoutStrategy();
Context ctx = new Panel();
ctx.setStrategy(s);
ctx.request();

The companion Context example Context has setBarPlot() / setLinePlot() that assign plotStrategy = new BarPlotStrategy() versus LinePlotStrategy, and plot() { plotStrategy.plot(x,y); } — identical shape, different domain.

Visual intuition: picture the Context as a universal remote with one slot labeled Strategy. The x-axis is time or user choice, y-axis is algorithm cost or quality. At any moment the slot holds one cartridge — BorderLayout cartridge shows five zones, GridLayout shows uniform cells, BoxLayout shows a single column. The takeaway: the remote's buttons (layoutContainer) never change; only the cartridge does, so the interface is stable while behavior varies.

14.5.3 Worked Examples

Visual note on Example 1: sketch three panels side-by-side, each with the same six buttons labeled 1–6. Left with GridLayout shows two rows of three equal cells. Middle with BorderLayout shows 5 labeled zones with button 1 at North stretching full width. Right with BoxLayout shows a vertical stack centered. The takeaway: identical children, three computations of x,y,w,h, one stable Container interface.

14.5.4 Industry Applications

Real-world: Swing layout managers BorderLayout, GridLayout, BoxLayout as strategies for Container; collection framework comparators Comparator and Comparable as sorting strategies; file exporters, serializers, and archivers that vary format and algorithm; encryption and compression libraries where algorithm families are pluggable. In NextGen, pricing policies PercentDiscountPricingStrategy and AbsoluteDiscountOverThresholdPricingStrategy are textbook Strategy instances — each implements ISalePricingStrategy.getTotal(Sale) and the Sale delegates return pricingStrategy.getTotal(this). Any framework that allows clients to replace a standard algorithm with a custom implementation through a common interface without changing the caller's code is Strategy in action.

14.5.5 Exam Notes

14.6 Factory Patterns, Factory Method, and Iterator as a Factory Method

14.6.1 Limitations of Constructors and the Factory Idea

Knowledge of constructors asks first what a constructor does at least: it constructs an object and it has the same name as the class. Limitations follow from that form. A constructor is typically a public method that exposes how objects are created, ties creation to a single concrete class, cannot easily hide complex creation logic, cannot easily return a subtype chosen by parameters or cache results, and cannot easily vary the product family without editing client code. The talk listed three to four creational patterns that address these limits; factory and factory method are among the most popular, even though factory in its simplest form is not a classic Gang of Four member.

The factory idea is to create objects without exposing the instantiation logic to the client. The client interacts with an interface and passes parameters. The factory decides which concrete class to instantiate. Newly created objects are referred to through a common interface or common parent that declares shared methods; specific implementations differ. The factory is a pure fabrication object whose responsibility is to handle creation for a hierarchy of products. The underlying motive is separation of concerns and cohesion: when creation involves special considerations, complex branching, or choices about which subtype to return, that logic is moved into a cohesive helper object rather than spreading it across clients. That helper can also introduce performance management and resource control such as caching or recycling — the factory can return a cached instance instead of creating a new one without any client change.

14.6.2 Simple Factory — Parameter-Driven Creation

class NamerFactory {
  public Namer getNamer(String entry) {
    int i = entry.indexOf(",");
    if (i > 0) return new LastFirst(entry);
    else        return new FirstFirst(entry);
  }
}
class LastFirst extends Namer {
  LastFirst(String s){
    int i=s.indexOf(",");
    if(i>0){ last=s.substring(0,i).trim(); first=s.substring(i+1).trim();}
    else { last=s; first=""; }
  }
}
class FirstFirst extends Namer {
  FirstFirst(String s){
    int i=s.lastIndexOf(" ");
    if(i>0){ first=s.substring(0,i).trim(); last=s.substring(i+1).trim();}
    else { first=""; last=s; }
  }
}

interface Shape { void draw(); }
class ShapeFactory {
  Shape getShape(String type){
    if(type.equalsIgnoreCase("circle")) return new Circle();
    if(type.equalsIgnoreCase("rectangle")) return new Rectangle();
    if(type.equalsIgnoreCase("square")) return new Square();
    return null;
  }
}

14.6.3 Factory Method — Definition and Comparison with Constructor

14.6.4 Worked Examples Continued — Iterator as Factory Method

Iterator it = collection.iterator(); // factory method
while (it.hasNext()) {
    Element e = it.next();
    process(e);
}

Visual intuition: draw two parallel hierarchies. Left hierarchy is Creator: Collection at top with abstract iterator(), children LinkedList, DoublyLinkedList, PriorityQueue each with concrete iterator() arrow. Right hierarchy is Product: Iterator at top with hasNext/next, children ListIterator, HeapIterator. A dashed arrow from each creator child points to its product child, labeled "creates." The x-axis is creation timing, y-axis is abstraction level. Takeaway: each creator subclass knows which product subclass matches its internal representation, and the client sees only the two abstractions.

14.6.5 Student Questions and Answers

14.6.6 Industry Applications

Real-world: ShapeFactory that returns Circle, Rectangle, Square through a Shape interface; name factories that format names by locale or comma convention; honorific factories that produce Mr. versus Ms. objects; Swing creation helpers; any library where getInstance or create... hides branching or caching. The canonical platform example is Java collections and their iterators — List.iterator(), Set.iterator(), Queue.iterator() are the textbook factory method, and Java's Calendar.getInstance() / Toolkit.getImage() show simple factories. In NextGen POS, ServicesFactory and PricingStrategyFactory are singleton factories that read the concrete adapter or strategy class name from a system property and instantiate via reflection Class.forName(className).newInstance() — hiding concrete choice completely behind an interface and enabling zero-code swap.

14.6.7 Exam Notes

14.7 Toolkits, Templates, Frameworks, and How Patterns Fit Reuse

14.7.1 Toolkits Versus Frameworks Versus Patterns

Patterns, toolkits, templates, and frameworks all support reuse but at different levels and with opposite control flow. Keeping them distinct is a recurring exam requirement.

Toolkits are a collection of related and reusable classes, for example the C++ standard library or Java's java.util package with ArrayList, HashMap, Collections. They are called by the application; the application controls the flow and uses toolkit classes as needed — the application is the caller, the toolkit the callee. Toolkit classes are largely independent; you can use ArrayList without HashMap.

Templates in C++ are language-level generic mechanisms — template<typename T> class vector<T> — that generate type-safe classes or functions at compile time. The lecture explicitly warned not to confuse generic templates with the decorator pattern or other design patterns just because the name template appears in both contexts. The name collision is accidental. One is a compile-time type mechanism; the other is a run-time object structuring intent.

Frameworks are a set of cooperating classes designed for a particular kind of application such as compilers, graphical editors, business systems, or GUI applications. A framework implements the basic architecture and inverts control — the framework defines the main flow (event loop, validation loop, transaction loop) and calls application-supplied extensions at hook points. The developer adds application-specific operations, names, and state information and implements responsibilities and collaborations as the pattern prescribes, fitting into the framework's hooks. Real-world: compiler frameworks, GUI frameworks such as Swing's overall application structure (event dispatch thread, paint cycle, layout cycle), Eclipse or Spring as larger frameworks. The key sentence for exams: " framework calls you; you call a toolkit."

Patterns are medium-granularity design descriptions that can be used inside toolkits and frameworks. Toolkits and frameworks are larger reusable architectures; patterns are the recurring design decisions within them that standardize how problems like adapting interfaces, decorating components, encapsulating commands, deferring creation, and varying algorithms are solved. For example, Swing as a framework embeds Decorator (JScrollPane), Strategy (LayoutManager), Command (Action), Proxy (RMI stubs), and Factory (Collection.iterator()) as its extension points.

14.7.2 Applying a Pattern in a Project — What Must Be Changed

Visual intuition: picture a stencil (the pattern) with labeled cutouts: Component, Decorator. Next to it, three stenciled walls labeled Swing, I/O Streams, Pricing. Each wall shows the same stencil shape but with different paint colors and labels: JComponent / JScrollPane, InputStream / BufferedInputStream, Sale / PercentDiscountPricingStrategy. The stencil shape — aggregation plus interface — is constant; the paint — names, state — varies. Takeaway: patterns are stencil shapes, not finished walls.

14.7.3 Student Questions and Answers

14.7.4 Worked Examples

14.7.5 Industry Applications

Real-world: C++ standard library as the canonical toolkit — vector, map, algorithm used by the application via direct calls. Compiler and GUI frameworks as architectures that embed patterns — Swing's JComponent hierarchy, Eclipse or NetBeans Platform where editors are framework plugins. Collection and GUI libraries where pattern instances — factory for creation (Collection.iterator()), strategy for layouts (LayoutManager), proxy for remote access (RMI stubs, EJB pool proxies), command for actions (Action), decorator for views (BufferedInputStream, JScrollPane) — already appear as documented extension points. Any modern IDE, browser engine, or game engine is a framework that composes toolkits internally and exposes pattern-based hooks.

14.7.6 Exam Notes

14.8 Pattern Identification Exercises and Common Traps

14.8.1 Exercise Type 1 — Is Singleton Used Correctly?

A fragment was presented that appeared to name a singleton but was not a correct implementation. The diagnosis is to check two things. Naming alone does not make a singleton. The question is whether the code can actually return the single instance through a public access method. If the instance is created inside a class but there is no public method such as getInstance() that allows clients to reach it, there is no way to obtain the object. A correct singleton must expose the instance through a public access method; otherwise the creation is isolated and unusable.

public class ServicesFactory {
    private static ServicesFactory instance = null; // or eager new
    private ServicesFactory() {} // guard
    public static synchronized ServicesFactory getInstance(){
        if(instance==null) instance = new ServicesFactory();
        return instance;
    }
}

14.8.2 Exercise Type 2 — Does This Fragment Implement Factory Method?

14.8.3 Exercise Type 3 — Which Pattern Fits a Description?

Exam Guidance Summary

• Intent drives pattern choice. Problems that mention converting one plug into another, existing services that are not compatible, and converting target to source point to Adapter. Problems that require adding scroll bars, borders, or other visual or behavioral enhancements without changing component usage point to Decorator. Problems that mention execute(), isEnabled(), setEnabled(), putValue(), icons, and undo/redo history point to Command. Problems that mention delaying instantiation, expensive loading until viewed or until a tab is clicked, or deferring remote connections point to Proxy. Problems that describe a family of algorithms such as encryption, compression, layout, comparator, or file save formats and the ability to change the algorithm at run time point to Strategy. Problems that seek to hide creation logic, expose only a common interface, and choose among several possible classes based on data point to Factory and Factory Method — the latter via a Creator hierarchy where each ConcreteCreator decides the ConcreteProduct, as with iterator() over singly linked lists, doubly linked lists, stacks, queues, and priority queues.

• Know how to compare a constructor with a factory method: a constructor has the same name as the class and, when public, exposes creation — caller must new ConcreteClass(...); a factory method hides that logic and returns objects through a common interface, letting subclasses or a parameter-driven factory decide the concrete type. Be ready to explain why merely creating a single XMLReader does not satisfy Factory Method (no product family, no Creator hierarchy, single helper only), while iterator() over singly linked lists, doubly linked lists, stacks, queues, and priority queues is a canonical Factory Method because each collection supplies its own creation method behind a shared Iterator abstraction with hasNext() and next(). The Simple Factory versus Factory Method contrast — if(type) inside one class versus abstract create() overridden by subclasses — is the scored discriminator.

• Distinguish diagrams from intent. Decorator and Composite share a diagram shape — shared abstraction, concrete component, and an aggregating wrapper — but Composite composes a tree (iterate over many children) while Decorator enhances a single object (forward to one wrapped component plus augmentation). Naming alone, such as calling a variable singleton, does not satisfy a pattern; for Singleton check that a public static getInstance() actually returns the one instance and that the constructor is private, and for any pattern check that the full set of responsibilities and collaborations is present, not just a fragment or a name.

• The session emphasized downloading and running small code examples for Decorator via JScrollPane decorating JTextArea (new JScrollPane(myTextArea) and new SlashDecorator(new CoolDecorator(new JButton(...))) plus FilterInputStream chains), Command via Action/AbstractAction greeting actions and cut/copy/paste enable logic with undo history as a Vector<Command> + unDo(), Proxy via image proxies that implement paintIcon() with MediaTracker + delay and tab-deferred creation plus RMI stubs, Strategy via LayoutManager variants BorderLayout/GridLayout/BoxLayout with layoutContainer(Container) and Comparator variants (CompareById/Name/Age) plus file-save/pricing strategies, and Factories via shape factories (getShape(type)), name formatting factories using comma conventions (NamerFactory.getNamer), and honorific Mr./Ms. selection. Time constraints meant coding parts were assigned for independent practice rather than live demonstration; prepare to discuss how each execution path forwards to the wrapped or created object and augments or selects behavior. Exam answers should trace one such path — for example Decorator's paint → wrapped.paint → augment, or Command's isEnabled guard → execute → append to history.

• Series guidance: the next class is the last one. Review the pattern vocabulary — how to use each pattern, how they differ — and the differences among toolkits (application calls library, e.g., C++ STL), generic templates (language compile-time type mechanism, not a design pattern), and frameworks (cooperating classes for an application kind that invert control and call your extensions). The following topic will cover design metrics and measuring design quality — cohesion, coupling, and protected variation made measurable — and will build directly on the ability to name which pattern is present and why. Attendance and preparation were requested, and asking peers to attend was encouraged.

Key Industry Applications

Real-world: Java Swing toolkit — JComponent, JTextArea, JButton, JScrollPane for component decoration (new JScrollPane(myTextArea) and FilterInputStream chains like BufferedInputStream); Action, AbstractAction, ActionListener for commands (cut/copy/paste with isEnabled and undo histories); Container together with LayoutManager, BorderLayout, GridLayout, BoxLayout for strategies (every GUI validates via layoutContainer); and collection iterators hasNext()/next() over singly linked lists, doubly linked lists, priority queues, stacks, and queues as Factory Methods (collection.iterator()).

Real-world: Editor and GUI commands — cut, copy, paste with enabled/disabled state driven by Clipboard, and undo/redo over a List<Command> in word processors, drawing programs, and IDEs where each stroke or edit is an object that remembers its DrawData for reversal.

Real-world: Deferred loading — web pages that load images and videos only when scrolled into view or when a tab is clicked via ImageProxy.paintIcon with MediaTracker and a monitor thread; enterprise tabs that defer RealChart creation; and remote proxies in Java RMI and EJB connection pools that defer connection establishment until first method invocation.

Real-world: Remote access — Java Remote Method Invocation where a local stub/proxy stands in for a remote subject, implements the same service interface, and defers socket creation and marshaling until requestApproval or fetch is invoked, hiding latency behind the Subject interface.

Real-world: Algorithm families — file save formats such as PDF and word-processor formats, compression (Zip/Rar) and encryption (AES) variants, sorting strategies via Comparator applied through Collections.sort(list, comparator) that sorts by id, name, age, or city, plus shape factories (ShapeFactory.getShape) and name-formatting factories that hide branching on parameters such as type strings, honorific Mr. versus Ms., or comma-separated last-name-first conventions (NamerFactory.getNamer).

Real-world: Adapter for external-system integration — NextGen POS ITaxCalculatorAdapter / IAccountingAdapter adapting TaxMaster versus GoodAsGoldTaxPro and SAP via SOAP over HTTPS, selected by a reflective ServicesFactory singleton reading class names from system properties.

Real-world: Reuse architectures — C++ standard library as a toolkit example (application calls library) and compiler, GUI, and business-system frameworks as larger architectures that invert control and embed the above patterns as extension points; understanding whether you call the library or the framework calls you determines whether you are using a toolkit or a framework, and patterns are the vocabulary inside both.