Design Patterns + B3.2 Checkpoint
Explain Singleton, Factory and Observer, then integrate inheritance, polymorphism, abstraction and class relationships in a cumulative HL OOP check.
Patterns solve recurring design problems
- explain Singleton, Factory and Observer as solutions to recurring design problems;
- select a suitable pattern from a scenario and justify the match;
- retrieve and apply all B3.2 concepts;
- complete the planned 2027 case-study checkpoint on GAN training balance and mode collapse.
Rapid Recall Deck
Attempt each card first. If a term is new, flip and study it, then answer it again without looking. Mark only secure recall as “Know it”.
Three patterns you must be able to explain
Singleton
Use when: the application should share one coordinated instance, such as one configuration manager.
Risk: global shared state can make testing and dependencies harder if overused.
Factory
Use when: client code needs objects of different concrete types and creation logic should be centralized.
Benefit: calling code depends less on construction details.
Observer
Use when: several listeners must react when one subject produces an event or state change.
Benefit: the subject can notify subscribers without hard-coding each response.
Choose the pattern from the problem, not from the name
Match the design problem
A. A program should create PDFReport, CSVReport or HTMLReport from a requested format without spreading construction logic across the system.
B. A dashboard has several widgets that must update whenever a sensor publishes a new reading.
C. Every part of an application must read the same runtime configuration object.
A: Factory centralizes creation of different report types. B: Observer lets multiple subscribed widgets react to one sensor event. C: Singleton can provide one shared configuration instance when exactly one coordinated instance is required.
Centralize object creation
class TextReport:
def build(self):
return "text"
class PDFReport:
def build(self):
return "pdf"
class ReportFactory:
@staticmethod
def create(kind):
if kind == "text":
return TextReport()
if kind == "pdf":
return PDFReport()
return NoneTrace the factory
Predict the type and output produced by:
report = ReportFactory.create("pdf")
print(report.build())
create("pdf") returns a PDFReport object, so the output is pdf. The client requests the kind and does not construct the concrete class directly.
Patterns are tools, not rules
Read the Observer structure
class NewsFeed:
def __init__(self):
self.subscribers = []
def subscribe(self, listener):
self.subscribers.append(listener)
def publish(self, message):
for listener in self.subscribers:
listener.update(message)Explain the roles of the subject and observers in this design.
NewsFeed is the subject: it stores subscribers and publishes updates. Each listener is an observer expected to provide update(message). One publication can therefore notify multiple independent observers.
Pattern or overengineering?
A script reads one configuration value once and exits. Should Singleton automatically be added because “configuration often uses Singleton”?
No. The pattern should solve an actual recurring design problem. For a tiny one-use script, Singleton may add unnecessary global structure without a meaningful benefit.
Cumulative HL OOP practice
B3.2 cumulative Paper 2 mini-set
1. Explain how inheritance and method overriding can work together to produce dynamic polymorphism.
2. Explain how an abstract class can establish a common interface for subclasses.
3. A Playlist stores references to existing Song objects that can appear in other playlists. Explain the class relationship.
4. A system must notify several displays whenever one data source changes. Explain which design pattern is appropriate and why.
- A child inherits the shared interface and overrides a method; a common method call is dispatched at runtime to the implementation belonging to the actual child object.
- The abstract class defines required operations while leaving concrete implementations to subclasses, so client code can rely on one interface.
- Aggregation: the songs exist independently and are referenced rather than lifecycle-owned by one playlist.
- Observer: one subject can notify multiple subscribed displays when the source changes.
GAN generator/discriminator balance
Build a research note: GAN training balance
The generator learns to produce outputs that increasingly resemble real images and deceive the discriminator. The discriminator improves at distinguishing real training images from generated ones. Useful adversarial learning depends on neither side overwhelming the other for long periods; severe imbalance can make training unstable or uninformative. In mode collapse, the generator produces a narrow range of similar outputs instead of capturing the dataset’s diversity. Keep mitigation research evidence for the later deep case-study block.
Close the OOP block with evidence
OOP gap diagnosis
Choose one B3.2 area that still needs retrieval: inheritance, polymorphism, abstraction, composition/aggregation or patterns.
IA progress check
Record one implemented feature, one test result and one implementation choice you can justify in Criterion D.
Finish the learning cycle
IA — main task
Continue Criterion D development/testing and evidence logging. Make sure one implementation decision is explained rather than only described.
Paper 2 — short practice
Redo only the B3.2 checkpoint items you missed. Add one credible research source/mitigation note to the GAN training-balance section of your case-study research.
Checkpoint
Open the 2027 Case Study Hub and verify that your GAN note uses the official terms generator, discriminator, adversarial dynamic, training stability and mode collapse.