Download as PDF, PPTX
![Composite Check list 1. Ensure that your problem is about representing "whole-part" hierarchical relationships. 2. Consider the heuristic, "Containers that contain containees, each of which could be a container.” Divide your domain concepts into container classes, and containee classes. 3. Create a "lowest common denominator" interface that makes your containers and containees interchangeable. 4. All container and containee classes declare an "is a" relationship to the interface. 5. Child management methods [e.g. addChild(), removeChild()] should normally be defined in the Composite class.](https://image.slidesharecdn.com/parti-160225012459/75/Software-Design-Patterns-Part-I-Structural-Patterns-21-2048.jpg)
Uploaded bySergey Aganezov
Software Design Patterns. Part I :: Structural Patterns
The document outlines a workshop on software design patterns, covering creational, structural, and behavioral patterns, with a focus on structural patterns such as adapter, composite, and bridge. It explains how design patterns can enhance software development efficiency by addressing common issues and promoting code readability. The document also provides instructions for participating in JetBrains' student program and includes details for an upcoming meeting.
Software Design Patterns. Part I :: Structural Patterns
- 1.
- 2. Java / Android-- Intellij IDEA Python -- PyCharm C / C++ -- Clion Obj. C / Swift -- App Code C# -- ReSharper / Rider Php -- PhpStorm Ruby -- RubyMine Javascript -- WebStorm DBA -- DataGrip JetBrains student program jetbrains.com/student
- 3. • Install “Learn” plugin (link) • Complete the course (~15 minutes) •Answer the survey (link) • PROFIT!!! Get a chance to win $50 Amazon Vaucher from JetBrains
- 4.
- 5. Design patterns canspeed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.
- 6.
- 7.
- 8. Structural Design Patterns In Software Engineering,Structural Design Patterns are Design Patterns that ease the design by identifying a simple way to realize relationships between entities.
- 9. Structural Design Patterns • Adapter • Bridge •Composite • Decorator • Facade • Flyweight • Proxy
- 10. Structural Design Patterns • Adapter • Bridge •Composite • Decorator • Facade • Flyweight • Proxy
- 11.
- 12. Adapter Problem A component offerscompelling functionality that you would like to reuse, but its "view of the world" is not compatible with the philosophy and architecture of the system currently being developed.
- 13. Adapter Intent • Convert theinterface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. • Wrap an existing class with a new interface.
- 14.
- 15. Adapter Check list 1.Identify theplayers: the component(s) that want to be accommodated (i.e. the client), and the component that needs to adapt (i.e. the adaptee). 2.Identify the interface that the client requires. 3.Design a "wrapper" class that can match the adaptee to the client. 4.The adapter/wrapper class "has a" instance of the adaptee class. 5.The adapter/wrapper class "maps" the client interface to the adaptee interface.
- 16. Adapter Rules of thumb •Adapter makes things work after they're designed • Adapter is retrofitted to make unrelated classes work together. • Adapter provides a different interface to its subject. • Adapter is meant to change the interface of an existing object. • Adapter reuses an old interface. Remember that Adapter makes two existing interfaces work together as opposed to defining an entirely new one.
- 17.
- 18. Composite Problem Application needs tomanipulate a hierarchical collection of "primitive" and "composite" objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the "type" of each object before attempting to process it is not desirable.
- 19. Composite Intent • Compose objectsinto tree structures to represent whole-part hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. • Recursive composition when directories contain entries, each of which could be a directory
- 20.
- 21. Composite Check list 1. Ensurethat your problem is about representing "whole-part" hierarchical relationships. 2. Consider the heuristic, "Containers that contain containees, each of which could be a container.” Divide your domain concepts into container classes, and containee classes. 3. Create a "lowest common denominator" interface that makes your containers and containees interchangeable. 4. All container and containee classes declare an "is a" relationship to the interface. 5. Child management methods [e.g. addChild(), removeChild()] should normally be defined in the Composite class.
- 22. Composite Rules of thumb •Composite is usually traversed with Iterator. • Composite can let you compose a Mediator out of smaller pieces through recursive composition. • Composite's focus is not on embellishment but on representation.
- 23.
- 24. Bridge Problem "Hardening of thesoftware arteries" has occurred by using subclassing of an abstract base class to provide alternative implementations. This locks in compile-time binding between interface and implementation. The abstraction and implementation cannot be independently extended or composed.
- 25. Bridge Intent • Decouple anabstraction from its implementation so that the two can vary independently. • Publish interface in an inheritance hierarchy, and bury implementation in its own inheritance hierarchy. • Beyond encapsulation, to insulation
- 26.
- 27.
- 28. Bridge Use when • you want run-time binding of the implementation •you have a proliferation of classes resulting from a coupled interface and numerous implementations • you want to share an implementation among multiple objects • you need to map orthogonal class hierarchies
- 29. Bridge Check list 1. Decideif two orthogonal dimensions exist in the domain. 2. Design the separation of concerns: what does the client want, and what do the platforms provide. 3. Design a platform-oriented interface that is minimal, necessary, and sufficient. Its goal is to decouple the abstraction from the platform. 4. Define a derived class of that interface for each platform. 5. Create the abstraction base class that "has a" platform object and delegates the platform-oriented functionality to it.
- 30. Bridge Rules of thumb •Bridge is designed up-front to let the abstraction and the implementation vary independently. Adapter is retrofitted to make unrelated classes work together. • Adapter makes things work after they're designed; Bridge makes them work before they are.
- 31.