1 / 4

Understanding Design Patterns: The Decorator and Strategy Patterns Explained

This guide delves into two important design patterns in software development: the Decorator and Strategy Patterns. The Decorator pattern allows you to dynamically attach additional responsibilities to objects without altering their structure, making it easier to extend functionalities like filtering input text or modifying behavior. The Strategy pattern offers a way to define interchangeable algorithms so that the method of processing can be changed without modifying the codebase, promoting flexibility and reusability. Learn how these patterns enhance code organization and adaptability.

mliss
Télécharger la présentation

Understanding Design Patterns: The Decorator and Strategy Patterns Explained

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Patterns from nanoGoogle I • Decorator • Attach responsibilities dynamically • Concrete class 'is-a' and 'has-a' decorator • Avoid rewriting existing code, write new code • BufferedReader and java.io classes • From string, from web, from … • Filter classes • Boolean: accept/reject word • Altering: remove punctuation, lowercase, …

  2. Decorator Details • Name: also-knowns-as Wrapper • Wrap existing object with more responsibilities • HFDP: tall, decaf, skim, latte • Forces: • Add responsibilities to objects without affecting other objects (and remove the responsibilities) • Extension by subclass impractical: class explosion or no access to parent class for subclassing

  3. Patterns from nanoGoogle II • Strategy • Change algorithm, policy without altering existing code, but by writing new code • Program to interface, not implementation • Algorithm varies independently from client • What to do when processing words • Count them, store them, dump them to disk • How to print results after processing words • XML, to file, standard output, …

  4. Strategy Details • Name: also known as Policy • Make algorithms/policies interchangeable • HFDP: how to quack, how to fly • Forces: • Re-use policies between contexts or change them at runtime • Context has-a policy, uses it, can change policy • Don't hardwire policy behavior into client

More Related