Patterns in Software Engineering-Lecture 3 Slides-Computer Engineering, Slides of Software Engineering

Download Patterns in Software Engineering-Lecture 3 Slides-Computer Engineering and more Slides Software Engineering in PDF only on Docsity! Patterns in Software Engineering Lecturer: Raman Ramsin L t 3ec ure GoF Design Patterns – Structural Department of Computer Engineering 1 Sharif University of Technology Patterns in Software Engineering – Lecture 3 GoF Structural Patterns Class/Object Adapter: Convert the interface of a class into another interface clients expect Adapter lets classes work together that couldn't . otherwise because of incompatible interfaces. Object Bridge: Decouple an abstraction from its implementation so that the two can vary independently. Composite: Compose objects into tree structures to represent whole- part hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly . Decorator: Attach additional responsibilities to an object dynamically. Façade: Provide a unified interface to a set of interfaces in a subsystem. Flyweight: Use sharing to support large numbers of fine-grained objects efficiently. Proxy: Provide a surrogate or placeholder for another object to Department of Computer Engineering 2 Sharif University of Technology control access to it. Patterns in Software Engineering – Lecture 3 Adapter (Class): Structure Department of Computer Engineering 5 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Adapter (Object): Structure Department of Computer Engineering 6 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Adapter (Class): Consequences lets Adapter override some of Adaptee's behavior, since Adapter is a subclass of Adaptee. introduces only one object, and no additional pointer indirection is needed to get to the adaptee. adapts Adaptee to Target by committing to a concrete Adapter class. As a consequence, a class adapter won't work when we want to adapt a class and all its subclasses. Department of Computer Engineering 7 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Bridge: Applicability Use the Bridge pattern when t t id t bi di b t b t tiyou wan o avo a permanen n ng e ween an a s rac on and its implementation; for example, when the implementation must be selected or switched at run-time. both the abstractions and their implementations should be extensible by subclassing; combine different abstractions and implementations and extend them independently. changes in the implementation of an abstraction should have no impact on clients; that is, their code should not have to be recompiled. (C++) you want to hide the implementation of an abstraction completely from clients. In C++ the representation of a class is visible in the class interface. you want to share an implementation among multiple objects Department of Computer Engineering 10 Sharif University of Technology and this fact should be hidden from the client. Patterns in Software Engineering – Lecture 3 Bridge: Structure Department of Computer Engineering 11 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Bridge: Consequences Decoupling interface and implementation. An implementation is not b d tl t i t foun permanen y o an n er ace. The implementation of an abstraction can be configured at run- time. It's even possible for an object to change its implementation at run-time. Improved extensibility. You can extend the Abstraction and Implementor hierarchies independently. Hiding implementation details from clients. You can shield clients from implementation details. Department of Computer Engineering 12 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Composite: Structure Department of Computer Engineering 15 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Composite: Typical Object Structure Department of Computer Engineering 16 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Composite: Consequences h li t d t i iti bj t it l t kw erever c en co e expec s a pr m ve o ec , can a so a e a composite object. makes the client simple. Clients can treat composite structures and individual objects uniformly and this simplifies their code , . makes it easier to add new kinds of components. Clients don't have to be changed for new Component classes. can make your design overly general. It makes it harder to restrict the components of a composite. If you want a composite to have only certain components, you can't rely on the type system to enforce those constraints for you. You'll have to use run-time checks instead. Department of Computer Engineering 17 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Decorator: Applicability Use the Decorator pattern to add responsibilities to individual objects dynamically and transparently that is without affecting other objects, , . for responsibilities that can be withdrawn . h t i b b l i i i ti l S tiw en ex ens on y su c ass ng s mprac ca . ome mes a large number of independent extensions are possible and would produce an explosion of subclasses. Department of Computer Engineering 20 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Decorator: Structure Department of Computer Engineering 21 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Decorator: Consequences More flexibility than static inheritance. A oids feat e laden classes high p in the hie a chv ur - u r r y. A decorator and its component aren't identical. f li l bjLots o tt e o ects. Department of Computer Engineering 22 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Façade: Applicability Use the Façade pattern when you want to provide a simple interface to a complex subsystem. there are many dependencies between clients and the implementation classes of an abstraction. you want to layer your subsystems. Use a facade to define an entry point to each subsystem level. Department of Computer Engineering 25 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Façade: Structure Department of Computer Engineering 26 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Façade: Consequences It shields clients from subsystem components, thereby reducing the number of objects that clients deal with, making the subsystem easier to use . It promotes weak coupling between the subsystem and its clients . It doesn't prevent applications from using subsystem classes if they need to Thus you can choose between . ease of use and generality. Department of Computer Engineering 27 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Flyweight: Applicability Use the Flyweight pattern when An application uses a large number of objects. Storage costs are high because of the sheer quantity of objects. Most object state can be made extrinsic. Many groups of objects may be replaced by relatively few shared objects once extrinsic state is removed. The application doesn't depend on object identity Since . flyweight objects may be shared, identity tests will return true for conceptually distinct objects. Department of Computer Engineering 30 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Flyweight: Structure Department of Computer Engineering 31 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Flyweight: Typical Object Structure Department of Computer Engineering 32 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Proxy: Class Hierarchy Department of Computer Engineering 35 Sharif University of Technology Patterns in Software Engineering – Lecture 3 Proxy: Applicability Use the Proxy pattern when a surrogate is needed: Remote proxy: provides a local representative for an object in a different address space. Virtual proxy: creates expensive objects on demand. Protection proxy: controls access to the original object. Smart reference: a replacement for a bare pointer that performs dditi l ti h bj t i da ona ac ons w en an o ec s accesse : counting the number of references to the real object so that it can be freed when there are no more references. loading a persistent object into memory when it's first referenced. checking that the real object is locked before it's accessed to Department of Computer Engineering 36 Sharif University of Technology ensure that no other object can change it. Patterns in Software Engineering – Lecture 3 Proxy: Structure Department of Computer Engineering 37 Sharif University of Technology