Design Patterns Simplified - Part 1

Explore how to support multiple bonus criteria in the EmployeeBenefits class, enabling grade-based and merit-based bonuses through FinanceCalculations.

Explore alternative designs for bonus calculations by adding criteria such as grade or merit, comparing if conditions versus inheritance under the open-closed principle, and examining ESOPs and other employee benefits.

Apply object composition to extract the changing bonus calculation from EmployeeBenefits, using a bonus calculator hierarchy with IBonusCalculator and a setBonusCalculator method to switch implementations, illustrating the strategy design pattern.

Define a family of algorithms as interchangeable bonus calculators through a common interface, encapsulating each in a class, with the context and clients setting the bonus calculator.

Identify varying parts and encapsulate them in their own classes to hide details and allow changes without affecting clients, using interface-based design and the strategy pattern.

Explore how a framework unifies multiple applications by centralizing common features, enabling uniform user interaction and efficient development through abstract interfaces and a factory method.

Learn how a test helper framework, via an abstract class, delegates datastore cleanup and input generation to derived data cleaner helpers, illustrating the abstract factory pattern.

Master the factory method and abstract factory pattern by defining interfaces to create objects, with concrete creators like XMLHelper and DBHelper producing XMLCleaner and XMLInputGenerator.

Contrast factory method and abstract factory patterns. Factory method uses derived creators in a base class; abstract factory declares creators to produce a family of products.

Compare factory method and abstract factory patterns, focusing on creator methods that instantiate objects, who calls them, and how each pattern controls and exchanges families of products.

Examine a ticketing example that grows with features—palace tours and toy trains—by extending the BasicTicket logic and using TicketProcessor and TicketApp, while illustrating the open-closed principle.

Show how inheritance creates ticket variants like BasicTicket and BasicPalaceTicket, uses polymorphism for printing, highlights class explosion, and introduces the decorator pattern as the solution.

Explore the decorator pattern by wrapping a basic ticket with optional features such as palace and toy train, extending cost and description through a common etiquette interface.

Illustrate the decorator pattern through sequence diagrams, showing a BasicTicket wrapped by PalaceDecorator for palace tours and by ToyTrainDecorator for multiple rides, with cost and description computed.

Explore how the decorator pattern attaches responsibilities to objects at runtime, enabling dynamic combinations like palace or toy train decorators for a basic ticket without heavyweight instantiation.

Apply decorator pattern to extend behavior by composition rather than inheritance, keeping code open for extension but closed for modification. Decorators wrap components and can be repeated for flexible functionality.

Explore state-based behavior with a keypad and library account example, illustrating locked and unlocked states, events, and transitions via diagrams and tables, plus how renewal and payments affect status.

design patterns simplified - part 1 introduces a state design pattern for an account system with active, canceled, and elite statuses, guiding issue and return books, and renewal payments.

The state design pattern encapsulates variation by moving behavior into active and cancelled state classes. The account delegates actions to its state and transitions on time elapsed or payment.

Explore implementing elite and alert statuses within the state design pattern, detailing how payment, renewal, and cancellation transition between active, elite, and cancelled states.

Learn the state design pattern: an account object changes behavior with its internal state via composition, while the context delegates to concrete states like ActiveState, CancelledState, and Elite.

Encapsulate what varies as state into its own classes, hiding the state objects from clients. Let the context compose with state objects to yield different behavior, illustrating composition over inheritance.

Examine how a library management example uses accounts, members, and email notifications to illustrate the observer pattern. Learn how to decouple notifications from state changes and update views on expiration.

Explore the observer pattern with a concrete subject and two observers. Learn how attach, detach, and notify keep observers in sync with state changes.

The observer pattern creates a one-to-many relationship where a subject notifies observers on state changes, and attach and detach keep the design loosely coupled.

Demonstrates using the tic tac toe example to illustrate the command pattern, encapsulating requests as command objects with an ICommand interface and execute method, wiring UI, model, and controller.

Explore command pattern, where the invoker uses a command interface with execute and mousePressed to delegate to GameViewController, which handles cellClicked and updates the interface with X or O.

Explore implementing undo using the command pattern by moving state storage from the receiver to the command object, enabling single or multiple undo in a game.

Explore implementing the command pattern in a game by mapping the invoker and receiver to game view controller and game model, creating a mark command with undo support.

Learn how to implement multiple undo levels by maintaining a stack of command objects and a command processor that executes and undoes actions, updating the user interface.

Encapsulate a request as an object to define the command pattern and enable parameterizing clients with different requests, while a command processor manages execute, undo, and redo.

Explain how the command pattern encapsulates what varies as a command object to isolate request from rest of the system. Applications supply their own command objects to execute specific requests.

Explore the adapter pattern by transforming an external bonus calculator into our existing design, showing how to integrate ABCBonusCalculator via an adapter while preserving IBonusCalculator and bonus computation.

Explore how the adapter pattern converts a class with a different interface into the target interface used by clients, enabling bonus calculations through an adopter that delegates to the adoptee.

Compare object adapters, which compose with an adaptee and delegate methods, to class adapters that inherit to call the adaptee’s methods directly.

Explore how the adapter pattern changes an interface to meet client expectations, using class and object adapters with ABCBonusCalculator to serve EmployeeBenefits and FinanceCalculations.

Explore a design pattern example in a drawing app that groups shapes, uses a Shape class for circle, rectangle, and triangle, and manages input and selection with a shape manager.

Learn a practical sequence where a user draws shapes—circle or rectangle—by mouse clicks, with the controller delegating to DrawShape, adding shapes to ShapeManager, and rendering via the shape's draw method.

Add grouping functionality to manipulate multiple shapes at once by introducing a Group that holds selected shapes. Update the controller and shape manager with addGroup and highlight the new group.

Select a group and apply color to all its ships by routing to the group object via the get selected group method, then highlight and recolor.

Rename the base class to Graphic and have Group inherit from Graphic, unifying shapes and groups under one interface while introducing isComposite and a default add method.

Demonstrates creating nested shape groups with a shape manager and controller, highlighting selections (circle, rectangle, triangle), forming G1 and G2, and applying recursive fill color to all members.

explains the composite pattern as a part-whole hierarchy that groups shapes into leaf and composite objects, enabling the controller to treat individual and group objects uniformly through the graphic component.

the composite pattern builds a tree of composite and leaf nodes with a component interface for the client, weighing cast vs base add for groups, balancing uniformity and type safety.

Explore the facade pattern through a concrete example that contrasts with the adapter and factory patterns, using a test framework across XML and relational databases.

Use a TestDataFacade to simplify the test data interface without altering factory or product classes, unifying setup and verification with setupTest and verifyTest.

Explore the facade pattern, which provides a unified, higher-level interface to a subsystem, simplifying usage and distinguishing it from the adapter pattern.

Explore how the facade pattern decouples the client from a complex subsystem by offering a simplified interface, while keeping access to lower-level interfaces and contrasting it with the adapter.