Design Patterns — Gang of Four Solutions

Design Patterns — Gang of Four Solutions

This lecture builds the catalogue habit behind the Gang of Four design patterns — what a pattern is, why it spreads as shared vocabulary, how each catalogue sheet is documented, where patterns sit between language mechanics and system architectures, and the three GoF families that organise the 23 patterns. It then walks five canonical patterns and their failure mirror in depth: Prototype (cloning from a model with Cloneable and shape caches), Singleton (one instance via a private constructor), Composite (uniform part–whole with MediaClip/Sequence), Observer (one-to-many notification and MVC/JFrame listeners), Facade (single entry over scanner–parser–builder–generator), Adapter (interface translation via IconAdapter), and Anti-Patterns (named bad solutions and multiple-choice elimination). The closing guidance shows how to combine several patterns in one exam design and where these ideas live in industry code such as Swing, Linux pipelines and compilers.

13.1 Foundations of Design Patterns

13.1.1 What a Design Pattern Is

A design pattern — a named, proven, general solution to a recurring design problem together with the context in which it works — is the central idea of this lecture. You do not design from scratch each time. You reuse a good solution that has already solved many similar problems and has been proven in real systems. Because the solution has been used in hundreds of instances over many years, reusing it saves time and improves reliability.

The term became widely known after the book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, published in 1994–1995. The authors are jointly called the Gang of Four or GoF. Grady Booch, a pioneer of object-oriented design, wrote the foreword and the book is still described in the lecture as the Bible of design patterns. Its lasting contribution is not a library of code to copy but a way to document the design knowledge that lives in the minds of experienced designers.

Think of learning any designed thing. Every built thing has a design behind it. How do you learn design? In other fields you collect problems and proven solutions and study them as pairs. In mathematics you study theorems together with worked problems and their solutions. In building trades you keep catalogues, working drawings and detail drawings that record how a problem was solved. Design patterns carry that same habit into software: record the problem, the context and the working solution so others can learn from it. Without that catalogue, knowledge stays tacit in one designer's head and dies when they leave the team.

An everyday parallel helps. When you tell a dress seller "gown" or "plazo-cut saree," a large bundle of information travels with that one name — silhouette, seams, drape, typical fabric — without a ten-minute description. The same is true when a reviewer says "we will use Factory here" — listeners immediately know the problem type, the shape of the solution and its rough trade-offs.

13.1.2 Why Learning Design Is Hard

Becoming a good designer by personal experience alone takes a very long time. The lecture uses a vivid building-architect analogy:

Whenever you design, you look at alternate solutions and choose the best fit for the particular problem at hand. A creative designer often takes a known basic solution and adds a small variation on top of it. That habit exists in every engineering field and in creative work too — from dress making to car styling to graphics. The mental step is identical: learn the recurring forms, then adapt them. This is why the lecture stresses that patterns do not make you less creative — they give you a stronger starting point so your creativity goes to the variation, not to reinventing the base.

If you miss this point you will treat patterns as magic templates. They are not. They are borrowed experience, useful only when the context matches.

13.1.3 Patterns Beyond Software

The lecture stresses that patterns are not limited to code. The word was deliberately borrowed from the wider world of repeatable forms.

In clothing there are named dress patterns: a gown, a saree, and within sarees many variations such as plazo cuts and draped forms. When you tell a seller the name, a large amount of information moves with that one name. In cars there are named body patterns such as hatchbacks and SUVs — each name carries proportions, door layout, cargo intent and typical customer. In machine learning the field itself is often called pattern recognition, and the well-known book Pattern Recognition and Machine Learning by Christopher Bishop carries that same use of the word. The whole world, as the lecture puts it, is full of patterns and repetitions.

This breadth is kept in the notes for a reason: it shows why the word pattern was chosen. It points to a repeatable form, not to a one-off trick.

Where the analogy breaks: a dress pattern can be cut almost literally, fabric for fabric. A software pattern cannot be copied line-for-line; you must adapt names, method signatures and object lifetimes to your context. The repeatable part is the collaboration, not the code text.

13.1.4 The Core Questions of This Material

Two threads run through the entire session and will shape your exam preparation:

1. What are the benefits of using patterns and why have they become the normal way to record design?
2. How do you learn patterns so you can apply several of them together to a real problem and argue that the combined solution will work?

The second thread is the harder one. The lecture is explicit:

Visual to keep in mind: picture a workshop wall covered with pinned catalogue sheets. Each sheet has a bold title (the pattern name), a short paragraph of when it applies, a UML sketch of two to four collaborating classes, and a bullet list of consequences at the bottom — half in green (gains) and half in amber (costs). That wall is the habit the GoF book made standard.

The handoff to the next section: once you accept that patterns are borrowed experience recorded as name + context + solution + consequences, the next question is how they help you day to day and what they cost — the focus of 13.2.

13.2 Benefits, Shared Vocabulary and Consequences

13.2.1 How Patterns Help Day to Day

A design pattern is more than a diagram — it is a shared abbreviation. Patterns help in several linked ways:

• They improve communication between designers, programmers and clients because each pattern has a prominent name. With the name you know the intent (purpose), the context (when it applies) and the shape of the solution, including its known trade-offs.
• They capture experience. By learning one pattern you borrow lessons from many systems that used it, rather than reliving their failures yourself.
• They raise reuse. Proven solutions get applied again rather than rebuilt from first principles.
• They give a systematic way to document and to evaluate alternate designs. A pattern description forces you to state problem, context and consequences, so comparisons are structured rather than hand-waving.
• They give a way to teach good design. The pattern description itself becomes a teaching tool — a catalogue sheet a newcomer can study.

In practice, when someone says in a review "we are using Factory here" or "this part is Observer," the team can quickly picture the roles and collaborations involved, anticipate the consequences, and confirm that the direction is sound. That shared picture reduces doubt about whether a proposed design will work. The reliability argument you can make to a client is concrete: this form has already been used widely and has succeeded in a known set of contexts, so risk is lower than for a novel construction.

A useful everyday parallel is Swing itself, mentioned later in the lecture: a developer who knows Composite and Observer recognises them inside JComponent, Container, listeners and models at a glance, while a developer who does not must reverse-engineer each class individually.

13.2.2 Trade-offs Are Always Present

Every pattern brings both advantages and drawbacks. Any decision in design, as in life, has trade-offs. You weigh what you gain against what you lose and choose the best fit for your situation. While studying examples you should learn the trade-offs alongside the structure. The material returns to this point deliberately: advantages, disadvantages and consequences are part of the pattern description, not an afterthought.

Consider two small trade-off sketches to keep this habit concrete:

• Observer gains automatic updates and low coupling between model and views, but pays in indirection, notification ordering questions, possible redundant redraws, and the need to manage registration and deregistration carefully.
• Singleton gains a single shared point of access, but pays in hidden global coupling, harder testing and the risk of turning every resource into a global.

Neither is universally good or bad. Context decides. Learning to argue "we gain X and accept Y because our context needs X more" is the skill the exam will test when it asks you to justify a combined solution.

Students sometimes ask whether learning consequences can be postponed until after the structure is memorised. The lecture's answer is no — study them together. A pattern without its consequence list is a half-remembered recipe.

13.2.3 How Patterns Became the Normal Way to Record Design

Because catalogue form is standardised, teams can persist knowledge beyond the memory of one designer and make designs easier to teach and to change later. A new member joining a codebase that says "this subsystem is Facade over scanner–parser–builder–generator" has an entry point for study — search the pattern, read its motivation, and compare the actual classes to the canonical roles.

Visual to keep: imagine two archives side by side. On the left, a filing cabinet with loose project notes, each labeled by project name and year — hard to search, hard to reuse. On the right, a wall of identically formatted catalogue sheets sorted by purpose (creational, structural, behavioral), each with the same headings — easy to browse, easy to compare. Patterns moved the profession from the left cabinet to the right wall.

The implication for your study is practical: do not treat these patterns as academic only. Even if a team never says "this is Facade," the underlying need — hiding a set of interacting subsystems behind a single entry — still appears and still benefits from a known shape, whether the team names it or not. Your ability to recognise the context without being prompted is the transfer the course aims for.

13.3 How a Pattern Is Described and How to Learn It

13.3.1 The Minimal Documentation of a Pattern

A pattern description at a minimum contains four parts. The lecture repeats this checklist because it is also your revision checklist for each of the 23 GoF patterns.

1. Pattern name — a short, memorable name that acts as vocabulary. The name must be distinctive enough to recall the whole solution; that is why Facade, Adapter and Observer are chosen as images, not abstractions.

1. Problem description — starts with intent (the purpose, what the pattern aims to achieve) and context (the situation and kind of problem in which it applies), then says when to apply it and what general problem it addresses. This part answers "Do I have this problem, here, now?"

1. Solution — how the solution is structured, most often shown with UML class diagrams and interaction or sequence diagrams plus general structured pseudocode. The solution is given in terms of communicating classes and objects: responsibilities, interfaces, collaborations and ordering of messages. It is a shape to adapt, not code to copy.

1. Consequences and trade-offs — benefits, liabilities, and notes on how the pattern affects reuse, change, coupling and cohesion. This part answers "What do I gain and what do I pay?"

Other fields often included — especially in the GoF book — are motivation, applicability, participants (named roles such as Subject, Observer, Component, Leaf), collaborations (how roles talk), implementation notes, sample code, known uses and related patterns. Headings such as classification, intent, motivation, structure, participants and collaborations are common in the GoF catalogue and are worth recognising so you can navigate the book quickly.

A concrete habit to build: for each pattern you revise, open the GoF contents, locate its Intent, read one paragraph of Motivation, sketch its Structure diagram from memory, list Participants with one-line roles, and then write two consequences — one gain, one cost — without looking.

13.3.2 Two Ideas You Must Hold When You Study Each Pattern

When you study any single pattern, hold exactly two ideas first, before diagrams:

• the intent — the purpose of the pattern, what it aims to achieve, and
• the context — the situation and the kind of problem in which it applies.

There is no simple formula or decision tree that picks a pattern for you. The lecture is explicit on this: you learn to recognise the context, recall the intent, and then map the solution structure to your problem. Pattern selection is recognition, not calculation.

13.3.3 A Practical Way to Learn

This programme has no later separate course that will repeat these patterns at this depth. Everything in the syllabus — all 23 GoF patterns and many related forms — is meant to be learned now. Since they are now widely documented, the practical advice given in the lecture is concrete and worth following literally:

1. Read about a pattern on the web — intent, context and consequences, not just code.
2. Download code for it and run it. Step through the calls in a debugger.
3. Watch how the collaborations work — who creates whom, who holds whom, who notifies whom.
4. Try it in a different situation. Open a searched example (for instance, the net-standard Shape–Circle–Rectangle for Prototype), find the shape of the pattern, and then adapt it with small changes to your own problem rather than copying line for line.

The example often mentioned is the Swing library in Java for graphical user interfaces. Swing uses many of the GoF patterns at once, so working with Swing is described as a way to meet many patterns inside one real library — observer for event listeners, composite for components and containers, iterator for collections, factory for creation, singleton for toolkit instances, adapter for wrappers such as IconAdapter, and facade where a component hides a subsystem. By using Swing widgets, lists, tables and event sources you encounter observer, composite, factory, singleton, iterator, adapter and others in production code, not in toy snippets.

Visual to keep: picture your study table with two columns. Left column: a handwritten card per pattern with name at top, intent in one sentence, context in one sentence, tiny UML sketch, two trade-offs. Right column: a laptop running a Swing demo where you can set a breakpoint in notifyObservers, clone, or paintComponent and see the pattern fire. When the left card predicts what the right execution shows, you have learned that pattern.

13.4 Granularity — Where Patterns Sit

13.4.1 Low-Level Templates You Can Copy Directly

At the lowest level are programming constructs such as for loops, while loops and if statements. These are fine-grained. You can apply them directly and reuse them with almost no change. A for loop that traverses an array is the same in many programs. They are not called design patterns because they are not contextual design decisions — they are language mechanics.

Think of them as hand tools in a workshop: hammer, saw, screwdriver. Every builder uses them, but the design of the house is not captured in the choice of a hammer. The lecture draws this line deliberately so you do not chase patterns where mechanics suffice.

13.4.2 Medium-Level Patterns You Adapt

Design patterns sit at a medium level of granularity and at a medium level of abstraction. They are more general than a single loop but more concrete than a whole system architecture. They are defined as contextual solutions to recurring design problems that can be used with minimal adaptation. You customise them to your situation. They are not drop-in code that you cut and paste. You keep the shape and the collaborations, change names and details, and fit the solution to your classes.

This is why patterns are described as general, broadly applicable, repeatable solutions that have been used in many systems over many years. They are not finished designs ready to turn into code without thought. The published form is often pseudocode plus diagrams; you transform the pattern into the problem and then into code for your language, whether C++ or Java.

13.4.3 High-Level Architectures

At the high level are software architectures such as pipes and filters — familiar from Linux command pipelines like cat file | grep pattern | sort — and client-server and layered web architectures. These are course-level topics of their own and need a large amount of work to apply. Patterns are more primitive and smaller than frameworks and architectures, but the same habit of documenting context, problem and solution applies at every level.

Comparison to keep sharp:

Patterns are therefore primitive and contextual — smaller than a framework, bigger than a loop, and always tied to a particular design context.

13.4.4 The Full Definition Used in the Session

This section consolidates the scattered phrases from the lecture into one working definition you can quote.

• A description of communicating objects and classes customised to solve a general design problem in a particular context.
• Described with intent, motivation, structure in terms of classes, participants and collaborations.
• Classified by purpose — creational, structural, behavioral — and by scope — class vs. object.
• Written at a medium granularity where reuse with small changes is realistic.

These descriptions rest on object-oriented principles already covered and worth recalling explicitly because they explain why many patterns look alike at the interface level: abstraction, encapsulation, modularity, separation of concerns, coupling and cohesion, divide and conquer, single point of reference, separation of interface from implementation (so you get more reuse), separation of policy from mechanism (so policy changes are easy to handle), and sufficiency plus completeness. If you can name the principle a pattern exploits — for instance, separation of interface from implementation in Adapter and Facade, or divide-and-conquer in Composite — you can explain its leverage more convincingly.

13.5 The Three Families of GoF Patterns

13.5.1 Purpose-Based Classification

The GoF catalogue groups its 23 patterns into three families by purpose — what design force they relieve. This grouping is the first filter you should apply when facing a problem.

• Creational patterns — how you create and arrange objects, giving the designer more flexibility than direct, static construction with new. They separate the operation of creation from the rest of the application so creation is not tightly bound to one class and so a family of related products can be produced consistently. Constructors are the standard way to create objects, and these patterns add controlled variations and global access points. Examples discussed in detail in this session are Prototype (clone a prototypical instance) and Singleton (one instance, global access). Other members named and widely used are Factory Method, Abstract Factory and Builder. The creational theme is: who creates what, when, and how the concrete class is hidden behind an interface.

• Structural patterns — how you arrange classes and objects into larger structures, using abstraction, aggregation, inheritance and composition to shape the static make-up of a system. They answer "how do parts compose into a whole that still behaves like a part, or how do I make two mismatched interfaces work together?" The detailed example in this session is Composite; Adapter and Facade later in the lecture are also structural. The structural theme is: how the skeleton fits together and how it protects clients from change.

• Behavioral patterns — how objects take on responsibilities and communicate, especially how you assign and distribute behavior across objects and how you describe collaborations and message flows at run-time. Observer, also called publish-subscribe and earlier known in Smalltalk and MVC frameworks, is the detailed behavioral example here. Other behavioral forms mentioned include Iterator, Strategy, Command and State. The behavioral theme is: who does what, when, and how a change or request propagates.

Real-world note from the session: the GoF purpose groups act as a rapid triage when you face a problem on the whiteboard. That triage is itself a pattern habit — name the family, then narrow to candidates, then compare intents.

13.5.2 Scope and Perspectives

Alongside purpose, patterns are also seen as class-scope or object-scope depending on whether the variation is achieved mainly through inheritance at class level (compile-time, hierarchy-driven) or through object composition at run-time (delegation, aggregation, lists of peers). Classical examples: Factory Method in its class form uses inheritance to let subclasses decide what to create; Prototype, Composite and Observer lean on object composition to vary behaviour at run-time by configuring objects. In practice most patterns involve both — Composite inherits from the common interface and aggregates children; Adapter inherits from the target and holds the adaptee — but the dominant variation mechanism determines the scope label.

At a higher level, the lecture stresses that any object-oriented solution is at its core a collaboration or communication among objects in a particular context, and that context is always important for choosing and explaining a pattern. That is why two patterns can share a similar structure (for instance, Adapter and Bridge both place an indirection between an abstraction and an implementation) yet differ fundamentally in intent and when they are applied: Adapter repairs an existing mismatch after the fact, Bridge is designed up-front to let abstraction and implementation vary independently.

Visual: imagine three shelves labeled CREATIONAL, STRUCTURAL, BEHAVIORAL, each holding 5–8 catalogue sheets, and a side label on each sheet marking C (class) or O (object). When a symptom appears, you walk first to the right shelf, then pull two sheets and compare their intents before you draw.

13.6 Prototype — Cloning Objects from a Model

13.6.1 The Problem

A very common need appears in graphical editors, word processors, presentation tools and UML drawing tools: a user works on a canvas and wants to make a copy of an existing graphical item — a shape, a text box, a connector — and then change its size or position. The user does not want to build the new item from nothing each time. The system needs to produce clones of a prototype item quickly, without knowing in advance how many copies will be needed.

Put abstractly: there is an original item, you need to make a clone, and the user should be able to define properties such as the size of the clone. You cannot pre-create a fixed number of objects because you do not know the number in advance. A creation approach that hard-codes new Circle() for every new shape with a long conditional chain (if shapeType == "circle" then new Circle() else if shapeType == "rectangle" ...) is brittle and forces the client to know every concrete class.

The same requirement appears in less visual domains: cloning configured report templates, cells in a spreadsheet engine, or prototype game entities where the base attributes are tuned once and then copied.

13.6.2 The Solution Shape

• A common interface or abstract class, often called Shape, defines the operations that all shapes share — clone(), draw(), perhaps getArea().
• Concrete classes such as Circle and Rectangle implement Shape and hold their own specific data such as radius for a circle or width/height for a rectangle.
• A client interacts only with the Shape interface, not with each concrete class directly. The relationship between the client and the concrete classes passes through inheritance from Shape — this is where interface separation protects the client.
• A Shape cache or registry (often a Map<String, Shape> or Dictionary) can hold one prototypical instance of each kind, keyed by name. When a new item is needed, the client asks the prototype to clone itself and then adjusts the new copy, for example by supplying a new radius.

The class diagram described in the lecture shows Shape at the top as an interface, the concrete shapes below it inheriting from it, and the client using Shape via aggregation to the registry and via a clone() call. The key move is that only one prototype per kind needs to exist; clones are created on demand.

Pseudocode for the idea, in the spirit of the session and matching the standard textbook example:

interface Shape {
  Shape clone();
  void draw();
}
class Circle implements Shape {
  private int radius;
  Circle(int r) { radius = r; }
  Shape clone() { return new Circle(this.radius); }
  void draw() { /* draw with radius */ }
}
class Rectangle implements Shape {
  private int width, height;
  Rectangle(int w, int h) { width = w; height = h; }
  Shape clone() { return new Rectangle(this.width, this.height); }
  void draw() { /* draw rectangle */ }
}
// registry
Map<String, Shape> prototypes = new HashMap<>();
prototypes.put("circle", new Circle(10));
prototypes.put("rectangle", new Rectangle(5, 8));
// client — no knowledge of Circle vs Rectangle
Shape newCircle = prototypes.get("circle").clone();

Real-world note from the lecture: the same Shape idea is the standard example found on the web for Prototype. Search "prototype pattern Shape Circle Rectangle shape cache" and you will find Shape, Circle and Rectangle with a shape cache and a clone operation — runnable code you can extend to new shapes with almost no client change.

Visual to keep: picture a rubber stamp tray (the registry) holding one master stamp per shape — a circle stamp inked at radius 10, a rectangle stamp at 5×8. The client presses the stamp onto paper to make a fresh copy, then trims the copy to size. The master stamp never moves and never runs out; you make as many copies as you need. That is different from a tray that holds 100 pre-stamped copies — the master-tray scales.

13.6.3 Tagging Interfaces and Java Clone

In Java the cloning support touches a well-known interview topic.

• An interface — a type that lists operations without giving their implementation — can be empty of methods and still be useful.
• A tagging interface (also called a marker interface) — an interface with no methods that marks a class as having a property — is that empty form.

Cloneable is the example given of a tagging interface. It has no methods. You implement it to tag a class as one that allows cloning, and the environment then knows it may call the clone mechanism. The language provides a clone() method of protected type in Object that is reachable through this tagging permission. This can feel strange: why implement an interface with no methods? The answer offered is that you want to signal to the runtime that this class is intended to be cloned, even though you do not want to force a public clone implementation on every tagged class. It is a way to declare capability without prescribing the method signature — a permission flag rather than a contract.

13.6.4 Using the Pattern Well

Prototype belongs to the creational family because it controls how new instances are created — by copying rather than by direct construction via new with concrete class knowledge. It comes with clear trade-offs.

Gains: hides the concrete class from the client; avoids a long if-else or switch creation chain; allows adding new products (new shape kinds) by adding a prototype, not by editing clients; can be more efficient when object creation is expensive and a cached prototype is cheaper to clone.

Costs: you must manage copying correctly, especially for fields that reference other objects (shallow vs. deep); the set of prototypes must be initialised and kept consistent; explaining cloning permission in Java adds conceptual overhead.

The lecture advises trying the Shape example with code concretely: load prototypes into a Map<String, Shape>, clone from the map, print the clone's radius to verify independence, and extend to a new shape to feel how little the client changes. Beyond graphics canvases, the Swing library example — creating many similar widgets by cloning a configured prototype — is cited as a way to meet Prototype alongside other patterns inside one real codebase.

13.7 Singleton — One Instance with Global Access

13.7.1 The Problem

Some resources should exist only once for the whole application and many parts of the system should be able to reach that same object. Two small but telling examples given in the lecture are:

• a company name object that holds the organisation identity and is used throughout the company system — changing it should be visible everywhere at once, and
• a random number generator that the environment creates once and all students or classes reuse, often because it is seeded once.

Without a disciplined way to enforce a single instance, code can create many copies by mistake, each with its own state, or reach the resource through messy global variables and bare static fields, which C++ and similar languages try to avoid because they obscure ownership and lifecycle. A hidden second instance is a classic bug: two Company objects diverge, or two generators produce different sequences and break tests.

13.7.2 The Solution Shape

• The constructor of the class is made private so outside code cannot call new Singleton() directly. This is the enforcement mechanism.
• The class holds its one instance in a private static field and creates it at the point of declaration (eager) or on first use (lazy).
• A public static method, conventionally called getInstance(), returns that same instance to any caller. Because the method is static and class-scoped, no existing instance is needed to reach it.

Structure in words: a class Singleton with a private constructor, a private static Singleton instance, and a public static Singleton getInstance() { if (instance==null) instance=new Singleton(); return instance; }. Clients call Singleton.getInstance() rather than using new. The instance is created there itself inside the class, and the public method hands it out.

class Singleton {
  private static Singleton instance;
  private Singleton() { /* private — no outside new */ }
  public static Singleton getInstance() {
    if (instance == null) instance = new Singleton();
    return instance;
  }
  public void doWork() { /* shared behaviour */ }
}
// client
Singleton s1 = Singleton.getInstance();
Singleton s2 = Singleton.getInstance();
// s1 == s2 is true — same object

This pattern is the classic interview answer for "where would you use a private constructor?" By default many constructors are package-visible or public; singleton is the deliberate, justified case where you restrict construction to enforce singularity. The combination — private constructor plus public static accessor — is its signature.

A quick check with real references sharpens the picture. Under the lecture's Company example:

Company c1 = Company.getInstance();
c1.setName("Acme Ltd");
Company c2 = Company.getInstance();
System.out.println(c2.getName()); // prints "Acme Ltd" — same instance

If a second new Company() were possible, c2 could hold a different name and the system would be inconsistent. The private constructor prevents that second new.

13.7.3 When to Use It and What to Watch

Use singleton when you need global reach and a single copy — many clients must share state or a heavy resource, and you want to control creation rather than leaving it to scattered new calls. Classic collaborators: configuration holders, logging services, thread pools, and shared generators seeded once.

The same property that makes singleton useful also makes it risky. Global reach increases coupling and can hide dependencies. A class that calls Singleton.getInstance() deep inside a method hides the fact that it depends on shared mutable state — tests must then reset that state between runs or become order-dependent. Much later design guidance therefore warns to use singleton sparingly and to keep the shared state easy to test, to reset, and if possible immutable after initialisation.

Implementation notes worth remembering:

• Lazy vs. eager: The lecture sketch uses lazy creation (if null then create). Eager creation (private static Singleton instance = new Singleton();) is simpler and avoids a null check but pays creation cost even if never used.
• Thread safety: In a multithreaded environment, two threads calling getInstance() simultaneously can create two instances if the check is not synchronised. Production code uses synchronisation, double-checked locking, or the enum-singleton idiom in Java — detail not required on the exam but worth noting as a pitfall.
• Subclassing limitation: A private constructor makes subclassing difficult. If you anticipate variation in the singleton's behaviour, instance-side methods on the singleton instance are more flexible than static-only helpers, as discussed in the textbook.

Visual: picture a single reception desk in a large office building. Every department that needs the company stamp must walk to that one desk (getInstance()), rather than keeping its own stamp. The desk guarantees there is one stamp and controls who uses it — convenient, but every department now depends on that desk being open and consistent.

13.8 Composite — Treating a Single Object and a Group the Same Way

13.8.1 The Problem

How do you build a whole that can be used exactly like one of its parts? Selling pens is the simple analogy used in the lecture: a single pen with its own price and details, and a bundle of pens where you join the properties of each single pen into a new sellable whole. The buyer treats the bundle as a single item while it still contains many individual items.

The session gives a media example that carries the same structure: there are individual audio clips and video clips that can be played, and there is a sequence that holds a collection of those clips. The user wants to play() a single clip or play() the whole sequence through the same operation — the sequence should play each of its clips in turn and getPrice() should aggregate prices. A plain list fails here: a list does not share the clip interface and cannot be passed where a single clip is expected.

In an earlier case study referred to as the gate example, the same part-whole tension had appeared — individual gates versus assemblies of gates that still behave like a gate.

13.8.2 The Solution Shape

• A common Component interface, often called MediaClip or Component, declares shared operations such as play() and getPrice(), plus child-management operations such as add(MediaClip m) and remove(...) (sometimes only on the composite).
• Leaf classes such as VideoClip and SoundClip (or SinglePen) implement the interface for single items — each leaf keeps its own independent identity and lifecycle and its own implementation of play() and getPrice().
• A Composite class such as Sequence or AddSequence also implements the same interface. Inside it holds a collection of MediaClip by aggregation — each leaf keeps independent identity — and its own implementation of play() simply iterates and calls play() on each member. Similarly, getPrice() sums or combines values returned by members.

The class diagram discussed shows MediaClip at the top, VideoClip and SoundClip as leaves, and Sequence as the composite that both inherits from MediaClip and aggregates MediaClip (a diamond-linked collection). Common methods are implemented by leaves and by the composite with forwarding.

Why both inheritance and aggregation together, not just one?

• Inheritance lets the composite be used wherever a single clip is expected — it is a kind of clip from the outside, so a variable typed MediaClip can hold either. This is the uniformity guarantee.
• Aggregation lets the composite hold many clips without copying identity or lifecycle — the clips exist independently and can be moved between composites.
• Dynamic binding then does the rest: when the client calls play() on a MediaClip reference, the run-time picks the leaf version for a single item and the composite version for a group, and the composite forwards the call to its members.

Pseudocode for the intent, elaborated with prices to make forwarding visible:

interface MediaClip { void play(); int getPrice(); }

class SoundClip implements MediaClip {
  void play() { /* play sound: drum beat */ }
  int getPrice() { return 5; }
}
class VideoClip implements MediaClip {
  void play() { /* play video: 2-sec animation */ }
  int getPrice() { return 10; }
}
class Sequence implements MediaClip {
  List<MediaClip> parts = new ArrayList<>();
  void add(MediaClip m) { parts.add(m); }
  void remove(MediaClip m) { parts.remove(m); }
  void play() { for (MediaClip m : parts) m.play(); }
  int getPrice() { int s = 0; for (MediaClip m : parts) s += m.getPrice(); return s; }
}
// client — polymorphic usage
MediaClip single = new SoundClip();
single.play();               // plays one sound, price 5
Sequence seq = new Sequence();
seq.add(new SoundClip());    // price 5
seq.add(new VideoClip());    // price 10
seq.add(seq2);               // composites can nest — a sequence of sequences
MediaClip whole = seq;       // upcast — same type
whole.play();                // forwards to all three internal members
int price = whole.getPrice(); // 15 — aggregated

A client can then write MediaClip c = new SoundClip(); c.play(); and also Sequence s = new Sequence(); s.add(new SoundClip()); s.add(new VideoClip()); s.play(); with no change in the call site. A colour-coded version of this diagram was shown: interface operations in one colour, forwarding/aggregation management in another — worth recreating mentally to separate what the component promises from how the composite fulfils it.

Visual: picture a music playlist app. A Song is a leaf — you can press play on one song. A Playlist is a composite — you can also press play on a playlist, which just plays each song inside in order. A playlist of playlists is still a playlist. The same play button works no matter how deep the nesting.

13.8.3 Why This Matters and How It Is Tested

Composite is a structural pattern because it shapes how objects are arranged into a recursive tree. The key property to remember and to state in an answer is: leaves have their own identity and can be used alone, yet the composite can be used as if it were a single leaf. That sentence alone signals that you understand the two mechanisms together.

The lecture frames it as a structural pattern alongside inheritance-plus-aggregation questions long used in interviews: "When would you use inheritance and aggregation together?" Composite is the canonical answer. It also connects naturally to other patterns: Iterator often traverses the composite's parts, Decorator wraps a component while Composite groups them, and Composite is itself the shape behind pricing strategies that combine multiple ISalePricingStrategy objects behind one getTotal() call in the textbook example.

Real-world settings worth naming:

• File systems where a Folder may hold Files or other Folders — open(), getSize() work uniformly.
• Graphical scenes where a Picture holds Shapes (or JComponent/Container in Swing) — draw() or paintComponent() works uniformly.
• Price bundles in retail where SinglePen(price 5) vs PenBundle(price 5+10+...) share getPrice().
• The textbook's pricing composite where a CompositePricingStrategy holds a list of pricing strategies and returns the best total.

13.9 Observer — When One Change Must Flow to Many Views

13.9.1 The Problem

How do you keep many views in step with one underlying piece of data, without tying them tightly together? The original home of this pattern is Smalltalk, described in the lecture as the purest form of object-oriented programming, where the early framework called Model-View-Controller (MVC) — now widely seen as a framework built on the Observer idea — was first explored.

Picture a data table that is the model. Several views show that same model in different ways: view one is a pie chart, view two is a histogram, view three is a scatter or bar chart. Each view has its own controller, labelled C1, C2, C3 and so on. A user may change the model through any view — for example by editing numbers in a table or dragging a slice in the pie chart — and all views must automatically show the new state. You do not want each view to know the internals of every other view, and you want the set of views to be open — you may add a new view tomorrow without editing the model.

Another picture suggested in the lecture is a blackboard that is the observable item and several students who are observers, labelled 01, 02, 03, 04. The students all look at the same board. When the board changes through any student, all students are notified. The channel-subscription metaphor is also used: many subscribers watch a channel and receive a notification when the channel updates.

The same need shows up in many places quoted in the lecture: building a directory browser where the same data can be shown in a file-explorer view or a command-prompt view, and in graphical user interfaces where pressing a button should cause several registered listeners to react — without the button knowing who they are.

13.9.2 The Solution Shape

Roles and operations as presented in the lecture:

• Subject — holds the application state and the list of observers. It offers operations attach(Observer o), detach(Observer o) and notifyObservers(). In Java the library provides a class Observable that keeps this list and methods to add, delete and notify, plus a flag such as hasChanged() that is tested before notification to avoid redundant redraws. The concrete subject (e.g., StaffTable, DataModel, ConcreteSubject) holds the actual model data and a getState() accessor.
• Observer interface — declares an update() operation. Concrete observers such as PieChart, Histogram, BarChart or a button's ActionListener implement this interface and, when notified, fetch the new state from the subject and redraw or refresh themselves. In each concrete observer the update logic is named to fit the application, but the shape is the same.

The interaction sketched in the lecture is:

1. An observer registers with the subject through attach.
2. Any observer (or external actor) may request a state change on the subject through setState or similar.
3. The subject marks that it has changed (setChanged / hasChanged) and calls notify() on its list.
4. Each observer calls getState() on the subject and then updates/redraws.

Pseudocode for the intent — interface version matching the lecture, plus a note on the Java built-in:

interface Observer { void update(); }
interface Subject {
  void attach(Observer o);
  void detach(Observer o);
  void notifyObservers();
}
class ConcreteSubject implements Subject {
  private List<Observer> observers = new ArrayList<>();
  private Data state;
  private boolean changed = false;
  void setState(Data d) { state = d; changed = true; notifyObservers(); }
  Data getState() { return state; }
  void attach(Observer o) { observers.add(o); }
  void detach(Observer o) { observers.remove(o); }
  void notifyObservers() {
    if (!changed) return;
    for (Observer o : observers) o.update();
    changed = false;
  }
}
class PieChart implements Observer {
  private ConcreteSubject subject;
  PieChart(ConcreteSubject s) { subject = s; s.attach(this); }
  void update() { Data d = subject.getState(); // redraw pie with d
  }
}
class Histogram implements Observer {
  private ConcreteSubject subject;
  void update() { Data d = subject.getState(); // redraw bars with d
  }
}

In the Java library variant described, Observable is a class (not an interface) and Observer is an interface with update(Observable o, Object arg). A typical subject then calls setChanged(); notifyObservers(); and each update pulls the new data. A non-Java design often makes both sides interfaces. Either way, the collaboration is the same.

This achieves separation between application data and its presentation. Views stay separate from the data, and both sides remain reusable. The subject does not know the concrete class of any observer; it only knows they implement the observer interface. Communication is by broadcast notification, and there is no tight type coupling between subject and concrete observers.

Visual: picture a radio broadcast tower (the subject) and a ring of houses with radios (observers). The tower does not know who owns a radio — it just broadcasts on a frequency. Any house that tuned in (attach) hears the update. A new house can tune in tomorrow without the tower being rewired.

13.9.3 When to Choose Observer

Choose observer when the textbook checklist is met:

• Two aspects — data and presentation — must stay separate and both be reusable across contexts.
• One subject, many dependents, with a one-to-many dependency that may grow at run-time.
• A change in one place should appear automatically in others, but the subject should not need to know who the others are.
• The set of objects that must be notified is open-ended, not fixed at compile time.

The most memorable property to state on the exam is: a change in the subject automatically shows up in all dependent views without the subject holding knowledge of their concrete types. That automatic update — which the lecture calls simple and almost magical — comes directly from keeping the number of dependents open and avoiding direct knowledge between the sides. It is also why the channel-subscription metaphor fits: subscribing is attaching, publishing is notifying.

Common neighbours to distinguish:

• Mediator also decouples peers, but via a central hub that knows workflow, whereas Observer broadcasts from one source to many dependents without a hub workflow.
• Publish-subscribe channels at larger scale are Observer extended across processes.

Real-world settings beyond charts and tables quoted in the lecture: the event delegation model in graphical interfaces — ActionListener, MouseListener objects register with a JButton, and when the button is pressed every registered listener is notified — and publish-subscribe channels where many subscribers watch a topic. Both are Observer at different scales.

13.10 Facade — A Simple Door in Front of a Complex House

13.10.1 The Problem

How do you hide a complex set of cooperating subsystems behind one easy entry point? The best example offered in the lecture is a compiler. The work inside a compiler is complex and involves many steps and many interacting parts. A client such as a programmer just wants to compile a program by giving a simple command and receiving the output, not by driving each subsystem in the right order.

A second example offered is a product purchase that must apply many rules: credit card handling, debit card handling, coupons, gift certificates, expiry checks and similar business rules. A rule engine needs to evaluate the full set of rules behind the scenes and report success or failure, but the client operation is simply purchase(paymentChoice).

In both cases the underlying subsystems have many dependencies and the risk of circular or wrong ordering is real. If clients talk directly to each subsystem class — holding references to Scanner, Parser, NodeBuilder, CodeGenerator separately — they can create mistakes, duplicate wiring and brittle code, and the program may not build. Worse, every client rebuilds the same wiring slightly differently, so a change in one subsystem ripples to many clients.

13.10.2 The Solution Shape

• Clients talk only to the facade. They send requests to the facade rather than to the individual subsystem classes.
• The facade forwards those requests to the right subsystems, handles the ordering, and hides the dependency wiring. It knows which subsystem needs which data and when.
• Clients have no direct access to the subsystem classes through the facade path. The facade shields them and reduces coupling between subsystems and clients. Any later change inside the subsystems can be handled by changing the facade while most clients keep the same call.

For the compiler example the subsystems named are CodeStream that carries code, a Scanner or lexical analyzer, a Parser that builds a parse tree, a NodeBuilder that holds visual and other nodes, and a CodeGenerator that emits bytecode. Each has its own methods. The Compiler as facade holds references to these subsystems and offers methods that, depending on parameters, create different bundles and drive the correct sequence — for example, scanning then parsing then building then generating. A client then types a single command such as gcc with parameters and the facade does the compilation job and returns the result. The textbook-companion diagram shows each subsystem behind the facade, with the client arrow pointing only to the Compiler box.

For the purchase example the facade is the purchase operation or the POSRuleEngineFacade / rule-engine facade discussed in the textbook companions. Inside it evaluates the set of rules — credit vs. debit, coupon validity, gift-certificate expiry — and decides whether a particular combination is valid (for instance, marking an expired coupon as invalid), while the client sees only purchase(paymentType, coupon) with a payment-choice parameter.

A small pseudocode sketch of the forwarding:

// subsystems
class Scanner { Tokens scan(Source s) { ... } }
class Parser { ParseTree parse(Tokens t) { ... } }
class NodeBuilder { Nodes build(ParseTree p) { ... } }
class CodeGenerator { Bytecode emit(Nodes n) { ... } }

// facade
class Compiler {
  private Scanner scanner = new Scanner();
  private Parser parser = new Parser();
  private NodeBuilder builder = new NodeBuilder();
  private CodeGenerator gen = new CodeGenerator();
  Bytecode compile(Source s) {
    Tokens t = scanner.scan(s);
    ParseTree p = parser.parse(t);
    Nodes n = builder.build(p);
    return gen.emit(n);
  }
}
// client — one line instead of four orchestrations
Compiler facade = new Compiler();
Bytecode out = facade.compile(source);

Benefits captured in the lecture:

• Facade hides subsystems from accidental misuse — clients cannot call subsystems out of order.
• It removes a large number of direct dependencies from clients — one dependency on the facade replaces four or five on subsystems.
• It gives a single place to adapt when subsystems change — only the facade is edited.
• It does not force all clients to use the same simple view — power clients that need fine control can still reach more detail if the design allows a layered facade (a simple facade for most, deeper subsystem access for advanced use), but for most clients the simple view is enough.

Placement note: Facade is placed among structural patterns because it shapes the layer sitting in front of the subsystems and governs how classes and objects are connected to reduce coupling, not how responsibilities are distributed over time (which would be behavioral).

Visual: picture a modern house front door. Behind the door are dozens of systems — wiring, plumbing, heating, security, kitchen appliances — each with its own switches and dials. Visitors use the front door; they do not crawl through the service ducts. An electrician can still open the service panel when needed, but most people never do.

13.10.3 How to Recognise a Facade

Look for telling phrases in a problem statement: single entry point, default view, level in front of the subsystems, bundle the scanner–parser–builder–generator steps. The structural signature is:

• A class frequently named Compiler, POSRuleEngineFacade, ServicesFacade or SystemFacade.
• It holds references to subsystem objects (often via composition).
• Clients communicate with subsystem classes by sending requests to the facade, and the facade controls the conversation with the subsystems — it forwards, orders and adapts.

The lecture connects the facade idea to the earlier GRASP Controller idea: a controller takes delegation and coordination work away from scattered clients and places it in one place that knows the workflow. Facade is the GoF expression of that same impulse for subsystem collections. The textbook companion traces the purchase example further into a POSRuleEngineFacade whose static call POSRuleEngineFacade.getInstance().isInvalid(sli, this) hides whether rules are evaluated by Strategy objects, an interpreter, or a commercial rule engine — the facade makes that choice interchangeable.

Real-world settings cited as textbook facades: gcc invoked from Linux; purchase APIs that hide a payment-rule engine (credit, debit, coupon, gift certificate, expiry); many library entry objects that bundle scanner, parser, builder and generator steps; and the DBFacade / POSRuleEngineFacade examples in the companion design case where dozens of classes are hidden behind one public access point accessed via Singleton.

13.11 Adapter — Using What You Have with the Interface You Need

13.11.1 The Problem

How do you reuse an existing class whose functionality is right but whose interface does not fit the place where you need it, without changing that existing class? The lecture uses that electrical adapter directly: electricity is unchanged, only the shape of the interface differs.

In code the same mismatch arises often. The lecture's running example is the Icon family in Java. An Icon can paint itself (paintIcon) and can report its width and height (getIconWidth, getIconHeight), but it is not a Component and cannot be added directly to a Container. The Swing containers — JFrame, JPanel — accept only Component objects (more precisely, JComponent). You want to show icons inside containers without rewriting either side. The desired functionality already exists; the interface is what is wrong.

A similar mismatch appears with text boxes, graphical widgets, device drivers and external service clients where one hierarchy offers the right behaviour but the wrong type for the client that will hold it. The textbook companion adds the NextGen examples: TaxMasterAdapter and SAPAccountingAdapter adapt varying external tax and accounting service APIs to the consistent ITaxCalculatorAdapter / IAccountingAdapter interfaces used inside the application — same shape-translation, different domain.

13.11.2 The Solution Shape

Structure used in the lecture (object-adapter form, the more common and flexible variant):

• Target interface — what the client expects. In the Icon example, Component / JComponent, with operations such as paintComponent(Graphics g) and getPreferredSize(). In the NextGen example, ITaxCalculatorAdapter with getTaxes(Sale).
• Adaptee class — the existing class you want to reuse, such as Icon with operations getIconWidth(), getIconHeight() and paintIcon(Component c, Graphics g, int x, int y), or an external GoodAsGoldTaxPro with its own API.
• Adapter class — implements or extends the Target, holds a reference to the Adaptee as an aggregated private member, and translates each Target operation into a call on the Adaptee. The adapter therefore shows both inheritance (it is a Component) and aggregation (it has an Icon).

A client holds a reference to the target interface and talks only to the adapter. Inside, the adapter forwards the call. Class-level adapters achieve the same translation via multiple inheritance (Adapter inherits Target interface and Adaptee implementation), but Java without multiple inheritance of implementation favours the object-adapter with composition — the form shown in the lecture.

The code sketch presented and elaborated for precision:

interface Icon {
  int getIconWidth();
  int getIconHeight();
  void paintIcon(Component c, Graphics g, int x, int y);
}
class IconAdapter extends JComponent {
  private Icon icon;  // aggregation — adapter HAS an adaptee
  IconAdapter(Icon icon) { this.icon = icon; }
  @Override
  protected void paintComponent(Graphics g) {
    // translation: target paintComponent → adaptee paintIcon
    icon.paintIcon(this, g, 0, 0);
  }
  @Override
  public Dimension getPreferredSize() {
    // translation: target size query → adaptee width/height queries
    return new Dimension(icon.getIconWidth(), icon.getIconHeight());
  }
}
// client in a Frame — talks only to Target
Icon carIcon = new CarIcon(); // also BirdIcon, any Icon
JComponent adapted = new IconAdapter(carIcon);
frame.add(adapted);  // frame sees a JComponent; drawing delegates to Icon

Here target methods paintComponent and getPreferredSize are implemented by calling adaptee methods paintIcon, getIconWidth and getIconHeight. Once the icon has been wrapped as a component it can be added to the JFrame and will be drawn and sized correctly. This matches the lecture description where IconAdapter extends JComponent, implements target methods, holds a private Icon, and uses it in paintComponent and getPreferredSize.

Alternative adaptees were also mentioned as possible: any icon type such as CarIcon or BirdIcon can be given to the same adapter without changing the container code — one adapter serves an entire adaptee hierarchy.

The same translation in the textbook companion:

«interface» ITaxCalculatorAdapter { List<TaxLineItem> getTaxes(Sale s); }
class TaxMasterAdapter implements ITaxCalculatorAdapter {
  private TaxMaster adaptee = new TaxMaster(); // private aggregated adaptee
  List<TaxLineItem> getTaxes(Sale s) { return adaptee.calculateTax(s); } // name translation
}

Visual: picture two connectors side by side — a three-round-pin plug and a two-flat-pin socket. The adapter is a block with a socket on one face (fits your plug → Target) and pins on the opposite face (fits the wall → Adaptee). No electricity is changed; only the shape through which it flows is translated.

13.11.3 When to Use It

Use Adapter whenever you meet all three conditions:

• You want to reuse an existing class without changing it (because its source is unavailable, belongs to a library, or is used elsewhere in its current form).
• The functionality you need is already there but the interface you need is different — names differ, parameter order differs, or the type hierarchy does not match the container's expectation.
• The two interfaces are conceptually related enough that a translation is meaningful. Adapting Icon paint/size to Component paint/size works; adapting a tax calculator to a drawing routine would not.

The pattern is structural because it reshapes the interface around the reused implementation, not because it adds new domain behaviour. It realises a classic Protected Variation + Indirection theme from GRASP: protect the client from varying external interfaces by inserting an indirection object that applies polymorphism.

Related families worth placing next to Adapter:

• A resource adapter that hides an external system behind a consistent interface may also be considered a Facade (a single front over a subsystem). The textbook makes the distinction: if the motivation is adaptation to varying external interfaces, call it Adapter even if it looks like a Facade — intent selects the name.
• Bridge also separates abstraction from implementation, but it is designed up-front so both sides can vary independently, whereas Adapter repairs a mismatch after the fact.
• Decorator enhances without changing interface; Adapter changes interface.

Real-world settings: electrical socket adapters, Icon-to-Component (IconAdapter extending JComponent, holding a private Icon, implementing paintComponent by calling paintIcon and getPreferredSize by calling getIconWidth/getIconHeight, then added to a Frame), many Swing wrapper classes that make one toolkit fit another, and the NextGen IAccountingAdapter / ITaxCalculatorAdapter families that adapt external service APIs to the application's stable interfaces. The textbook notes that manufacturers' JavaPOS classes com.ibm.pos.jpos.CashDrawer and similar are also adapters in this sense — adapting native device drivers to the standard jpos.CashDrawer interface.

13.12 Anti-Patterns — Learning from Failure

13.12.1 What Anti-Patterns Are

An anti-pattern — a recurring bad solution that should be avoided because it reliably leads to poor outcomes — is the mirror image of a pattern. While a pattern records a proven good solution to a recurring problem, an anti-pattern records a worst practice or a bad lesson that teams have learned through failed projects. The reason to study anti-patterns is the same as the reason to study good patterns: humans learn a great deal from failures. If you learn how a bad design arises, what forces tempt you into it, why it fails, and how to move out of it toward a good solution, you avoid repeating the same mistake.

This idea is framed in the lecture with that multiple-choice analogy. One way to solve a multiple-choice question is to argue positively for the correct option. Another way is to rule out the wrong solutions first. By identifying and removing the wrong answers you also arrive at the good answer, and you arrive there with stronger justification — "we chose Observer because the alternatives were a polling loop that wastes CPU and a mesh of direct references that couples every view to every other view." Anti-patterns help you rule out the designs you should not use. Absence of anti-patterns is therefore part of what makes a design good.

A useful distinction: an anti-pattern is not simply "not knowing a pattern." Not knowing a pattern just leaves you to invent from scratch with no guidance. An anti-pattern is a named, repeatable bad construction that many teams have tried independently and that has been shown to cause harm — copy-paste variants, monolithic God objects, global cargo-cult singletons applied everywhere, a mesh where every view talks directly to every other view instead of through Observer, or presentation logic scattered into domain objects. Knowing its name lets you call it out in a review ("this is a God-object risk") and replace it with the corresponding good pattern.

13.12.2 How They Are Documented

Anti-patterns are documented in the same habit as good patterns — problem, context, bad solution, why it fails, how to move to a better solution — but with the focus on the failure path and recovery. Bad practices are explicitly labelled so teams can recognise them in reviews and steer away. Consequences are stated as reliably negative: higher coupling, lower cohesion, duplicated code, fragile change, testing difficulty, performance traps.

The lecture notes that time may not allow a deep dive into anti-patterns in this session, but the idea should be retained: catalogue the bad forms alongside the good forms. The habit extends naturally to related forms such as design smells (symptoms of a drift toward an anti-pattern) and refactorings (the moves that cure them). That extended habit is why the textbook companions often pair a pattern with the alternative that fails — for instance, contrasting Facade (one default front) with a scatter of direct subsystem calls that entangle every client.

Study tip: for each pattern you revise, add one anti-pattern question to your card: "What would the naïve bad construction look like here?" For Observer the bad form is "every view polls the model or holds a direct typed reference to every other view." For Composite the bad form is "a separate List<Leaf> everywhere with no uniform interface, so every client branches on type." For Singleton the bad form is "every class creates its own new Configuration() and the values diverge." Naming that failure makes the good pattern's intent sharper.

Real-world texture: the most informal anti-pattern exercise happens in project post-mortems and interviews that ask "what is the worst way to solve X, and how would you rescue it?" Recurring answers — "we tried direct global references everywhere and regretted it," "we copy-pasted calculation code into every form and maintenance collapsed" — are nascent anti-pattern entries waiting to be named.

Exam Guidance Summary

This lecture closes with the pattern-combination skill that the exam will measure directly. Individual pattern knowledge is necessary but not sufficient.

• Expect one or more real-world problems where you must identify several patterns at once, place them in one object-oriented solution, show the arrangement with class diagrams and sequence or interaction diagrams plus pseudocode, and argue that the combination works in the given context. A typical problem might ask you to introduce a factory that creates adapters, accessed via singleton, with a facade over a rule subsystem — and to justify each choice. Practise placing two to three patterns together rather than hunting for a single pattern, and rehearse the adaptation sentence: "We kept the GoF collaboration but mapped roles to domain names X, Y, Z because..."

• You are expected to know the 23 GoF patterns at the level of name, intent, problem, context, structure, participants, collaborations and consequences. The syllabus includes this full set, and for this programme there is no later course that will repeat it at this depth. All patterns are freely documented; the GoF book with C++ examples and their Java interface translations is the core reference. Use the minimal documentation checklist when you revise: name, problem with intent and context and when to apply, solution in terms of diagrams and pseudocode, and consequences with trade-offs. Add known uses to anchor context — Swing is the richest single source.

• Study by doing, not only by reading. Read a pattern online, download its code, run it, trace through the calls with a debugger (set breakpoints in clone(), getInstance(), notifyObservers(), paintComponent() and watch the collaborations fire), and then apply it in a different domain. The Swing library is named explicitly as a useful place to see observer, composite, factory, singleton, iterator, facade and adapter side by side in production code. The prototype Shape–Circle–Rectangle example and the Icon-to-JComponent adapter are both runnable starting points; extend them to your own types to test adaptation.

• On the exam, write assumptions so the reader can follow your reasoning when you choose a pattern. Adapt the general structure to the problem and name the adaptation rather than copying diagrams line for line — examiners check that you preserved intent while renaming. Show the translation steps, including any reuse of existing interfaces versus new interfaces you introduced. Marks are distributed across correct pattern choice, correct diagram shape, and coherent justification of consequences and trade-offs — including which anti-pattern you ruled out and why.

• Prior learning referenced as helpful includes object-oriented principles already covered: abstraction, encapsulation, modularity, separation of concerns, coupling and cohesion, divide and conquer, single point of reference, separation of interface from implementation, separation of policy from mechanism, and sufficiency with completeness. The Smalltalk MVC and pipes-and-filters architecture mentioned in the session are background context you should be able to relate to pattern choices — for instance, MVC as the historical home of Observer, pipes-and-filters as a high-level architecture that sits above patterns.

Key Industry Applications

The patterns taught in this lecture are not academic exercises — the lecture and its textbook companions present them as the de facto way that design knowledge is recorded and reused across real industries.

Catalogues beyond software. Gang of Four patterns are described as the de facto standard for documenting design knowledge. Domain catalogues now exist for telecommunications, web systems and retail selling; teams in those domains publish their own pattern sets that follow the same name, problem, context, solution and consequence format. When a telecom team says "we need a Mediator for the session manager," the same shorthand benefit appears as in software.

Vocabulary that travels. Dress and car pattern vocabularies are the non-software parallels used to explain why a short name carries a full solution. A seller hearing gown, saree, plazo or a buyer hearing hatchback, SUV knows the silhouette, proportions and trade-offs without a long description — just as a developer hearing Factory, Observer or Prototype immediately pictures the collaboration. That cross-domain parallel is retained deliberately to anchor why intent and context must accompany the name.

Borrowed experience at scale. The 15 to 20 bridges or buildings analogy for how long it takes to become an expert by building alone is used to motivate borrowing experience through patterns rather than waiting for personal project count to grow. Telecommunications and product-line companies use pattern histories for exactly this reason — to let a new hire design a new switch variant by standing on the recorded lessons of past switches.

Frameworks that embed Observer. Model-View-Controller in Smalltalk and now broadly in UI frameworks (Swing, JavaFX, web MVC) is the framework history behind Observer. Data tables with pie chart, histogram and scatter views are the runnable picture of one model with many views kept in step by notification. The blackboard with several student observers is the physical classroom parallel for the same one-to-many setup. In production today this shows up as event delegation, publish-subscribe channels, message buses and reactive streams.

Editors that rely on Prototype and Composite. Graphical editors in word processors, PowerPoint and Visio plus many UML editors are the running context for Prototype. The Shape interface with Circle and Rectangle, plus a shape cache that holds prototypical instances and hands out clones, is the code example widely available online and used to practise the pattern. The same editors and file explorers show Composite: a Folder may hold Files or other Folders; a Picture may hold Shapes; JComponent/Container in Swing composes components uniformly — each works whether it holds one child or a deep tree.

Swing as a living pattern catalogue. Java Swing for graphical user interfaces is presented as a library that uses almost every GoF pattern in one place. Working with Swing components, containers, lists, tables and listeners exposes Composite (Container), Observer (Listener/Model), Factory and Abstract Factory (look-and-feel creation), Singleton (toolkit), Iterator (collections), Facade (entry components), Adapter and Decorator side by side in real code. Cloneable as a tagging interface and the IconAdapter that extends JComponent and holds a private Icon — implementing paintComponent by calling paintIcon — are two Java details inside that library that the lecture singles out.

Architecture that sits above patterns. Linux command pipelines (cat | grep | sort) illustrate the pipes-and-filters architecture that sits above patterns, and the GCC command that drives Scanner, Parser, NodeBuilder and CodeGenerator inside a compiler — handling code streams, parseTree, visual/source nodes, bytecode — is the canonical Facade example. Recognising which level (pattern vs. architecture) a problem belongs to is itself a design skill the lecture reinforces.

Shared resources and rule engines. Company name objects and random-number generators shared across an application are the two small examples used to motivate Singleton — extended in industry to configuration holders, loggers and registries. Payment handling where one purchase() call hides credit card, debit card, coupon and gift certificate rule evaluation — and the POSRuleEngineFacade that may hide Strategy objects, an interpreter or a commercial rule engine — is the business Facade example drawn from the textbook's NextGen case study. The same study's ServicesFactory accessed via Singleton and returning Adapters formed from an Abstract Factory family (IBMJavaPOSDevicesFactory vs. NCRJavaPOSDevicesFactory) shows how Adapter, Factory, Abstract Factory, Singleton and Facade combine in one industrial flow.

The everyday adapter. Electrical socket adapters used when visiting a country with a different socket are the everyday parallel for Adapter. Inside software the IconAdapter that extends JComponent, holds a private Icon, implements paintComponent by calling paintIcon and implements getPreferredSize by calling getIconWidth/getIconHeight, and is then added to a Frame, is the concrete code example. The same shape appears when JavaPOS driver classes such as com.ibm.pos.jpos.CashDrawer adapt native drivers to the standard jpos.CashDrawer interface, and when LocalProducts and DBProductsAdapter share the IProductsAdapter front.