Module 6: Object-Oriented Design – Design Patterns

Software Engineering
Computer Science
Academic Year 2023/2024

Gerard Albà Soler

1
Contents
1. Introduction
• What will we learn
2. Object Oriented Design
- Design principles
- Design patterns
- Operation contract and Class diagram normalization
- Object responsibilities assignment
- Behavioral modeling. Sequence diagram and State diagram
- Software Architecture
- Components and Packages
1. Introduction
What will we learn?
OOA/D
Design

Design
Exercises
Patterns

OOA/D

Structural Behavioral

Creational
 1. Introduction
• Book References

ü Design Patterns: Elements of Reusable Object-Oriented Software. E Gamma

et al. Ed Addison Wesley professional computing series
ü Python: Master the Art of Design Pattern D Phillips et al. Ed Packt
Publishing
 2.2 Design Patterns
• Design patterns are built on top of design principles seen in the previous section.
• A design pattern in OOAD is a general solution to a problem that appears several
times in software development.
• Design patterns solve specific design problems in order to create more flexible,
reusable and quality systems.
 2.2 Design Patterns
• Patterns are not restricted to any domain or programming language.
• Each pattern describes a problem that is repeated over and over, as well as the
solution.
• Patterns are methods, documented in a catalog, that give us a systematic way to
approach problems:
ü GRASP: patterns of basic design principles (previous section in this Module 6)
ü GOF: "Design patterns : Elements of reusable object oriented software"
Authors Gamma, Helm, Johnson Vlissides are informally known as Gang of
Four.
 2.2 Design Patterns
• Patterns are classified under three main categories:
• Creational patterns
• Structural patterns
• Behavioral patterns

• The classification of patterns is done based primarily on how the objects get
created, how classes and objects are structured in a software application, and also
covers the way objects interact among themselves.
• It is not the aim of this course to learn about all the available patterns. But we will
show some examples of each category in the next sections.
 2.2 Design Patterns
Pattern category Description
Creational patterns • They work on the basis of how objects can be created
• They isolate the details of object creation
• Code is independent of the type of object to be created

• They design the structure of objects and classes so that they can compose to
achieve larger results
• The focus is on simplifying the structure and identifying the relationship
Structural patterns between classes and objects
• They focus on class inheritance and composition

• They are concerned with the interaction among objects and responsibility of
Behavioral patterns objects
• Objects should be able to interact and still be loosely coupled
 2.2 Design Patterns
GOF Patterns
2.2 Design Patterns
Behavioral patterns: Strategy

• Problem: Create a family of algorithms for a task and being able to decide which
one we chose at runtime.
• The strategy pattern is used when we have multiple algorithms for a specific task
and client decides the actual implementation to be used at runtime.
• It lets you define a family of algorithms, put each of them into a separate class,
and make their objects interchangeable.
 2.2 Design Patterns
Behavioral patterns: Strategy
• The Strategy pattern allows the behavior of an object to be selected dynamically at
runtime, providing flexibility, modularity, and testability. The key characteristics:
ü It defines a family of algorithms: the pattern allows you to encapsulate multiple
algorithms or behaviors into separate classes, known as strategies.
ü It encapsulates behaviors: each strategy encapsulates a specific behavior or
algorithm, providing a clean and modular way to manage different variations.
ü It enables dynamic behavior switching: enables clients to switch between different
strategies at runtime, allowing for flexible and dynamic behavior changes.
ü It promotes object collaboration: the pattern encourages collaboration between a
context object and strategy objects, where the context delegates the execution of a
behavior to a strategy object.
2.2 Design Patterns
Strategy: UML class diagram
 2.2 Design Patterns
Behavioral patterns: Strategy
Context
• The Context is a class or object that holds a
reference to a strategy object and delegates
the task to it.
• It acts as the interface between the client
and the strategy, providing a unified way to
execute the task without knowing the
details of how it’s done.
• The Context maintains a reference to a
strategy object and calls its methods to
perform the task, allowing for
interchangeable strategies to be used.
 2.2 Design Patterns
Behavioral patterns: Strategy
Strategy Interface
• The Strategy Interface is an interface or abstract
class that defines a set of methods that all
concrete strategies must implement.
• It serves as a contract, ensuring that all
strategies adhere to the same set of rules and
can be used interchangeably by the Context.
• By defining a common interface, the Strategy
Interface allows for decoupling between the
Context and the concrete strategies, promoting
flexibility and modularity in the design.
 2.2 Design Patterns
Behavioral patterns: Strategy

Concrete Strategies
• They are the various implementations of the
Strategy Interface. Each concrete strategy
provides a specific algorithm or behavior for
the task defined by the Strategy Interface.
• Concrete strategies encapsulate the details of
their respective algorithms and provide a
method for executing the task.
• They are interchangeable and can be selected
and configured by the client based on the
requirements of the task.
 2.2 Design Patterns
Behavioral patterns: Strategy

Client

• The Client is responsible for selecting and

configuring the appropriate strategy and
providing it to the Context.
• It knows the requirements of the task and
decides which strategy to use based on those
requirements.
• The client creates an instance of the desired
concrete strategy and passes it to the Context,
enabling the Context to use the selected
strategy to perform the task.
 2.2 Design Patterns
Behavioral patterns: Strategy
• Communication between the components occurs in a structured and decoupled manner:
ü Client to Context:
• The Client, which knows the requirements of the
task, interacts with the Context to initiate the task
execution.
• The Client selects an appropriate strategy based
on the task requirements and provides it to the
Context.
• The Client may configure the selected strategy
before passing it to the Context if necessary.
ü Context to Strategy:
• The Context holds a reference to the selected
strategy and delegates the task to it.
• The Context invokes a method on the strategy
object, triggering the execution of the specific
algorithm encapsulated within the strategy.
ü Strategy to Context:
• Once the strategy completes its execution, it
may return a result or perform any necessary
actions.
• The strategy communicates the result or any
relevant information back to the Context,
which may further process or utilize the result
as needed.
ü Strategy Interface as Contract:
• The Strategy Interface serves as a contract that
defines a set of methods that all concrete
strategies must implement.
• The Context communicates with strategies
through the common interface, promoting
interchangeability and decoupling.
2.2 Design Patterns
Strategy: case study Trading system
• We’ll implement a trading strategy system (in Python) using the Strategy Design Pattern.
• We aim to demonstrate the adaptability and flexibility of the pattern by encapsulating
different strategies: Moving Average and Mean Reversion, as interchangeable components.
2.2 Design Patterns
Strategy: case study Trading system

• Context: maintains a reference to one of

the concrete strategies and communicates
with this object only via the strategy
interface.
• Strategy Interface: Common to all concrete
strategies, declares a method the context
uses to execute a strategy.
• Concrete Strategies: Implement different
variations of an algorithm the context uses.
2.2 Design Patterns
Strategy: case study Trading system (in Python)

Strategy Interface
• We define first an abstract class Strategy that declares a method execute_strategy
common to all concrete strategies.
2.2 Design Patterns
Strategy: case study Trading system (in Python)

Concrete Strategies
• Implement concrete strategy classes ConcreteStrategyA and ConcreteStrategyB that
provide specific algorithm variations.
2.2 Design Patterns
Strategy: case study Trading system (in Python)
Context
• Develop a Context class that maintains a reference to one of the concrete strategies
and provides a method to execute the strategy.
2.2 Design Patterns
Strategy: case study Trading system (in Python)
Client
2.2 Design Patterns
Strategy: case study Trading system (in Python)
• The previous slides show the general case/setup of the pattern. For our trading
system, we could define specific trading algorithms as ConcreteStrategy (A and B).
 2.1 Design Principles
Activity 6.2.1
Our system draws a path (using an algorithm) in a map,
according to a selected transport among three choices (bus,
car or walk). We use the design pattern shown in the next
class diagram.
Which of the following are true about this design pattern:
A: It’s a strategy behavior pattern
B: If the algorithms where in the same class, they would
be more difficult to maintain and modify
C: If the algorithms where in the same class, this would
be large and more difficult to maintain
D: If the algorithms where in the same class, it would be
more difficult to add new transports (ex taxi)
 2.1 Design Principles
Activity 6.2.2
Which of the following statements are true for the next class diagram:

A: It’s a creational design pattern

B: It’s a structural design pattern
C: It’s a behavior design pattern
D: It’s one of the GRASP design principles
 2.1 Design Principles
Activity 6.2.3
Which of the following statements are true for the next class diagram:

A: The Context class has the responsibility of creating a reference to a specific strategy.
B: The Strategy class inherits the specific algorithm from ConcreteStrategy (A and B).
C: The Strategy class works as an interface, that is shared by the different algorithms.
D: The ConcreteStrategy (A and B) class is the one actually implementing the algorithm.
 2.2 Design Patterns
References
• You can learn more about Strategy Pattern (with Python examples) here:

https://youtu.be/WQ8bNdxREHU?si=pXsrl32MQB1Bhaqd
2.2 Design Patterns
Creational patterns: Factory

• Problem: Decoupling the process of creating objects from the clients that use
them.
• Using the factory pattern, a class will take the responsibility of creating objects.
2.2 Design Patterns
• A factory means: a class that is responsible for creating objects of other types.
• The class that acts as a factory has an object and its methods. The client calls this
method with some parameters; objects of desired types are created.
• So the question here really is, why do we need a factory when the client can directly
create an object? These are some benefits of using a factory:
ü The first advantage is loose coupling in which object creation can be independent of
the class implementation.
ü The client need not be aware of the class that creates the object which, in turn, is
utilized by the client. It is only necessary to know the interface, methods, and
parameters that need to be passed to create objects of the desired type. This
simplifies implementations for the client.
ü Adding another class to the factory to create objects of another type can be easily
done without the client changing the code. At a minimum, the client needs to pass
just another parameter.
 2.2 Design Patterns

Factory pattern Description

Simple Factory • This allows interfaces to create objects without exposing the object creation
logic.

• This allows interfaces to create objects, but defers the decision to the
Factory method subclasses to determine the class for object creation.

• It is an interface to create related objects without specifying/exposing their

classes.
Abstract Factory
• The pattern provides objects of another factory, which internally creates other
objects.
2.2 Design Patterns
Simple Factory

• UML class diagram of the pattern.

• The client class uses the Factory class,

which has the create_type() method.
• When the client calls the
create_type() method with the type
parameters, based on the parameters
passed, the Factory returns Product1
or Product2 objects.
2.2 Design Patterns
from abc import ABCMeta, abstractmethod
class Animal(metaclass = ABCMeta):
@abstractmethod
def do_say(self):
pass
class Dog(Animal):
def do_say(self):
print("Bhow Bhow!!")
class Cat(Animal):
def do_say(self):
print("Meow Meow!!")

## forest factory defined

class ForestFactory(object):
def make_sound(self, object_type):
return eval(object_type)().do_say()

## client code
if __name__ == '__main__':
ff = ForestFactory()
animal = input("Which animal should make_sound Dog or Cat?")
ff.make_sound(animal)
2.2 Design Patterns
Factory Method

• We define an interface to create objects, but instead of the factory being responsible for the
object creation, the responsibility is deferred to the subclass that decides the class to be
instantiated.
2.2 Design Patterns
Factory Method

• At the core of the Factory Method pattern is the concept of delegation.

• Instead of the client code directly creating objects (like in the Simple Factory pattern), it
delegates the responsibility to a Factory Method.
• This method resides in an abstract Creator class or interface, defining an interface for
creating objects.
• Concrete subclasses of the Creator implement this Factory Method, allowing them to
create specific instances of objects.
• This delegation promotes loose coupling between the client code and the objects it uses,
enhancing flexibility and maintainability.
 2.2 Design Patterns
Factory Method
• The Factory Method pattern has four essential components:
ü Creator: The Creator is an abstract class or interface. It declares the Factory Method,
which is essentially a method for creating objects. The Creator provides an interface for
creating products but doesn’t specify their concrete classes.
ü Concrete Creator: Concrete Creators are the subclasses of the Creator. They implement
the Factory Method, deciding which concrete Product class to instantiate. In other
words, each Concrete Creator specializes in creating a particular type of product.
ü Product: The Product is another abstract class or interface. It defines the type of
objects the Factory Method creates. These products share a common interface, but
their concrete implementations can vary.
ü Concrete Product: Concrete Products are the subclasses of the Product. They provide
the specific implementations of the products. Each Concrete Product corresponds to
one type of object created by the Factory Method.
 2.2 Design Patterns
Factory Method: case study Social media profiles (in Python)

• Consider that we would like to create profiles of different types on social networks such as
LinkedIn and Facebook for a person or company.
• Now, each of these profiles would have certain sections.
ü In LinkedIn, you would have a section on patents that an individual has filed or
publications s/he has written.
ü On Facebook, you'll see sections in an album of pictures of your recent visit to a
holiday place.
ü Additionally, in both these profiles, there'd be a common section on personal
information.
• We want to create profiles of different types with the right sections being added to that
profile.
 2.2 Design Patterns
Factory Method: case study Social media profiles (in from abc import ABCMeta, abstractmethod

Python) class Section(metaclass=ABCMeta):

@abstractmethod
def describe(self):
• In the following Python example, we would start by pass
defining the Product interface. class PersonalSection(Section):
def describe(self):
• We will create a Section abstract class that defines print("Personal Section")

how a section will be. We will keep it very simple class AlbumSection(Section):
and provide an abstract method, describe(). def describe(self):
print("Album Section")

• We then create multiple ConcreteProduct classes, class PatentSection(Section):

def describe(self):
PersonalSection, AlbumSection, PatentSection, and print("Patent Section")
PublicationSection. These classes implement the
describe() abstract method and print their class PublicationSection(Section):
def describe(self):
respective section names. print("Publication Section")
 2.2 Design Patterns
class Profile(metaclass=ABCMeta):
def __init__(self):
• We create a Creator abstract class that is named Profile.
self.sections = []
• This Profile (Creator) abstract class provides a factory self.createProfile()
@abstractmethod
method, createProfile().
def createProfile(self):
• The createProfile() method should be implemented by
pass
ConcreteClass to actually create the profiles with appropriate def getSections(self):
sections. return self.sections
def addSections(self, section):
• The Profile abstract class is not aware of the sections that self.sections.append(section)
each profile should have. For example, a Facebook profile
should have personal information and album sections. So we class linkedin(Profile):
def createProfile(self):
will let the subclass decide this. self.addSections(PersonalSection())
self.addSections(PatentSection())
• We create two ConcreteCreator classes, linkedin and self.addSections(PublicationSection())
facebook. Each of these classes implement the createProfile()
abstract method that actually creates (instantiates) multiple class facebook(Profile):
def createProfile(self):
sections (ConcreteProducts) at runtime.
self.addSections(PersonalSection())
self.addSections(AlbumSection())”
 2.2 Design Patterns
• In the main code, we determine which Creator class to instantiate in order to create a
choosen profile.
• If we now run the code, it'll first ask to enter the name of the profile that you'd like to create.
• If we say Facebook. It then instantiates the facebook (ConcreateCreator) class. This internally
creates ConcreteProduct(s), that is, it instantiates PersonalSection and AlbumSection.
• If Linkedin is chosen, then PersonalSection, PatentSection, and PublicationSection are created.

if __name__ == '__main__':
profile_type = input("Which Profile you'd like to create? [LinkedIn or FaceBook]")
profile = eval(profile_type.lower())()
print("Creating Profile..", type(profile).__name__)
print("Profile has sections --", profile.getSections())
 2.2 Design Patterns
References
• You can learn more about Strategy Pattern (with Python examples) here:

https://youtu.be/s_4ZrtQs8Do?si=Bqs3nNUBMQuzsJXU
 2.1 Design Principles
Activity 6.2.4
Which of the following are true about the Factory Method design pattern:

A: It’s a structural behavior pattern

B: It decouples client code from the concrete classes, reducing dependencies and
enhancing code stability
C: It allows for the creation of objects without specifying their exact class, making the
code more flexible and maintainable
D: New product classes can be added without modifying existing code, promoting an
open-closed principle (open for extensions, closed for modifications)
 2.1 Design Principles
Activity 6.2.5
Consider a design pattern that includes a
Creator class as shown in the code on the right.

Which of the following statements are true:

A: We will have to implement create_localizer()
methods (the Factory Method) to create
localizers in the subclasses of this parent class
B: A Creator is typically a class used in the
Decorator design pattern
C: A Creator is used in some behavior design
patterns
D: The Factory Method pattern uses a Creator
class to implement the method that defines the
product
2.2 Design Patterns
Structural patterns: Decorator

• Problem: dynamically attach new behaviors to an object at runtime without

changing their implementation (its class).
• The decorator pattern (or wrapper) allows us to dynamically attach new
behaviors to objects without changing their implementation by placing these
objects inside the wrapper objects that contains the behaviors. It is not
equivalent to the inheritance because the new feature is added only to that
particular object, not to the entire subclass.
2.2 Design Patterns
Structural patterns: Decorator

• In other words, it enables you to “decorate” or enhance objects by adding new

functionalities without modifying their structure.
• It is much easier to implement decorator method in Python because of its built-in
feature. We will first study the classic decorator pattern, and later in this section
we will see a different way in Python of doing it.
 2.2 Design Patterns
Structural patterns: Decorator
• A decorator allows us to dynamically add functionality and behavior to an object without
affecting the behavior of other existing objects within the same class. We use inheritance to
extend the behavior of the class.
ü Decorator patterns allow a user to add new functionality to an existing object without
altering its structure. So, there is no change to the original class.
ü The decorator is a structural pattern, which provides a wrapper to the existing class.
ü The decorator uses abstract classes or interfaces to implement the wrapper.
ü Decorators create decorator classes, which wrap the original class and supply additional
functionality by keeping the class methods’ signature (name and parameters) unchanged.
ü Decorator design patterns are most frequently used for applying single responsibility
principles since we divide the functionality into classes with unique areas of concern.
 2.2 Design Patterns
Below are some examples of use:
ü Extending Functionality: when we have a base component with basic functionality,
but we need to add additional features or behaviors to it dynamically without altering
its structure. Decorators allow us to add new responsibilities to objects at runtime.
ü Multiple Combinations of Features: when we want to provide multiple combinations
of features or options to an object. Decorators can be stacked and combined in
different ways to create customized variations of objects, providing flexibility to users.
ü Legacy Code Integration: when working with legacy code or third-party libraries where
modifying the existing codebase is not feasible or desirable, decorators can be used to
extend the functionality of existing objects without altering their implementation.
ü GUI Components: in graphical user interface (GUI) development, decorators can be
used to add additional visual effects, such as borders, shadows, or animations, to GUI
components like buttons, panels, or windows.
2.2 Design Patterns
Example of a system problem:

ü Suppose we are building a coffee shop application where customers can order
different types of coffee.
ü Each coffee can have various optional add-ons (toppings) such as milk, sugar,
whipped cream, etc.
ü We want to implement a system where we can dynamically add these add-ons
to a coffee order without modifying the coffee classes themselves.

• Using the decorator pattern allows us to add optional features (add-ons) to coffee
orders dynamically without altering the core coffee classes.
• This promotes code flexibility, scalability, and maintainability as new add-ons can
be easily introduced and combined with different types of coffee orders.
 2.2 Design Patterns
Decorator UML diagram
1. Create an interface.
2. Create concrete classes implementing
the same interface.
3. Create an abstract decorator class
implementing the above same interface.
4. Create a concrete decorator class
extending the above abstract decorator
class.
5. Now use the concrete decorator class
created above to decorate interface
objects.
 2.2 Design Patterns
• Component Interface: this is an abstract class or interface that defines the common
interface for both the concrete components and decorators. It specifies the operations
that can be performed on the objects.
• Concrete Component: these are the basic objects or classes that implement the
Component interface. They are the objects to which we want to add new behavior or
responsibilities.
• Decorator: this is an abstract class that also implements the Component interface and has
a reference to a Component object. Decorators are responsible for adding new behaviors
to the wrapped Component object.
• Concrete Decorator: These are the concrete classes that extend the Decorator class. They
add specific behaviors or responsibilities to the Component. Each Concrete Decorator can
add one or more behaviors to the Component.
2.2 Design Patterns
Decorator: coffee example (in Java)

Component interface
• This is the interface Coffee representing the component.
• It declares two methods getDescription() and getCost() which must be implemented
by concrete components and decorators.
2.2 Design Patterns
Decorator: coffee example (in Java)

Concrete Component
• PlainCoffee is a concrete class
implementing the Coffee interface.
• It provides the description and
cost of plain coffee by
implementing the
getDescription() and getCost()
methods.
2.2 Design Patterns
Decorator: coffee example (in Java)

Decorator
• CoffeeDecorator is an abstract class
implementing the Coffee interface.
• It maintains a reference to the
decorated Coffee object.
• The getDescription() and getCost()
methods are implemented to
delegate to the decorated coffee
object.
 2.2 Design Patterns
Decorator: coffee example (in Java)

Concrete Decorators
• CoffeeDecorator is an abstract class
implementing the Coffee interface.
• MilkDecorator and SugarDecorator are
concrete decorators extending
CoffeeDecorator.
• They override getDescription() to add the
respective decorator description to the
decorated coffee’s description.
• They override getCost() to add the cost of
the respective decorator to the decorated
coffee’s cost.
2.2 Design Patterns
Decorator: coffee example (in Java)
 2.2 Design Patterns
• Benefits of using decorator design patterns:
ü Open-Closed Principle: classes should be open for extension but closed for modification. This
means you can introduce new functionality to an existing class without changing its source code.
ü Flexibility: It allows to add or remove responsibilities (i.e., behaviors) from objects. This flexibility
makes it easy to create complex object structures with varying combinations of behaviors.
ü Reusable Code: Decorators are reusable components. You can create a library of decorator
classes and apply them to different objects and classes as needed, reducing code duplication.
ü Composition over Inheritance: unlike inheritance, that can lead to a large and les flexible class
hierarchy, the decorator uses composition. You can compose objects with decorators to achieve
the desired functionality, avoiding the drawbacks such as tight coupling and rigid hierarchies.
ü Dynamic Behavior Modification: Decorators can be applied or removed at runtime, providing
dynamic behavior modification for objects. This is particularly useful when you need to adapt an
object’s behavior based on changing requirements or user preferences.
ü Clear Code Structure: The Decorator pattern promotes a clear and structured design to
understand how different features and responsibilities are added to objects.
 2.2 Design Patterns
ü The decorator design pattern can be useful in Python, but there are other better options.
ü In Python, there are more efficient ways of implementing the same solution.
ü Monkey-patching in Python refers to these dynamic (or run-time) modifications of a class or module.
In Python, we can actually change the behavior of code at run-time.

ü Not to be confused with Python decorators, which is a language feature for dynamically modifying a
function or class. Python Decorators are an example of monkey-patching.
ü Design patterns became famous in 1994 publication of GOF Design Patterns. In 2003, the Python core
developers re-used the term decorator for an unrelated feature they were adding (to Python 2.4).
 2.2 Design Patterns
References
• The video explains the efficient implementation of the decorator design pattern in Python.

https://youtu.be/QH5fw9kxDQA?si=hZteiJjD5ICv0U-J
 2.2 Design Patterns
Decorator: case study Game Characters abilities
• Consider a scenario in game design where different
characters possess a unique set of abilities.
• As the game evolves, we need to add new abilities.
• We’ll use game character abilities, such as
the DoubleDamageDecorator, FireballDecorator,
and InvisibilityDecorator, as examples.
• Characters can have different combinations of these
abilities at any given moment.
• We will implement the decorator design pattern to
enhance a character’s abilities. By dynamically
applying decorators, such as Double Damage and
Invisibility, to a basic character, we create a special
character with combined powers.
2.2 Design Patterns
Decorator: case study Game Characters abilities (in Python)

Component
• The Component is the base
interface that defines the core
behavior that can be enhanced.
• In our example, it represents the
game character with a basic
attack method.
2.2 Design Patterns
Decorator: case study Game Characters abilities (in Python)

Concrete Component
• Concrete Components are the basic game characters to which we can add
special abilities. In this step, we create the basic character class.
 2.2 Design Patterns
Decorator: case study Game Characters abilities (in Python)
Decorator

• The Decorator is an abstract

class that also implements the
Component interface.
• It has a reference to a
Component object and adds its
specific behavior to the
component’s core.
• In this step, we create the
abstract decorator class.
 2.2 Design Patterns
Decorator: case study Game Characters abilities (in Python)

Concrete Decorator
• Concrete Decorators are classes
that extend the Decorator
abstract class, implementing
specific behaviors.
• In this step, we create concrete
decorator classes for special
character abilities, such as
Double Damage.
 2.2 Design Patterns
Decorator: case study Game Characters abilities (in Python)

Client
 2.1 Design Principles
Activity 6.2.6
The UML diagram shows a design pattern for a system drawing shapes. We’re going to create a Shape
interface and concrete classes implementing the Shape interface. We will also create an abstract
decorator class ShapeDecorator implementing the Shape interface and having the Shape object as its
instance variable.
Which of the following are true:

A: It’s a decorator structural pattern

B: Rectangle class and Circle class Will be
concrete classes implementing Shape
C: RedShapeDecorator is a concrete class
implementing Shape
D: All the above are correct
 2.1 Design Principles
Activity 6.2.7
Assume we are using a Decorator design pattern (a wrapper) for our system. Fill the table with the
corresponding task or function for each of the classes of objects in the Decorator pattern structure.

a) It declares the common interface for both

Class Task
wrappers and wrapped objects.
b) It defines the basic behavior, which can be Component a)
altered by decorators. Is the class of objects
being wrapped. Concrete Component
c) It defines extra behaviors that can be added
to components dynamically. It overrides
Decorator
methods of the base.
d) It can contain both concrete components
and decorators. It is an abstract class that
Concrete Decorator
delegates all operations to the wrapped
object.
 2.1 Design Principles
Activity 6.2.8
Which of the following statements are true for
the next class diagram:

A: It’s a creational design pattern

B: Component defines an interface for the
objects to be dynamically extended
C: ConcreteDecorator adds responsibilities
to the component
D: It’s a pattern that allows for the creation
of objects without specifying their exact
class, making the code more flexible and
maintainable