ASSIGNMENT 1 FRONT SHEET

Qualification BTEC Level 5 HND Diploma in Computing

Unit number and title Unit 20: Advanced Programming

Submission date 22/06/2020 Date Received 1st submission

Re-submission Date Date Received 2nd submission

Student Name Ngô Tiến Dũng Student ID GCH18539

Class GCH0716 Assessor name Doan Trung Tung

Student declaration

I certify that the assignment submission is entirely my own work and I fully understand the consequences of plagiarism. I understand that
making a false declaration is a form of malpractice.

Student’s signature

Grading grid

P1 P2 M1 M2 D1 D2
 Summative Feedback:  Resubmission Feedback:
2.1

Grade: Assessor Signature: Date:

Lecturer Signature:
Table of Contents
I. Introduction .................................................................................................................................................... 3
II. OOP general concepts ..................................................................................................................................... 3
III. OOP scenario ................................................................................................................................................... 6
1. Scenario ................................................................................................................................................... 6
2. Use case Diagram..................................................................................................................................... 7
3. Class Diagram .......................................................................................................................................... 8
IV. Design Patterns ........................................................................................................................................... 8
2.1. Creational patterns .................................................................................................................................. 9
2.2. Structural patterns ................................................................................................................................. 10
2.3. Behavioral patterns................................................................................................................................ 12
V. Design Patterns with OOP.............................................................................................................................. 13
VI. Conclusion ................................................................................................................................................. 15
References ............................................................................................................................................................ 15

List of Figures
Figure 1: Figure showing case diagram of VietnamWar............................................................................................ 7
Figure 2: Figure showing class diagram of VietnamWar ........................................................................................... 8
Figure 3: Figure showing class diagram use abstract factory pattern ...................................................................... 10
Figure 4: Figure showing class diagram use façade pattern .................................................................................... 11
Figure 5: Figure showing class diagram use decorator pattern ............................................................................... 12
Figure 6: Figure showing class diagram use template method pattern ................................................................... 13
 I. Introduction

The company assigned to me and my team is alleviate utilizing their code in multiple projects due
to poor documentation. My group task is explain characteristics of Object-oriented programming paradigm
by applying Object-oriented analysis and design on a given scenario, characteristics of OOP (such as:
encapsulation, inheritance, polymorphism, override, overload, etc.). Next task is introduce some design
patterns (including 3 types: creational, structural and behavioral) to audience by giving real case scenarios,
corresponding patterns illustrated by UML class diagrams. Then analyze the relationship between the
object-orientated paradigm and design patterns.

II. OOP general concepts

Object-Oriented Programming (OOP) is the term used to describe a programming approach based
on objects and classes. The object-oriented paradigm allows us to organise software as a collection of
objects that consist of both data and behaviour. This is in contrast to conventional functional programming
practice that only loosely connects data and behaviour. (Molloy, 2019)

An object-oriented programming language generally supports five main features:

• Classes
• Objects
• Classification
• Polymorphism
• Inheritance

An Object-Oriented Class

A class should:

• Provide a well-defined interface - such as the remote control of the television.

• Represent a clear concept - such as the concept of a television.
• Be complete and well-documented - the television should have a plug and should have a
manual that documents all features.
• The code should be robust - it should not crash, like the television.

Classes allow us a way to represent complex structures within a programming language. They have
two components:

• States - (or data) are the values that the object has.
 • Methods - (or behaviour) are the ways in which the object can interact with its data, the
actions.

An instance of a class is called an object.

An Object

An object is an instance of a class. You could think of a class as the description of a concept, and an
object as the realisation of this description to create an independent distinguishable entity. For example,
in the case of the Television, the class is the set of plans (or blueprints) for a generic television, whereas a
television object is the realisation of these plans into a real-world physical television. So there would be
one set of plans (the class), but there could be thousands of real-world televisions (objects).

Objects can be concrete (a real-world object, a file on a computer) or could be conceptual (such as
a database structure) each with its own individual identity. These objects should have their own identity
and are independent from each other.

Encapsulation

The object-oriented paradigm encourages encapsulation. Encapsulation is used to hide the

mechanics of the object, allowing the actual implementation of the object to be hidden, so that we don't
need to understand how the object works. All we need to understand is the interface that is provided for
us.

Encapsulation is the term used to describe the way that the interface is separated from the
implementation. You can think of encapsulation as "data-hiding", allowing certain parts of an object to be
visible, while other parts remain hidden. This has advantages for both the user and the programmer.

For the user (who could be another programmer):

• The user need only understand the interface.

• The user need not understand how the implementation works or was created.

For the programmer:

• The programmer can change the implementation, but need not notify the user.

So, providing the programmer does not change the interface in any way, the user will be unaware
of any changes, except maybe a minor change in the actual functionality of the application.

We can identify a level of 'hiding' of particular methods or states within a class using
the public, private and protected keywords:

• public methods - describe the interface.

 • private methods - describe the implementation.

Inheritance

One of the most important concepts in object-oriented programming is that of inheritance.

Inheritance allows us to define a class in terms of another class, which makes it easier to create and
maintain an application. This also provides an opportunity to reuse the code functionality and fast
implementation time.
When creating a class, instead of writing completely new data members and member functions,
the programmer can designate that the new class should inherit the members of an existing class. This
existing class is called the base class, and the new class is referred to as the derived class.
The idea of inheritance implements the is a relationship. For example, mammal IS-A animal, dog
IS-A mammal hence dog IS-A animal as well and so on.
A class can be derived from more than one classes, which means it can inherit data and functions
from multiple base classes. Where access-specifier is one of public, protected, or private, and base-class
is the name of a previously defined class. If the access-specifier is not used, then it is private by default.

Polymorphism

When a class inherits from another class it inherits both the states and methods of that class, so in
the case of the Car class inheriting from the Vehicle class the Car class inherits the methods of the
Vehicle class, such as engineStart(), gearChange(), lightsOn() etc. The Car class will also inherit the
states of the Vehicle class, such as isEngineOn, isLightsOn, numberWheels etc.

Polymorphism means "multiple forms". In OOP these multiple forms refer to multiple forms of the
same method, where the exact same method name can be used in different classes, or the same method
name can be used in the same class with slightly different paramaters. There are two forms of
polymorphism, over-riding and over-loading.

Over-Riding

As discussed, a derived class inherits its methods from the base class. It may be necessary to
redefine an inherited method to provide specific behaviour for a derived class - and so alter the
implementation. So, over-riding is the term used to describe the situation where the same method name
is called on two different objects and each object responds differently.

Over-riding allows different kinds of objects that share a common behaviour to be used in code
that only requires that common behaviour.

Over-Loading
 Over-Loading is the second form of polymorphism. The same method name can be used, but the
number of parameters or the types of parameters can differ, allowing the correct method to be chosen by
the compiler.

Abstract Classes

An abstract class is a class that is incomplete, in that it describes a set of operations, but is missing
the actual implementation of these operations. Abstract classes:

• Cannot be instantiated.
• So, can only be used through inheritance.

III. OOP scenario

1. Scenario

This is a game 1 vs 1, human and computer. Game is divided into 3 main parts which are reappeared
the war throughout the war period of Viet Nam. At the beginning of the game, each player (human and
computer) will have 1 base (with 100 cells), 150 golds, and 3 kinds of soldiers (each of them has 3 different
prices based on the damage and weapons). The game starts with the first period of war, Viet Nam vs China.
Each of the players has to choose 3 kinds of soldiers to fight with another. For each enemy piece destroyed
or cell of the enemy base burnt, the player will receive the same amount of gold and experience as that
type. This period only ends when either side destroys the enemy base or accumulates enough experience
and the next period (Viet Nam vs France) will come up with 3 new different kinds of soldiers for each player
and both of them can reuse old kinds of the old period. The rules for this period are similar to the first one.
Then after 2 main parts, players will move to the last period (Viet Nam vs America). This part is almost
similar to the second period but to end this part (end this game), one of the players will have to destroy
completely the base of the enemy.
 2. Use case Diagram

Figure 1: Figure showing case diagram of VietnamWar

Above is the use case of the game, players have 5 main functions that are play game, pause game, save games,
store, exit games. Players have 5 main functions that are play game, pause game, save games, store, exit games.
Play game function has 2 features that are new game play and play the previously saved game. Pause game
function allows the player to pause the game being played. Save game function allows the player to save the
game. Store function has 2 main features that are buying character skins and weapon skins, when purchased they
will automatically update in the game. Another function is exit game, players will exit the game and the system will
exit the game and will not save previous data.
 3. Class Diagram

Figure 2: Figure showing class diagram of VietnamWar

This class diagram is designed based on scenario that we have made. It includes main features of
OOP programming such as: attributes, methods, setters, getters, subclasses, etc. In addition, there are
different types between classes that we have determined it clearly.

IV. Design Patterns

1. Introduce design pattern

In software development, a template (or design pattern) is a written document describing a

common solution to a design problem that is repeated in many projects. Software designers tailor model
solutions to their specific projects. The samples use a formal approach to describe a design problem, the
proposed solution, and any other factors that may affect the problem or solution. A successful model
should have established itself resulting in a good solution in the previous three projects or situations.
(Rouse, 2007)

Types of Design Patterns:

There are mainly three types of design patterns:

• Creational
 These design patterns are all about class instantiation or object creation. These patterns can be
further categorized into Class-creational patterns and object-creational patterns. While class-creation
patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation
effectively to get the job done.

Creational design patterns are the Factory Method, Abstract Factory, Builder, Singleton, Object
Pool, and Prototype.

• Structural

These design patterns are about organizing different classes and objects to form larger structures
and provide new functionality.

Structural design patterns are Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Private
Class Data, and Proxy.

• Behavioral

Behavioral patterns are about identifying common communication patterns between objects and
realize these patterns.

Behavioral patterns are Chain of responsibility, Command, Interpreter, Iterator, Mediator,

Memento, Null Object, Observer, State, Strategy, Template method, Visitor.

2.1. Creational patterns

Scenario: A company specializing in manufacturing phones of two types is Xiaomi Redmi and Mi
phones. Due to its ability to compete in the market, the company decided to expand and produce smarter
watches. With the available brands of Redmi and Mi, the company will be divided into two factories:
RedmiFactory (making Xiaomi Redmi phones and Redmiband watches) and MiFactory (producing Xiaomi
Mi phones and Miband watches). When production is required, each order will be shipped to the factory
for execution. To avoid duplication of code and to avoid orders of confusion between the two factories, I
will apply an abstract factory design pattern to solve this problem.

Class diagram:
 Figure 3: Figure showing class diagram use abstract factory pattern

2.2. Structural patterns

Scenario 1: This is an application for those who want to manage their habits, ManageHabits. The
application is divided into 2 main parts: log into the system and set up personal habit management. At the
time of starting the application, users will log into the system (register if you do not have an account). Then
go to the management section, where users can add or remove a habit or more. There will be a routine
schedule and a summary table of established habits (including habit name, description, start time,
expected completion time, and number of percent completed habits). This application use façade patterns.

Class diagram:
 Figure 4: Figure showing class diagram use façade pattern

Scenario 2: A cafe's menu has some types of coffee available, but sometimes customers want to
use some that aren't available on the menu. Customers who order drinks will have to choose from the type
of coffee: Black coffee or milk coffee, with or without sugar, with ice or without ice, iced coffee or hot
coffee. Therefore, in order for customers to choose the type of coffee they want to drink, the restaurant
has allowed customers to customize and add topping into their drinks. Therefore, to be able to add actions
that are not available, it is necessary to use Decorator Design Pattern. Because the use of inheritance in
this situation is not useful, because it is fixed. If using Decorator, we will just need to wrap the layers
together, because Decorator is a Design Pattern of type Open Closed Principle. Because when creating
such a large Object, when you want to have another Object that uses Inheritance, it will be very difficult
to edit. For example, when we charge a cup of coffee with many ingredients, we will take each component
with a different price to add up the price of the coffee cup. But when one or more of those ingredients
price increases or changes. Then we have to take out the big Class and edit. But because we always want
to work towards the Open Closed Principle, every time we want to add a new or modified class, we just
need to extend the old class and replace the new one, and at the same time will reduce the need to modify
the code. If we use Decorator Design Pattern, then we only need to change one class. For example, in
coffee, Chocolate costs $ 5, when we want to change, we just need to change the class containing
Chocolate. Using Decorator will help us maintain a lot.

Class diagram:

Figure 5: Figure showing class diagram use decorator pattern

2.3. Behavioral patterns

Scenario: To my knowledge, milk tea now is one of the best famous beverages in Vietnam. Needless
to say, everyone still has different kinds of demand when they choose what inside their milk tea cup such
as sugar, amount of ice, kinds of topping, etc. So we are absolutely clueless about what would they choose.
Accompanied by a variety of recipe, I will write a program which is very convenient for employees to create
a recipe and print a bill. And in this project, I will use the template method pattern to develop effectively.

Class diagram:
 Figure 6: Figure showing class diagram use template method pattern

V. Design Patterns with OOP

Relation between some design patterns with OOP:

Abstract factory pattern

As in the example diagram of an abstract design pattern, the SuperFactory class is an abstract class.
This is a class that declares methods to create instances for other factories, and the specific
implementation of those methods will be done in the subclasses corresponding to each vendor.

The two subclasses of SuperFactory are RedmiFactory and MiFactory. Each subclass must
implement methods to create instances that correspond to each Factory.

For example, the CreatePhone () and CreateSW () methods on the RedmiFactory will initialize and
return the instance of Phone and Smartwatch corresponding to the Redmi Factory while the CreatePhone
() and CreateSW () methods on the MiFactory must initialize and return the Phone and Smartwatch.
corresponding to Mi Factory.

Façade pattern
 Facade pattern is a design pattern commonly used with object-oriented programming. The name
is by analogy to an architectural 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. A facade is an object that
provides a simplified interface to a larger body of code, such as a class library. A facade can make the
application easier to use, understand and test, since the facade has convenient methods for common
tasks, make the library more readable, for the same reason. When the system has many class, it is difficult
for users to understand the process of the program. And when there are so many subsystems that each
have their own individual interfaces, it is difficult to use in combination. In this case use Facade Pattern to
create a simple interface for users of a complex system

Decorator pattern

In the diagram above we can see the Coffee class and Decorator are 2 Abstract class. In the class
Coffee allows other class to inherit the functions get_Description () and cost (). The abstracting of Coffee
abstract and not inheriting its behavior, will create accuracy.

Inheritance is expressed by class like Capucinno, MilkCoffee, Espresso, Americano and Decorator
(Abtract class) inheriting the get_Description () and cost () functions of the Coffee class. Decorators have
the same type as the objects it will decorate. So here the inheritance is used to achieve the same type.

Encapsulation is a function that implies that the functions of the class are set to private, using
private will be accessible to anyone.

Regarding Polymorphism in this diagram, we see topping classes such as Milk, Mocha, Chocolate,
Vanilla. For the parent class is Coffee. We see, from a Class Coffee, we can overide the get_Description ()
function of the parent class Coffee.

Template method pattern

Template methods are a fundamental technique for code reuse. They are particularly important in
class libraries because they are the means for factoring out common behavior in library classes. Template
methods lead to an inverted control structure that sometimes referred to as "the Hollywood principle,"
that is, "Don't call us, we'll call you". This refers to how a parent class calls the operations of a subclass and
not the other way around. It's important for template methods to specify which operations are hooks (may
 be overridden) and which are abstract operations (must be overridden). To reuse an abstract class
effectively, subclass writers must understand which operations are designed for overriding.

VI. Conclusion

In summary, the characteristics of the object-oriented programming model are explained. Object-
oriented analysis and design on a given scenario is applied. Design patterns is introduced, some real case
scenarios are given, corresponding patterns illustrated by UML class diagrams. The relationship between
the object-orientated paradigm and design patterns are analyzed

References
Molloy, D. D., 2019. Object-oriented Programming with Embedded Systems. s.l.:s.n.

Rouse, M., 2007. Design Pattern. [Online]

Available at: (https://searchsoftwarequality.techtarget.com/definition/pattern)
[Accessed 20 06 2020].

Powered by TCPDF (www.tcpdf.org)

 Index of comments

2.1 OOP:
- Binh: general introduction about OOP. Introduction to scenario
- Binh: general OOP terms
- Loi: Use case diagram => simple diagram, correct syntax, symbols

Design class diagram:

- Dung: explain some OOP terms (abstraction)in class diagram, can answer override question
- Loi: explain encapsulation => understand, can draw constructor
- Cuong: inheritance => understand
- Binh: polymorphism => understand, can explain
- Generally, class diagram is correct. Attributes of Player should be protected instead of private

Patterns:
- Cuong: abstract factory pattern => suitable scenario, can explain component of pattern but need more details
(attributes)
- Loi: façade pattern => scenario seems confused but can explain component of pattern. Diagram is quite detailed.
- Dung: decorator pattern => suitable scenario. Should use protected members in super classes.
- Binh: template pattern => suitable scenario, understand key ideas of the pattern. Correct but too simple diagram,
should have more classes related to program.

Overall:
- Group understand OOP concepts, understand pattern concepts
- Group can show and explain diagram clearly.

Powered by TCPDF (www.tcpdf.org)