Week 3a Structural Design Patterns PDF
Document Details
Uploaded by SweepingArcticTundra565
Tags
Summary
This document provides an overview of structural design patterns in software engineering. It covers different patterns, such as Adapter, Bridge, Composite, Decorator, Facade, and Flyweight, along with examples and explanations.
Full Transcript
Structural Design Patterns XBSE2034 Software Design Recap What is the Behavioral Patter? Recap What are some examples of the Behavioral Pattern? Structural Design Patterns Structural patterns explain how to assemble objects and classes into larger structures while keeping...
Structural Design Patterns XBSE2034 Software Design Recap What is the Behavioral Patter? Recap What are some examples of the Behavioral Pattern? Structural Design Patterns Structural patterns explain how to assemble objects and classes into larger structures while keeping these structures flexible and efficient. Adapter Adapter Adapter Adapter Adapter So, when should you use the Adapter pattern? class when you want to use some existing class, but its interface isn’t compatible with the rest of your code. pattern when you want to reuse several existing subclasses that lack some common functionality that can’t be added to the superclass. Adapter Example Bridge Bridge Bridge Bridge Bridge Bridge Bridge So, when should you use the Bridge pattern? when you want to divide and organize a monolithic class that has several variants of some functionality (for example, if the class can work with various database servers). when you need to extend a class in several orthogonal (independent) dimensions. if you need to be able to switch implementations at runtime. Bridge Examples Composite Composite Composite Composite Composite So, when should you use the Composite pattern? when your collection has a complex data structure under the hood, but you want to hide its complexity from clients (either for convenience or security reasons).to reduce duplication of the traversal code across your app. when your collection has a complex data structure under the hood, but you want to hide its complexity from clients (either for convenience or security reasons). when you want your code to be able to traverse different data structures or when types of these structures are unknown beforehand. Composite Decorator Decorator Decorator Decorator Decorator Decorator Decorator Decorator Decorator So, when should you use the Decorator pattern? when you need to be able to assign extra behaviors to objects at runtime without breaking the code that uses these objects. when it’s awkward or not possible to extend an object’s behavior using inheritance. Example 1 – Christmas Tree decoration Example 2 – Assault gun Decorator Facade Facade Imagine that you must make your code work with a broad set of objects that belong to a sophisticated library or framework. Facade A facade is a class that provides a simple interface to a complex subsystem which contains lots of moving parts. A facade might provide limited functionality in comparison to working with the subsystem directly. However, it includes only those features that clients really care about. Facade So, when should you use the Facade pattern? when you need to have a limited but straightforward interface to a complex subsystem when you want to structure a subsystem into layers. Facade Flyweight Flyweight Flyweight Flyweight Flyweight Flyweight So, when should you use the Flyweight pattern? when your program must support a huge number of objects which barely fit into available RAM. Flyweight Example Proxy Proxy Proxy Proxy Proxy So, when should you use the Proxy pattern? when you have a heavyweight service object that wastes system resources by being always up, even though you only need it from time to time. when you want only specific clients to be able to use the service object; for instance, when your objects are crucial parts of an operating system and clients are various launched applications (including malicious ones) when the service object is located on a remote server. when you want to keep a history of requests to the service object. when you need to cache results of client requests and manage the life cycle of this cache, especially if results are quite large. when you need to be able to dismiss a heavyweight object once there are no clients that use it. Proxy Example