Le Duc Huy ASM2
Le Duc Huy ASM2
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
P3 P4 M3 M4 D3 D4
1
2
Summative Feedback: Resubmission Feedback:
3.1
5
TABLE OF FIGURES
Figure 1: Class diagram .............................................................................................................................................................................. 8
Figure 2: IOSFactory.cs(1) ......................................................................................................................................................................... 9
Figure 3: IOSFactory.cs(2) ....................................................................................................................................................................... 10
Figure 4: IOSFactory.cs(3) ...................................................................................................................................................................... 11
Figure 5: IOSFactory.cs(4) ...................................................................................................................................................................... 11
Figure 6: LuxuryMenu.cs.......................................................................................................................................................................... 13
Figure 7: LuxuryPhone.cs ......................................................................................................................................................................... 15
Figure 8: NormalMenu.cs ......................................................................................................................................................................... 17
Figure 9: NormalPhone.cs ........................................................................................................................................................................ 18
Figure 10: OldMenu.cs ............................................................................................................................................................................. 19
Figure 11: OldPhone.cs ............................................................................................................................................................................. 20
Figure 12: Phone.cs ................................................................................................................................................................................... 21
Figure 13: PhoneMenu.cs ......................................................................................................................................................................... 22
Figure 14: Program.cs ............................................................................................................................................................................... 23
Figure 15: Menu screeshots ...................................................................................................................................................................... 24
Figure 16: Choice 1 ................................................................................................................................................................................... 24
Figure 17: Choice 2 ................................................................................................................................................................................... 25
Figure 18: Choice 3 ................................................................................................................................................................................... 25
Figure 19: Choice 0 ................................................................................................................................................................................... 26
Figure 20: Abstract Factory ...................................................................................................................................................................... 27
Figure 21: Builder patterns ....................................................................................................................................................................... 28
Figure 22: Singleton .................................................................................................................................................................................. 29
Figure 23: Prototypes ................................................................................................................................................................................ 30
6
I. Introduction
Within the first assignment, I provided an explanation of the concept of object-oriented programming (OOP). As an
additional step, I developed a scenario and demonstrated it by using the class diagram and the use case diagram. Within my
report, I presented the circumstance as well as the class diagram. In the following, I will apply it and describe its benefits
and drawbacks, compare it to other design patterns, and explain why I chose it for the instance that was shown before.
There is a specialized company that manufactures phones, offering three unique categories: luxury phones, standard
phones, and vintage phones. The corporation will provide customers options, which the program will then apply to
select the best suitable things for certain consumers. The selection of things depending on their pricing. If the consumer
specifies a price range between $50 and $400, the program will provide a list of obsolete phone products. Please choose
a price range between $400 and $1000. The software will generate a list of regular phones. However, if you provide a
price range of $1,000 to $6,000, the program will generate a high-end luxury phone. Furthermore, buyers have the
option to buy phones at a reduced price and by brand.
2. Diagram
7
Figure 1: Class diagram
In the picture, the class map shows how the different classes are connected. It shows the classes' traits, methods,
relationships, and how they are passed down.
From old phones to luxurious phones, the picture shows a lot of different classes and platforms that are used to make
and sell phones. The classes and interfaces in the picture are described in more detail below:
With IOSFactory (), you can make Phone objects. This is the main class in the system.
PhoneMenu () is an interface that sets out the main ways to show the phone list and choose phones.
8
Phone (): This is the parent class, and all phones share the same traits and methods.
These subclasses, NormalPhone (), LuxuryPhone (), and OldPhone (), all come from the Phone () class. There
are different types of phones, and each class has its own set of features and methods.
The NormalMenu (), LuxuryMenu (), and OldMenu () subclasses all come from the PhoneMenu () class. Each
of these classes stands for a different phone list and has its own set of ways for showing that list.
Through inheritance, the subclasses of Phone () and PhoneMenu () are linked to the subclasses of NormalMenu
() and LuxuryMenu ().
This picture shows a class diagram that shows how classes and interfaces work together in terms of making and selling
phones.
III. Implementation
1. Code
1.1. IOSFactory.cs
Figure 2: IOSFactory.cs(1)
9
Figure 3: IOSFactory.cs(2)
10
Figure 4: IOSFactory.cs(3)
Figure 5: IOSFactory.cs(4)
11
This code establishes a basic C# console application that emulates a phone store; the primary functionality of the
program is handled by the `IOSFactory` class. Let us take a closer look at the code:
Methods:
• Run (): The primary method that launches the application consists of a loop that shows the menu
continuously, requests the user's selection, executes that selection, and keeps going until the user selects to
exit (choice equals ‘EXIT’).
• PrintMenu (): Prints the main menu options to the console.
• GetChoice (): Determines the user's selection and invokes the appropriate method in accordance with it.
FindByName (): prompts the user to enter a phone name (old, normal, or luxury) and displays the menu
for the chosen type.
FindByPrice (): prompts the user to enter a price and displays the menu based on the entered price range.
Discount (): prompts the user to enter a discount percentage and displays the menu based on the entered
discount.
Menu Interaction
• The menus (‘OldMenu’, ‘NormalMenu’, ‘LuxuryMenu’) seem to have a ShowMenu () method, which is
called after setting the ‘menu’ field in the FindByName (), FindByPrice (), and Discount () methods.
12
Input Handling
• The code uses Console.ReadLine () and int.Parse () to handle user input for choices, names, prices, and
discounts.
Error Handling
• An error notice titled "Invalid choice" appears if the user makes an incorrect selection.
Note: If the ‘PhoneMenu’, ‘OldMenu’, ‘NormalMenu’, and ‘LuxuryMenu’ classes and their ShowMenu () methods
are not defined elsewhere in the code, it is hard to give a comprehensive understanding of the functionality of the
entire application.
1.2. LuxuryMenu.cs
Figure 6: LuxuryMenu.cs
13
It looks like this code is part of a larger program that simulates a phone store, where different phone models are
associated with different menus. The class entitled ‘LuxuryMenu’ derives from the ‘PhoneMenu’ class.
Inheritance:
Since ‘LuxuryMenu’ is a subclass of ‘PhoneMenu’, it is likely that it receives some of its characteristics and
behavior from the ‘PhoneMenu’ class.
Method Override:
The Create () function from the base class ‘PhoneMenu’ is overridden by the class; this means that although the
‘Create ()’ method is described as an abstract or virtual method in the base class, it offers a customized
implementation for the luxury menu in this instance.
Phone Creation:
The ‘LuxuryMenu’ appears to be used for creating and managing luxury phones inside the phone shop application,
as evidenced by the fact that the overridden ‘Create ()’ function produces a new instance of the ‘LuxuryPhone’
class.
Assumptions:
It is presumed that the ‘PhoneMenu’ class has a virtual or abstract method called Create (), which subclasses
override to indicate the kind of phone they manage.
Phone Hierarchy:
A hierarchy of phone classes is implied by the code, where the ‘LuxuryPhone’ is a particular kind of phone that is
connected to the ‘LuxuryMenu’.
It is impossible to fully explain how this class fits into the broader design of the phone store simulation without
knowing more about the ‘PhoneMenu’ class and the other phone-related classes in the program.
14
1.3. LuxuryPhone.cs
Figure 7: LuxuryPhone.cs
15
The purpose of this code appears to be to represent a particular type of luxury phone and provide functionality for
displaying information about various models and handling user input for purchasing. It defines a C# class named
‘LuxuryPhone’ that extends (inherits from) a class called ‘Phone’.
Inheritance:
Since ‘LuxuryPhone’ is an instance of the ‘Phone’ class, it is distinct from other phone types.
Constants:
The class defines constants that represent prices for several luxury phone models and a sale percentage that is
applicable to all models ({PRICE1}, {PRICE2}, {PRICE3}, {PRICE4}, {SALE}).
Info Method:
The `Info()` function asks the user to select a phone model, checks the input, and, depending on the selection,
shows a congrats message.
Exception Handling:
In the event that the user inputs non-numeric data, a `FormatException` may arise. This is caught by the `try-catch`
section.
1.4. NormalMenu.cs
16
Figure 8: NormalMenu.cs
An object of class ‘NormalPhone’ is created and returned by overriding the ‘Create()’ function in this code, which
defines a class named ‘NormalMenu’ that inherits from the ‘PhoneMenu’ class.
1.5. NormalPhone.cs
17
Figure 9: NormalPhone.cs
This code defines a class called ‘NormalPhone’, which is an inheritance of the ‘Phone’ class; it represents a typical
phone type and handles the user's choices during the purchase process. To summarize, this class is as follows: -
{NormalPhone} is an inheritance of the `Phone} class; - The constants {PRICE1{, {PRICE2},..., {PRICE6}
18
represent the prices of various phone models; - {SALE} is a constant representing the discount rate (20% in this
case). - The `Show()’ method displays information about common phone models, including prices and discounts,
and then calls the `Info()} method to handle the user's selection. - The `Info()’ method asks the user to select a
phone model and displays a congratulatory message with the corresponding discount.
1.6. OldMenu.cs
An object of class ‘OldPhone’ is created and returned by overriding the ‘Create()’ function in this code, which
defines a class named ‘OldMenu’ that inherits from the ‘PhoneMenu’ class.
19
1.7. OldPhone.cs
This code defines a class called ‘OldPhone’, which is an inheritor of the ‘Phone’ class and represents a traditional
phone type, model information, and user unit option after purchase.
• ‘OldPhone’ is a classic phone type that inherits from the ‘Phone’ class.
• The constants `PRICE1`, `PRICE2`, ..., `PRICE6` represent the prices of different vintage phone models.
• The ‘Show()’ method shows details about classic phone models, including prices and discounts; it then calls
the `Info()} method to handle basic user selection.
• The ‘Info()’ method asks the user to select a phone model and displays a congratulatory message with the
corresponding reduced price.
20
• ‘SALE’ is an ongoing representative rule discount (15 percent in this case).
1.8. Phone.cs
21
1.9. PhoneMenu.cs
22
The main goal of ‘PhoneMenu is to provide a common structure for displaying menus and creating the
corresponding ‘Phone’ object. Subclasses of ‘PhoneMenu’ must implement the ‘Create()’ method to provide a
‘Phone’ object that is specific and independent of how the menu is displayed.
1.10. Program.cs
The code ‘IOSFactory i = new IOSFactory(); i.Run();’ creates an instance of the ‘IOSFactory}’ class and then calls
its ‘Run()’ method.
This line instantiates the class using the ‘new’ keyword. ‘i.Run();’: This line calls the {Run(){ method on the
‘IOSFactory’ instance ‘I’. The ‘Run()’ method runs the phone store application's main logic, displays a menu, and
waits for the user to choose to quit. In summary, this code sets up and runs an instance of the phone store
application represented by the ‘IOSFactory’ class. The specific behavior will depend on the implementation detail.
2. Program screenshots
23
Figure 15: Menu screenshots
When the application is being executed, this is the first interface that appears. If consumers wish to locate items based
on any item, they need just input the numbers from one to three in this section. To exit the application, enter the
number 0.
If the user chooses 1, the system will search for goods based on their prices. Users have the option of entering the price
at which they want to purchase a product, and the application will then provide goods that are suited for that price. In
the event that the user inputs a number that is not present in the menu while selecting a product to purchase, the
software will insist that the user enter the number many times until it is accurate.
Within this section, the user is able to input the quantity of the product that he wishes to purchase, and the software will
compute the precise price of the product, taking into account any applicable discounts.
24
Figure 17: Choice 2
Option 2 on the menu is where customers may discover items based on the sorts of things they are looking for. In the
event if the user enters normal, the software will display items from outdated smartphones. When customers input the
category of elderly or luxurious, the application will also provide them with the items that belong to those categories. In
this section, the user is able to input the quantity of the product that he wishes to purchase, and the software will
compute the precise price of the product, taking into account any applicable discounts.
When customers are looking for items based on discount codes, this is the third option present in the menu. The
application will display the goods that are stored in the old phone when the user inputs the number 15. In this section,
25
the user is able to input the quantity of the product that he wishes to purchase, and the software will compute the
precise price of the product, taking into account any applicable discounts.
IV. Discussion
1. Range of similar design
1.1. Abstract factory
Abstract Factory design pattern is one of the Creational patterns. Abstract Factory pattern is almost similar to
Factory Pattern and is considered as another layer of abstraction over factory pattern. Abstract Factory patterns
work around a super-factory which creates other factories. Abstract factory pattern implementation provides us with
a framework that allows us to create objects that follow a general pattern. So, at runtime, the abstract factory is
coupled with any desired concrete factory which can create objects of the desired type. Abstract Factory provides
interfaces for creating families of related or dependent objects without specifying their concrete classes. Client
software creates a concrete implementation of the abstract factory and then uses the generic interfaces to create the
concrete objects that are part of the family of objects. (Geeksforgeeks, 2022)
26
Figure 20: Abstract Factory
• Too Many arguments to pass from client program to the Factory class that can be error prone because most
of the time, the type of arguments are same and from client side its hard to maintain the order of the
argument.
• Some of the parameters might be optional but in Factory pattern, we are forced to send all the parameters
and optional parameters need to send as NULL.
• If the object is heavy and its creation is complex, then all that complexity will be part of Factory classes that
is confusing.
27
We can solve the issues with large number of parameters by providing a constructor with required parameters and
then different setter methods to set the optional parameters. The problem with this approach is that the Object state
will be inconsistent until unless all the attributes are set explicitly. Builder pattern solves the issue with large
number of optional parameters and inconsistent state by providing a way to build the object step-by-step and
provide a method that will actually return the final Object.
(Pankaj, 2023)
1.3. Singleton
Singleton pattern is one of the simplest design patterns in Java. This type of design pattern comes under creational
pattern as this pattern provides one of the best ways to create an object.
This pattern involves a single class which is responsible to create an object while making sure that only single
object gets created. This class provides a way to access its only object which can be accessed directly without need
to instantiate the object of the class.
(Tutorialspoint, 2022)
28
Figure 22: Singleton
1.4. Prototype
The Prototype Design Pattern in C# is a creational pattern used for creating objects by copying an existing object,
known as the prototype. This pattern is particularly useful when the cost of creating an object is more expensive or
complex than copying an existing object. To simplify the above definition, we can say that the Prototype Design
Pattern gives us a way to create new or cloned objects from the existing object of a class. That means it clones the
existing object with its data into a new object. If we make any changes to the cloned object (i.e., new object), it
does not affect the original object. (DotNet Tutorials, 2022)
29
Figure 23: Prototypes
Assess the usage of pattern in your program, taking into consideration both its benefits and drawbacks.
A number of benefits
• An intimate contact between the creator and the tangible goods is something that I am able to avoid.
30
• Because each class just has a single method, the code is incredibly simple to understand and straightforward to
modify.
• My code may be extended without requiring any of the older classes to be fixed.
• Cut down on the number of switch cases in the program.
Lack of advantage
• It's possible that my software will have an excessive number of classes if I add additional aircraft types to it.
V. Conclusion
I followed the design pattern as well as the scenario that I selected and constructed for the strategy design pattern that was
offered in this report. This was done in line with what is said in the report. At the same time that I was putting my design
pattern into reality, I simultaneously provided an explanation of it by way of the class diagram. Additionally, I have
supplied you with some images of the software, in addition to the fact that the source code for the program has been made
accessible to you. Furthermore, I have provided a comparison of the strategy design pattern with a few other design
patterns, as well as an explanation of why the strategy design pattern is appropriate for Scenario. I have also supplied a
comparative analysis of the strategy design pattern. There was also a discussion of the advantages and disadvantages that
are related with the use of the strategy design pattern that I included in my concluding remarks.
31
VI. Reference:
32
3.1 - P3: The Factory Method pattern has been applied in order to solve a problem of phone manufacturing. The section has provided a design of class diagram and an
acceptable implementation. The project's complexity is low, and it had better include a design of use case diagram for clarifying the system requirements better.
- P4: The section adequately outlines patterns closely associated with the Factory Method pattern. However, there is a lack in providing a well-justified rationale for
the final selection. It is essential to thoroughly assess and justify the appropriateness of each pattern within the context of the project.
---***---
Assessor Signature: Hong-Quan Do
Grade: P