Structural patterns

Structural PatternDr. Himanshu Hora

SRMS College of Engineering & TechnologyBareilly (UP) INDIA

05/01/23Structural Pattern

1

Content

• History of Design Pattern• Definitions of Design Pattern• Types of Pattern• Adapter • Bridge• Composite• Decorator • Facade• Flyweight• Proxy • Benefits and Possible problems05/01/23 Structural Pattern 2

History of Design Pattern

• In 1994, Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides explained the usefulness of patterns and resulted in the widespread popularity of design patterns.

• These four authors together are referred to as the Gang of Four (GoF).

05/01/23 Structural Pattern 3

Definitions of Design Pattern

• Design patterns are recurring solutions to software design

problems you find again and again in real-world application development

OR• Design patterns represent solutions to problems that arise

when developing software within a particular contextOR

• Design patterns are standard solutions to common problems in software design


Types of Pattern

There are 3 types of pattern

• Creational: address problems of creating an object in a flexible way. Separate creation, from operation/use.

• Structural: address problems of using O-O constructs like inheritance to organize classes and objects

• Behavioral: address problems of assigning responsibilities to classes. Suggest both static relationships and patterns of communication (use cases)


Types of Pattern

Creational Patterns (concerned with abstracting the object-instantiation process)• Factory Method Abstract Factory Singleton• Builder PrototypeStructural Patterns

(concerned with how objects/classes can be combined to form larger structures)• Adapter Bridge Composite• Decorator Facade Flyweight• ProxyBehavioral Patterns

(concerned with communication between objects)• Command Interpreter Iterator• Mediator Observer State• Strategy Chain of Responsibility Visitor• Template Method


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

• Use the Adapter pattern when:– you want to use an existing class and its interface does not

match the one you need – you need to use several existing subclasses, but it's

impractical to adapt their interface by subclassing everyone. An object adapter can adapt the interface of its parent class


Adapter


Bridge

• Decouple an abstraction from its implementation so that the two can vary independently

• Use the Bridge pattern when: – you want run-time binding of the implementation – you want to share an implementation among multiple

objects


Bridge


Composite

• Compose objects into tree structures to represent whole-part hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly

• Use this pattern whenever you have "composites that contain components, each of which could be a composite".


Composite


Decorator

• Attach additional responsibilities to an object dynamically

• Decorators provide a flexible alternative to subclassing for extending functionality


Problems

• Several classes with a similar operation (method), but different behavior.

• We want to use many combinations of these behaviors


Example - Automated Hospital

• People come to the reception with problems

• They describe their problems

• A special doctoRobot is created that is specialized to treat their special situations.


Automated Hospital - Solution 1

DoctoRobot

Cure (p : Patient)

DentistRobot

Cure (p : Patient)

DermaRobot

Cure (p : Patient)

PsychoRobot

Cure (p : Patient)

DentistDermaRobot DentistPsychoRobot DermaPsychoRobot


Problems with solution-1

• Sometimes we don’t have multiple inheritance.

• Even if we have, if is problematic, and bad design.


A Better idea: Use Decorator

ConcreteComponent

Operation( )

ConcreteDecoratorAaddedState

Operation( )

ConcreteDecoratorB

Operation( )

Decorator

Operation( )

Component

Operation( )

component


Decorator in our case

DentistRobot

Cure (p : Patient)

DermaRobot

Cure (p : Patient)

PhsychoRobot

Cure (p : Patient)

DoctorRobotDecoratorinnerDoctor

Cure (p : Patient)

DoctoRobot

Cure (p : Patient)

component


Facade

• Provide a unified interface to a set of interfaces in a subsystem• Facade defines a higher-level interface that makes the

subsystem easier to use • Create a class that is the interface to the subsystem• Clients interface with the Facade class to deal with the

subsystem • It hides the implementation of the subsystem from clients• It promotes weak coupling between the subsystems and its

clients • It does not prevent clients from using subsystems class, should

it?


Facade


Flyweight

• Use sharing to support large numbers of fine-grained objects efficiently

• The pattern can be used when:– The program uses a large number of objects and– The program does not use object identity (==)


Flyweight


Proxy

• Provide a surrogate or placeholder for another object to control access to it.

• The proxy has the same interface as the original object• Virtual Proxy:

– Creates/accesses expensive objects on demand – You may wish to delay creating an expensive object until it

is really accessed – It may be too expensive to keep entire state of the object in

memory at one time


• Protection Proxy– Provides different objects different level of access to

original object

• Cache Proxy (Server Proxy)– Multiple local clients can share results from expensive

operations: remote accesses or long computations

• Firewall Proxy– Protect local clients from outside world


Proxy


Benefits• Flexible• Don’t have to foresee all combinations• Little objects

Possible problems• Performance• Decorators are not necessarily always cummutative

(surgeon and Anastasiolic)


Thank You


Dr. Himanshu HoraSRMS College of Engineering & Technology

Bareilly (UP) INDIA

Education

Structural patterns