INDIVIDUAL ASSIGNMENT

SECTION 1
TECHNOLOGY PARK MALAYSIA

CT070-3-3-DPAT

DESIGN PATTERNS

APU3F2302SE

HAND OUT DATE: 13 APRIL 2023

HAND IN DATE: 23 MAY 2023

WEIGHTAGE: 20%

LECTURER: ASSOC. PROF. DR. MUHAMMAD EHSAN RANA

STUDENT NAME: MARWAH ABDULRAHMAN AL-KERBASH (TP061874)

Table of Contents
1.0 Abstract....................................................................................................................................1

2.0 Introduction..............................................................................................................................2

3.0 Literature review.....................................................................................................................4

4.0 Simpler Solution.......................................................................................................................8

4.1 Scenario..................................................................................................................................8

4.2 Class Diagram........................................................................................................................8

4.3 Java Implementation..............................................................................................................9

5.0 Refined Solution................................................................................................................13

5.1 Design issues in simple solution..........................................................................................13

5.2 Applied design patterns........................................................................................................14

5.3 Refined class diagram..........................................................................................................16

5.4 Refined Java implementation...............................................................................................16

6.0 References...............................................................................................................................19

Table of Figures

Figure 1: Design Parts (Josikakar, 2021).........................................................................................2

Figure 2: Coupled Patterns in Masuda et al (Bieman).....................................................................7
Figure 3: Class Diagram - initial design..........................................................................................8
Figure 4: Code snippets for main method and menu() method.......................................................9
Figure 5: Code snippets for order() method....................................................................................9
Figure 6: Code snippets for selecting ice cream topping...............................................................10
Figure 7: Code snippets for payment() method.............................................................................10
Figure 8: Code snippets for ice cream class.................................................................................11
Figure 9: Code snippets for child class that inherits Waffle class.................................................11
Figure 10: Code snippets for add topping methods.......................................................................12
Figure 11: Code snippets for payment methods............................................................................12
Figure 12: Figure 12: Class Diagram - Refined Design................................................................15
Figure 13: Code snippets for ToppingDecorator class..................................................................16
Figure 14: Code snippets for Caramel decorator class..................................................................16
Figure 15: Code snippets for PaymentStrategy interface..............................................................17
Figure 16: Code snippets for CreditCardStrategy.........................................................................17
1.0 Abstract
High coupling and low coupling are two significant object-oriented design principles that aid in
the creation of flexible, reusable, and feasible software. The level of reliance or connection
among various parts of a structure, which might include classes, methods, or modules, is referred
to as coupling. A change in one component has a large impact on a number of others, causing the
whole structure multifaceted, rigid, and fragile. Because the components are loosely coupled and
may operate separately, the system is simple, adaptable, and robust. Hence, this report will
discuss about what these terms mean, why they are important, and how to apply them to the
objects using prevalent design patterns and testing techniques. The first section of the report will
include introduction to the issue, literature review, and designed a simple high coupling
application along with its refined solution. For the refined solution Decorator and Strategy
pattern have been selected to solve the issue in the current proposed application. A java code
snippets are included where necessary and to visualize the structure of the application the class
diagram has been created. In the second section of the report will discuss about the methodology
and analysis of the results.

1|Page
2.0 Introduction

The Design stage of the Software Development Life Cycle is responsible for producing a
solution to an issue specified in the SRS (Software Requirement Specification) file. The design
phase produces a Software Design Document (SDD).

Coupling and cohesion are two fundamental concepts in software engineering that are used to
assess the design quality of a software system.

The level of interconnection among the software components is referred to as coupling. Modules
with high coupling have strong connections, and modifications in a single module might impact
other modules. Modules with low coupling are autonomous, and modifications in a single
module have no effect on the other modules (Josikakar, 2021).

Coupling and cohesion are crucial variables that influence a software system's reliability,
flexibility, and dependability. A system with high coupling and low cohesion can be hard to
modify as well as examination, whereas a system with low coupling and high cohesion is simpler
to maintain and increase (Josikakar, 2021).

As it shows in the figure below, design is essentially a two-part continuous procedure. The first
component is Conceptual Design, which informs the client about what the whole thing will do.
The second step is technical design, enable system builders to comprehend the real hardware and
software required to fix the clients issue (Josikakar, 2021).

2|Page
 Figure 1: Design Parts (Josikakar, 2021)

Advantages of Low Coupling (Josikakar, 2021):

Improved maintainability: Because low coupling decreases the effect of modifications in

one module on other modules, particular parts can be modified or replaced with no
impacting the whole system.
Enhanced modularity: Because of the low coupling, modules can be created and verified
independently, enhancing code flexibility and reusability.
Better scalability: Low coupling makes simpler to add new modules and remove old
ones, making it simpler to expand the structure as required.

Disadvantages of High Coupling (Josikakar, 2021):

High coupling raises interconnection among modules, causing the whole thing harder and
more complicated to comprehend.
Reduced flexibility: Because of the high coupling, it is hard to modify or substitute
particular parts with no impacting the system as a whole.
Reduced modularity: High coupling causes developing and testing components
independently harder, thereby decreasing code modularity and reusability.

3|Page
3.0 Literature review

Object-oriented (OO) design patterns are groups of interrelated classes that are used for a
specific purpose. A design pattern is an element of structure in a pattern-based system, similar to
how an operation is a fundamental unit in a function-based system (Bieman).

A procedural programme or a class is a structural unit in an OO system that is not pattern-based.

When developers handle patterns as structural units, they must deal with problems like coupling
and cohesion at a higher level of abstraction (Bieman).

We used the following process to search the available literature explaining particular pattern
applications for instances of pattern coupling (Bieman):

1. Search for instances of interrelated patterns in the most recent design pattern applications
literature.

2. Create a list of all examples of Gamma et al design patterns that you can find in the literature.

3. Make a sub-list of all pattern categories utilised as pairs or various sets that interact Gamma et
al patterns.

4. Sort the list by coupling type (tightly compared to loosely coupled) and communication type
(intersection, structure, or embedding), providing an explanation for each grouping.

5. Assess the discovered situations of coupled patterns on the basis of appealing software
qualities (maintenance, factorability, reusability, as well as simple implementation), providing
justification for each grouping.

6. Analyse the data to gain a better understanding of the pattern coupling methods that, in
overall, contribute to design "goodness" while others ought to be utilised only to meet particular
application requires.

We restricted ourselves to coupled pattern groups that are entirely made up of patterns identified
by Gamma et al.

4|Page
The 23 Gamma et al OO patterns comprise the study pattern set. The patterns are divided into
three major groups and are listed below with descriptions taken from Gamma et al (Bieman):

 Creational Pattern:
Factory Method: Define an interface for creating an object, but let subclasses decide
which class to instantiate.
Abstract factory: Provide an interface for creating families of related or dependent objects
without specifying their concrete classes.
Builder: Separate the construction of a complex object from its representation so that the
same construction process can produce multiple representations."
Prototype: Specify the types of objects to create using a prototypical instance, and copy
this prototype to create new objects."
Singleton: Ensure that a class has only one instance and provides a global point of
contact.
 Structural Patterns
Adapter: Convert a class's interface into another interface that clients expect.
Bridge: Decouple an abstraction from its implementation so that the two can vary
independently.
Composite: Build objects into tree structures to represent part-whole hierarchies.
Decorator: Attach additional responsibilities to an object dynamically.
Façade: a unified interface to a set of interfaces in a subsystem.
Flyweight: Use sharing to efficiently support a large number of fine-grained objects.
Proxy: Serve as a surrogate or placeholder for another object in order to control access to
it.
 Behavioral Patterns
Chain of Responsibility: Refrain from coupling the inquiry's sender to its receiver...
Chain receive items and pass the query along through the chain till it is handled by a
component."
Command: Encapsulate an inquiry as an object, allowing you to define customers using
various requests.

5|Page
 Interpreter: considering a language, establish a grammar illustration as well as an
interpreter.
Iterator: Offer a method for repeatedly accessing each component of a collection object
with no showing it’s behind representation.
Mediator: Define a thing that encompasses the way a set of objects interact.
Memento: Capture and externalise the internal condition of an object so that it may be
brought back to this indicate later.
Observer: Specify a one-to-many dependability among objects so that when one object
modifications nation, all it’s the dependents get informed as well as updated.
State: Allow an object's behaviour modify when its internal configuration shifts."
Strategy: Identify a group of algorithms, encapsulate every one of them, and then render
these individuals interchangeable," says the.
Template: Identify the basic structure of an algorithm in a procedure, putting off certain
phases to subclasses.
Visitor: Represent a procedure to be carried out on each component of a physical
structure.

We found all of the coupled patterns. All pattern connects or numerous which link together make
up such coupled patterns. We categorised linked pattern sets based on loose vs. tight coupling
and pattern interacting types:

 Types of couplings

Loosely Coupled: Patterns are loosely tied together with few connections, making separation
simpler. The organisation should encourage faster and simpler future design modifications
(Bieman).

Tightly Coupled: Patterns are tightly coupled when they have numerous connections as well as
dependence. It will be challenging to make small modifications to one of the patterns without
first impacting any of the others (Bieman).

 Pattern Interaction Types

6|Page
Intersecting patterns demonstrate an exchange of information and communication scheme that
"talks to" or "uses a." While we discovered no proof that the design was both Composite material
and Embedded, we divided it as an intersection type (Bieman).

Demonstrates one of the coupled patterns discovered by Masuda et al. In this example, a
Template Method pattern example is linked to a Builder pattern example via a common class.
Class Translator is used in both patterns. The connection is of the type "talks with a," which
classifies the patterns as "Intersection (Bieman).

Figure 2: Coupled Patterns in Masuda et al (Bieman)

The collected information effectively contains additional instances for the intersection category
of pattern connection. The majority of coupled pattern sets are intersections (Bieman).

Modules should be as independent of one another as achievable, to ensure that modifications to

one module do not have an important effect on the other modules (Montiel, 2018).

High coupling indicates that the module is well-versed in the internal operations of various other
modules. Modules that know excessively regarding other modules complicate changes and
render modules brittle. If Module A understands excessively about Module B, changes to
Module B's internals may break Module A's functionality (Montiel, 2018).

By aiming for low coupling, it are capable of making modifications to module internals with no
concern about the way they will affect other modules in the system as a whole. Because our

7|Page
modules are not interrelated, low coupling makes it simpler to create, write, and test code
(Montiel, 2018).

The mediator pattern is used to reduce the complexity of communication among numerous
objects or classes. This pattern offers a mediator class that handles every interaction among
various classes and allows for easy code maintenance through loose coupling. The mediator
pattern is classified as a behavioral pattern (tutorialspoint.com, n.d.).

4.0 Simpler Solution

4.1 Scenario
Yummy Ice cream is a dessert shop that sells ice cream in different flavours including the vanilla
flavour, chocolate, and strawberry flavour. Different flavoured ice cream are sold are different
prices, the vanilla ice cream costs 4RM, chocolate flavour costs 6RM, and strawberry flavour
costs 8R. Moreover, customers can order an ice cream with or without topping. They will also be
charged for different prices based on the chosen toppings. Toppings choice are Caramel,
M&M’s, or Oreos.

8|Page
4.2 Class Diagram

Figure 3: Class Diagram - initial design

4.3 Java Implementation

The programme is written in Java using Eclipse IDE, as shown in the class diagram above. It is
made up of five classes: the Main class, an Ice Cream class, and three classes that inherit the Ice
Cream class: Vanilla_IceCream, Chocolate_IceCream, as well as Strawberry_IceCream.

The main class is responsible for carrying out the ordering process, which includes showing the
menu, customizing the Ice Cream order, and making payment.

9|Page
 Figure 4: Code snippets for main method and menu() method

In the figure above, it shows the code snippets for the main method. As the menu () method is
called to display the menu for customers and to get their order by calling order method as shown
in figure 4.

Figure 5: Code snippets for order() method

10 | P a g e
 Figure 6: Code snippets for selecting ice cream topping

After customers choose the ice cream flavor, the system will prompt again for the customers to
choose the toppings they need. Customers have 3 options of flavors, so they can select one of the
topping from 1 – 3, and if they don’t need any toppings they can select option 4 “No Toppings”
and then they can proceed to the payment.

Figure 7: Code snippets for payment() method

11 | P a g e
After customers are done with choosing their ice cream flavor and toppings, the total price of the
ice cream will be calculated, then customers can move to choose the payment method they want
whether using credit card or e-wallet.

The Ice Cream class is abstract, with one abstract method getPrice() that will be modified by its
child classes.

Figure 8: Code snippets for ice cream class

The figure above is showing the code of the ice cream class.

Figure 9: Code snippets for child class that inherits Waffle class

In the figure above is an example of the Vanilla_IceCream class extends the IceCream class and
overrides the parent class's abstract getPrice() method to determine its own behaviour, allowing it
to set the ice cream price for the original flavor to RM 4.

12 | P a g e
 Figure 10: Code snippets for add topping methods

Figure 11: Code snippets for payment methods

Ice cream class also includes methods for adding toppings and defines payment methods.

13 | P a g e
5.0 Refined Solution
5.1 Design issues in simple solution

There are some problems with the first system design, which are primarily due to inheritance
limitations. VanillaIceCream, ChocolateIceCream, and StrawberryIceCream all have a direct
relying on the IceCream class in some situations. This is demonstrated by the fact that they
inherit from the IceCream class and directly access its attributes.

When classes are highly coupled and rely on each other's details of implementation, this is
referred to as high coupling. In this situation, subclasses have immediate knowledge of the
IceCream class that can cause problems if the IceCream class is changed. Any changes or
updates to the IceCream class would necessitate corresponding modifications in the subclasses,
increasing the likelihood of erroneous and upkeep challenges.

It would be preferable to create a layer of abstraction among the subclasses and the IceCream
class to decrease coupling and enhance the design. This can be accomplished by defining an
interface that is common for the ice cream flavors through interfaces or abstract classes. Through
doing that way, the subclasses may depend on the abstraction instead of calling the IceCream
class directly.

5.2 Applied design patterns

As a result, two design patterns from the GoF are used to improve the errors in the initial design.
Decorator design pattern has been chosen as the first design patter to decorate the ice cream with
toppings to overcome the limitations of inheritance.

We may apply an abstract base class or interface for both components as well as decorator
classes to decrease coupling in the decorator design pattern. As a result, the decorator class will
only contain references to the abstract base class or interface, reducing coupling. The Decorator
pattern is a structural design pattern that allows behaviour to be dynamically added to an object.
It provides a flexible alternative to subclassing for extending an object's functionality. The

14 | P a g e
pattern entails creating a decorator class that wraps the original object and adds or modifies
existing behaviours to provide additional functionality.

The Decorator pattern can be used in the context of Yummy Ice Cream to solve the high
coupling problem among ice cream flavours and toppings. Rather than creating separate classes
for each ice cream flavour and topping combination, we may create a base IceCream interface or
class which represents the fundamental ice cream object. Then, for each topping, we can make
decorators (for example, CaramelDecorator, M&MsDecorator, OreosDecorator) that wrap the
base ice cream object and provide extra topping functionality. The ice cream flavours and
toppings are thus decoupled, allowing us to continually add or remove toppings as required.

The Strategy pattern is a behavioural design pattern that allows for the runtime selection of an
algorithm. It defines a family of interchangeable algorithms and contains each algorithm in its
own class. The pattern enables the algorithms to be chosen and used interchangeably depending
on the context or client's needs.

The Strategy pattern can be used to handle the pricing of different ice cream flavours in the case
of Yummy Ice Cream. Each flavour of ice cream can have its own pricing strategy.
VanillaIceCream, ChocolateIceCream, and StrawberryIceCream, for example, can each have
their own PriceStrategy implementation. The PriceStrategy interface or abstract class can define
methods such as calculatePrice(), which computes the price based on the ice cream flavour. We
can use the Strategy pattern to dynamically choose and implement the right pricing approach
based on the ice cream flavour, supporting loose coupling and flexibility in dealing with pricing
variations.

To summarise, we can dynamically add toppings to the ice cream using the Decorator pattern
without highly coupling flavours and toppings. We are able to manage cost variations for
different ice cream flavours using the Strategy pattern without directly coupling the pricing logic
with the ice cream classes.

15 | P a g e
5.3 Refined class diagram

Figure 12: Figure 12: Class Diagram - Refined Design

16 | P a g e
5.4 Refined Java implementation
Java code has been implemented for the refined solution based on the refined class diagram that
shows in the figure12. In the refined class diagram 7 classes has been added and sum up with
total of 7 classes. It is easy to notice that the design of the Main class has not changed much. The
overall programme flow remains the same as in the original design. The distinction is most
noticeable in the Ice Cream class.

First class was added is the ToppingDecorator class:

Figure 13: Code snippets for ToppingDecorator class

Figure 14: Code snippets for Caramel decorator class

17 | P a g e
As it shows in the figures below, the following modification is the inclusion of the Strategy
pattern in the payment part. To allow for various payment methods, a payment strategy interface
is provided.

Figure 15: Code snippets for PaymentStrategy interface

Figure 16: Code snippets for CreditCardStrategy

18 | P a g e
6.0 References
Bieman, W. B. (n.d.). Coupling of Design Patterns: Common Practices and Their Benefits. 25th Annual
International Computer Software and Applications Conference. COMPSAC 2001.

Josikakar. (2021, November 6). Software Engineering | Coupling and Cohesion. Retrieved from
geeksforgeeks: https://www.geeksforgeeks.org/software-engineering-coupling-and-cohesion/

Montiel, I. (2018, Septemebr 18). Low Coupling, High Cohesion. Retrieved from medium:
https://medium.com/clarityhub/low-coupling-high-cohesion-3610e35ac4a6

tutorialspoint.com. (n.d.). Design Patterns - Mediator Pattern. Retrieved from tutorialspoint:

https://www.tutorialspoint.com/design_pattern/mediator_pattern.htm

19 | P a g e