Module 3: Behavioral Patterns
This page aggregates the generated reference routes used by the learner-facing module.
- Semester:
semester-03-software-design - App:
foundations
Read only if stuck
- HF: Designing the Duck Behaviors
- HF: Integrating the Duck Behaviors
- HF: Testing the Duck Code
- HF: Speaking of Design Patterns
- HF: Overheard in the Next Cubicle
- HF: Tools for Your Design Toolbox (Strategy)
- HF: Exploring Strategy (MVC)
- HF: 8 The Template Method Pattern
- HF: Let's Abstract That Coffee and Tea
- HF: Template Method Pattern Defined
- HF: Hooked on Template Method
- HF: Template Methods in the Wild
- GoF: Strategy Applicability
- GoF: Strategy Sample Code
- GoF: Strategy Known Uses
- GoF: Template Method Implementation
- Refactoring: Replace Conditional with Polymorphism (Part 1)
- Refactoring: Replace Conditional with Polymorphism (Part 2)
- Refactoring: Replace Type Code with Subclasses
- HF: The Observer Pattern
- HF: Publishers + Subscribers = Observer Pattern
- HF: Observer Pattern Class Diagram
- HF: The Power of Loose Coupling
- HF: Implementing the Subject Interface in WeatherData
- HF: Power Up the Weather Station
- HF: Coding the Life-Changing Application
- HF: Tools for Your Design Toolbox (Observer)
- GoF: Observer Collaborations
- GoF: Observer Implementation
- GoF: Observer Sample Code
- Good Code Bad Code: Invalid States
- HF: 6 The Command Pattern
- HF: The Command Pattern Defined
- HF: Assigning Commands to Slots
- HF: More Uses of the Command Pattern -- Logging Requests
- HF: Memento (Leftover Patterns)
- GoF: Command Class and Subclasses
- GoF: Command Implementation
- GoF: Command Known Uses
- Refactoring: Replace Function with Command
- Refactoring: Replace Command with Function
- HF: 10 The State Pattern
- HF: The New Design
- HF: Implementing Our State Classes
- HF: Implementing More States
- HF: The State Pattern Defined
- GoF: State Consequences
- GoF: State Known Uses
- OOAD: FSM -- A Simple Example
- OOAD: Requirements Analysis with FSMs
- OOAD: Transitioning Between States
- OOAD: State Classes to Observer Pattern
- OOAD: Replacing Event Conditionals with Polymorphism
- OOAD: Features of the State Pattern to Consequence
- Refactoring: Decompose Conditional
- Refactoring: Repeated Switches
- Clean Code: Switch Statements
- HF: 9 The Iterator and Composite Patterns
- HF: What's the Problem with Two Menu Representations?
- HF: Can We Encapsulate the Iteration?
- HF: The Single Responsibility Principle
- HF: Meet Java's Iterable Interface
- HF: Writing the Enumeration/Iterator Adapter
- HF: Chain of Responsibility
- GoF: Encapsulating Access and Traversal
- GoF: Iterator Class and Subclasses
- GoF: Encapsulating the Analysis (Visitor motivation)
- GoF: Visitor Class and Subclasses
- GoF: 5 Behavioral Patterns (intro)
- GoF: Chain of Responsibility Implementation
- GoF: Chain of Responsibility Sample Code
- GoF: Chain of Responsibility Known Uses
- GoF: Iterator Implementation
- GoF: Iterator Sample Code (Part 1)
- GoF: Iterator Sample Code (Part 2)
- GoF: Iterator Known Uses
- GoF: Visitor Applicability
- GoF: Visitor Implementation
- GoF: Visitor Sample Code
- HF: Logging Requests
Optional deep dive
- HF: King of Compound Patterns (MVC)
- HF: Using MVC to Control the Beat
- HF: Better Living with Patterns
- HF: Organizing Design Patterns
- GoF: Designing for Change (Part 1)
- GoF: How to Select a Design Pattern
- GoF: Objects as Arguments (Command/Visitor connection)
- GoF: Decoupling Senders and Receivers
- Refactoring: Code Smells -- Alternative Classes with Different Interfaces