ASM 1 Advanced Programming 1651FPT Greenwich (Full Distinction criteria) (new 2022))

ASSIGNMENT 2 FRONT SHEET
Qualification

TEC Level 5 HND Diploma in Computing

Unit number and title

Unit 20: Advanced Programming

Submission date

30/06/2022

Date Received 1st submission

Re-submission Date

Date Received 2nd submission

Student Name

Nguyen Huy Hoang

Student ID

GCH200739

Class

GCH0908

Assessor name

Le Viet Bach

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


 Summative Feedback:

Grade:

 Resubmission Feedback:

Assessor Signature:

Internal Verifier’s Comments:

Signature & Date:

Date:


Table of Contents
A.

INTRODUCTION ........................................................................................................................................................ 5

B.

SCENARIO ANALYSIS ................................................................................................................................................. 6
1.

SCENARIO ............................................................................................................................................................. 6

2.

DIAGRAM .............................................................................................................................................................. 6

C.

2.1.

Use-case Diagram .......................................................................................................................................... 7

2.2.

Class Diagram .............................................................................................................................................. 10

IMPLEMENTATION ................................................................................................................................................. 16
1.

Code(Related to Class Diagram) ......................................................................................................................... 16
1.1.

Loan Concrete Class .................................................................................................................................... 16

1.2.

Client Concrete Classes ............................................................................................................................... 22

1.3.

Credit Checker Classes ................................................................................................................................ 24

1.4.

Loans Factory Method Design Pattern Classes ........................................................................................... 27

2.

Code(Some Represented Codes in GUI) ............................................................................................................. 31

3.

Program ScreenShots ......................................................................................................................................... 35

D. DISCUSSION ............................................................................................................................................................ 40
1.

2.

Range of Similar Patterns ................................................................................................................................... 40
1.1.

Briefly Summary of Some Similar Design Patterns to Factory Method ...................................................... 40

1.2.

Explain Why Factory Design Pattern is The Most Suitable for this Scenario .............................................. 41

Usage of Patterns ............................................................................................................................................... 43

References ..................................................................................................................................................................... 44

List of Table
Table 1: Signup usecase................................................................................................................................................... 8
Table 2: MakeLoan usecase ............................................................................................................................................. 8
Table 3: View Profile usecase .......................................................................................................................................... 9
Table 4: Logout Usecase ................................................................................................................................................ 10


List of Figures
Figure 1: Use-case diagram .............................................................................................................................................................. 7

Figure 2: Class Diagram .................................................................................................................................................................. 10
Figure 3: Loans Concrete Classes ................................................................................................................................................... 11
Figure 4: Client Concrete Class ...................................................................................................................................................... 12
Figure 5: Loans Factory Method Design Pattern ........................................................................................................................... 14
Figure 6: Credit Checker Classes .................................................................................................................................................... 15
Figure 7:Enum ................................................................................................................................................................................ 15
Figure 8: Loans CLass ..................................................................................................................................................................... 16
Figure 9: HotLoans Class ................................................................................................................................................................ 17
Figure 10: Unsecured Loan Class ................................................................................................................................................... 18
Figure 11: Overdraft Loan Class ..................................................................................................................................................... 19
Figure 12: InstalmentLoan Class .................................................................................................................................................... 20
Figure 13: MortgageLoan class ...................................................................................................................................................... 21
Figure 14: User Class ...................................................................................................................................................................... 22
Figure 15:Bank Class ...................................................................................................................................................................... 23
Figure 16: Item class ...................................................................................................................................................................... 24
Figure 17: ICreditChecker interface ............................................................................................................................................... 25
Figure 18: FastCreditChecker Class ................................................................................................................................................ 25
Figure 19: ComplexCreditChecker class ......................................................................................................................................... 26
Figure 20: ServiceChecker Class ..................................................................................................................................................... 26
Figure 21: AutomaticChecker Class ............................................................................................................................................... 27
Figure 22: ILoanFactory Interface .................................................................................................................................................. 28
Figure 23: HotLoanFactory Class .................................................................................................................................................... 28
Figure 24: UnsecuredLoanFactory Class ........................................................................................................................................ 29
Figure 25: OverdraftLoanFactory Class .......................................................................................................................................... 29
Figure 26: InstalmentLoanFactory Class ........................................................................................................................................ 30
Figure 27: MortgageLoanFactory Class .......................................................................................................................................... 31
Figure 28: Main Form Typical Snippet code.................................................................................................................................. 32
Figure 29: AvailableLoanService Form Snippet Code .................................................................................................................... 33
Figure 30: MortgageLoan Form ..................................................................................................................................................... 34
Figure 31: Home Form of app ........................................................................................................................................................ 35

Figure 32: Home Form when unlocking other functions ............................................................................................................... 36
Figure 33: Loan Services Form ....................................................................................................................................................... 37
Figure 34: Profile form ................................................................................................................................................................... 37


A. INTRODUCTION
In programming, when faced with some problems which are related to OOP or class family organisation, one of the
solutions which would be helpful is the design pattern. Design patterns are understood as all-purpose, repeatable
solutions to issues that crop up frequently. The best practices are those that seasoned developers follow. Patterns are
not entire pieces of code, but they may be used as a model to solve a particular issue. Patterns may be used to
compare design problems in any domain since they are reusable.
To get more understandable, this report will present the development of the "GetH1gh" application, which has the
problem related to the initialization of an instance of the class and this will be solved by one of the creational
patterns. The detailed processing, designing, coding and explaining will be presented below. The report also provides
screenshots for illustrations and analysis as well as evaluates the most suitable design pattern.


B. SCENARIO ANALYSIS
1. SCENARIO
"GetH1gh" is a relatively famous financial aid office recently, their slogan is wishing to change its approach to
finance, helping people have a better life by providing quick - easy - transparent service. Now, when being
legalized after operating the long outlaw period, "GetH1gh" is planning to develop an online finance application
that will help its customers to make loans more straightforward or even create a mortgage loan package online.
The online financial application of "GetH1gh" has not been completed yet and is being tested with one of its
main functions, which is to initiate loan packages. Specifically, there are five primary loan packages of
"GetH1gh" including unsecured loans; overdraft loans; instalment loans; mortgage loans and hot loans. Each
loan also has its own distinct features:
 The unsecured loan package will have the highest interest rate is fixed at 21%/year and does not
require any collateral. Additionally, the procedures for an unsecured loan are quite simple and the
credit.

 For overdraft, it loan limit will be based on the balance of the customer's bank account and the liability
and interest of the overdraft will be calculated based on the outstanding balance and the time of the
debit. The overdraft package could have collateral or not, if there is any collateral to make an
overdraft loan, the interest rate of it will decrease significantly.
 Installment loans will need to declare the items to be paid in instalments, the interest rate is based on
the term that the customer will deal with the office. The amount and prepayment also will be
calculated automatically based on the instalment item.
 The mortgage loans may need documents of the collateral as well as the loan purpose. In case the
mortgage collateral has no proven document, the interest rate will be pretty high. The loan limit of a
mortgage loan is 170 % of the total value of the collateral.
 Lastly, the special Loan package of "Geth1gh" is a hot loan, its procedures are very simple. However,
its interest rate is very high.
Because of the incompetence of their dev team, our team was invited to assist them in developing this
functionality.
2. DIAGRAM


2.1.

Use-case Diagram
Here is the use case of entire the program

Figure 1: Use-case diagram

Explanation:
Use case Name
Created by:
Date Created
Description:
Actors:

Pre-conditions:
Post Conditions:
Flow:

Alternative Course:
Exception:

SignUp
Mr Hoang
Last Updated By:
Mr Hoang
30/06/2022
Last Revision Date 30/06/2022
This use case describes the process of Signing up the new user’s
data
 User
 The user had to download and install this application;
 The system handles and stores the data of the input from the
user
1) User clicks on the “Sign up” button on the home form of the
app;
2) User fill in the text boxes with appropriate input and format
3) User Click on the button check and the system performance
checks the validation of each text boxes
4) System stores and handle the data from the user
5) Finish
 Application is no longer approved for use(occurs at step 1);


Requirements:

 Crashing;
The appropriate of the system and user;

Table 1: Signup usecase

Use case Name
Created by:
Date Created
Description:
Actors:
Pre-conditions:
Post Conditions:

Flow:

MakeLoan
Mr Hoang
Last Updated By:
Mr Hoang
30/06/2022
Last Revision Date 30/06/2022
This use case describes the process of making the loan
 User
 The user had to download and install this application;
 The user has already done the “Signup” use case;
 The system handles and stores the data of the selections of
the user
 The system stores the input from the user
1. User clicks on the “MakeLoan” button on the home form of

the app
2. System performs credit Check
3. System displays the available Loan for the user based on
credit;
4. User performs making Loan
5. User fill in the text boxes in the Loan form
6. System updates the time. System and user repeat steps 3 to
5 until the user clicks the “back” button;

Alternative Course:

7. Finish;
In step 4 of the Flow, the user can make different types of loan
packages:
1) Make the hot loan one time;
2) Make the unsecured loan one time;
3) Make the overdraft loan one time;
4) Make the instalment loan one time;
5) Make the mortgage loan one time;

Exception:
Requirements:
Table 2: MakeLoan usecase

The use case continues at step 4 of the flow
 Application is no longer approved for use(occurs at step 1);
 Crashing;
The appropriate of the system and user;

Use case Name
Created by:
Date Created
Description:
Actors:
Pre-conditions:
Post Conditions:
Flow:

Alternative Course:

View Profile
Mr Hoang
Last Updated By:
Mr Hoang
30/06/2022
Last Revision Date 30/06/2022
This use case describes the activities of viewing the profile
 User
 The user had to download and install this application;
 The user had signed up successfully;
 The system handles and stores the data of the selections of
the user
1. User clicks on the “Profile” button on the home form of this
app;
2. System displays the information of the user;
3. Finish;
In step 2 of the Flow, the user can cancel the existed loan in the
list:
1. Enter the index of the loan which the user wants to cancel;

2. Pay for money fine;
3. System store change;

Exception:
Requirements:

The use case continues at step 2 of the Normal Course
 app is no longer approved for use(occurs at step 1);
 Crashing;
The appropriate of the system and user;

Table 3: View Profile usecase

Use case Name
Created by:
Date Created
Description:
Actors:
Pre-conditions:
Post Conditions:
Flow:

Alternative Course:
Exception:

Log out
Mr Hoang
Last Updated By:
Mr Hoang
30/06/2022

Last Revision Date 30/06/2022
This use case describes the moment when the user clicks logout
this game
 User
 The user had to download and install this game;
 The User had to Sign up in this app;
 The system handles the data of the selections of the user
1. User clicks on the “Logout” button on the menu;
2. System handles the selection of the user;
3. System performs signing out the data of this user;
4. Finish;
 Lag;


Requirements:

The appropriate of the system and user;

Table 4: Logout Usecase

2.2. Class Diagram
a) Diagram:

Figure 2: Class Diagram


b) Break Down Class Diagram and Explain:
 Loans Concrete Classes:

Figure 3: Loans Concrete Classes

Explanation:
According to the scenario above, the “Geth1gh” application will provide 5 primary loan packages; So, these
classes also have 5 concrete classes that are responded to 5 loan packages: Hot Loans Class, Mortgage
Loans Class, Unsecured Loans Class, Overdraft Loans Class and Instalment Loans Class. Although each one
also has its own features, these 5 concrete classes still have some features in common. Hence, there is a
base class(“Loans” Class) which contains the properties in common of 5 loan packages. There is a
bidirectional association between Loans class and User class and the relationship is “make” and the
multiplicity between the “User” and the “Item” is “1 and 0…*. It demonstrates that one instances of “user”
class could make some loans or not. The public access modifier properties and methods of the “Loans” class
include:
 Properties:
 Amount: defines the amount of this loan.
 Interest Rate: defines the interest rate of this loan.
 Required Income: The income that this loan requires the customer have.
 LoanTerm: Defines the term that the customer deals with this loan.
 Liability: Defines the total Liability of this loan.


 User: The customer who makes this Loan.
 Methods:
 SetLiability method: get the double parameter from input and assign it to the Liability Property
 SetInterestRate Method: get the double parameter from input and assign it to the interest rate
Property
Because of ensuring the encapsulation, the constructor of this base class has the access modifier is
“protected”(just permit subclasses to manipulate). 5 Loan concrete classes now are the subclasses and they
inherit the “Loans” base class to share the features in common. There are distinct features of each Loan
concrete class:
 Hot Loan Class: two properties that are “requiredincome” and “InterestRate” are set to default(0 for
“requiredincome” and 27 for “InterestRate” ) once the instance of this class is initialized.

 Mortgage Loan Class: Two additional properties of this class are “Collateral”(Which defines the
collateral which the customer wants to mortgage) and “Purpose”(It stores the purpose of the
customer why they want to make a Mortgage Loan). The additional method of this class is “set
requiredincome”(get the double parameter from input and assign it to the required income
Property).
 Unsecured Loan Class: this class is quite like the base class, the only different thing is the Interest
rate of this Loan will set the default to 21 once its instance is initialized.
 Overdraft Loan Class: Because the Loan limit is based on the balance in the bank account of the
customer, this class has a bank account property(defines the bank account of the customer) and the
other additional property is Collateral(May or may not defines the collateral of the customer).
 Instalment Loan Class: Because the Loan Limit and the prepayment property of this class will be set
based on the instalment Item, this class has the additional item that is Item(which defines the
instalment item of the customer). The distinct method of this Class is SetPrepayment(get the double
parameter from input and assign it to the prepayment Property)
 Client Concrete Class:

Figure 4: Client Concrete Class


Explanation:
There are 3 classes which represent 3 primary objects that store the information of the customer
including Item(defines the collateral as well as the instalment Item of the customer), Bank(defines the
bank account of the customer) and User(the concrete class defines all basic information of the
customer needs when making any loan anywhere).
The bidirectional association between the “User” class and “Item” class as well as between the “User”
class and “Bank” class demonstrates that the relationship also is possing. However, the multiplicity
between the “User” and the “Item” is “1 and 0…*” which means each user’s instance when being
initialized could have some Items(Item represent for instalment Items and Collateral; hence, it could
appear to initialize more than one time) or not. And the multiplicity between “User” and “Bank” is “1
and 0…1” which means each user’s instance when being initialized could have only one bank account

or not.
For specific, there are the properties and methods of each class:
User Class:
 Properties(Public access modifier with protected setter):
 Name: Defines the full name of the customer.
 Age: Defines the age of the customer.
 Identity Card: The number sequence on the National Identity Card of the customer.
 Income: The monthly income of the customer.
 isHavingJob: Defines whether the Customer has a fixed job or not(fixed-job doesn’t include
“freelancer”).
 BankAccount: Defines the bank account of the user.
 LoanStatus: Defines the status which is assessed in the customer’s loan history.
 Loanlists: The list of loans the customer makes.
Bank Class:
 Properties(Public access modifier with protected setter):
 Name: The card name.
 CardNumber: The number on the bank card.
 ExpiredDate: The expired date wrote on the bank card.
 Balance: Defines the current balance of this bank card.
 Methods:
 ReceiveMoney method: Get the double parameter from input and add it to the Balance
Property
 PayMoney method: Get the double parameter from the input and then take the balance
minus the parameter.


Item Class:
 Properties(Public access modifier with protected setter);
 Name: Defines the name of the Item
 Value: The actual value of this Item(VND)

 Document: Defines whether this Item has a full document or not.
 Loans Factory Method Design Pattern:

Figure 5: Loans Factory Method Design Pattern

Explanation:
Based on factory design pattern logic, these Loan Factory Classes will substitute the calls to a unique
factory method for direct object construction calls (initialize any loan in 5 primary concrete loan
classes using the new operator). However, the new operator of Loan Concrete Class is still used to
construct the objects, but it is now called from within the factory method(CreateLoan method). Loans
now are frequently used to describe objects that a factory method returns.
The ILoansFactory interface declares a method(CreateLoan) that is intended to return an instance of a
Loans Class. Loan Factory Concrete classes are able to indirectly change that logic by implementing the
factory method and returning a different type of Loan from it. These 5 Loan factory(responding to 5
primary loan packages) concrete classes implement the factory method(CreateLoan) so that changing
the resulting Loan's type. Although the method of Loan Factory concrete Class still uses the Loans as
type, the Loan concrete class instance is actually returned from the method.
Return a new loan is not the primary responsibility of the loan concrete class, it still has some logic
related to Loan. Hence, there are three classes which help loan factory concrete class perform logic
when creating loan such as “PrepaymentImplement” class, “InterestRateImplement” class and


“Liability Calculator” class. The bidirectional association between them and Loan Factory concrete
classes demonstrates that they will be used by Loan Factory concrete classes.
 CreditChecker Classes

Figure 6: Credit Checker Classes

Explanation:
These classes and interface are represent for the checking credit of customers when they sign up.

Because the difference in each checking way and each type of checking is used for each type of loan,
these checking types are extracted into separate classes called Fast Checker and Complex Checker.
The interface IcreditChecker declares the CreditCheck method which gets the User object as its
parameter with the type of method is CreditType(enum) to all supported types of checker class.
Two classes(Fast Checker and ComplexChecker) implement this interface to set their all-handling logic
for checking the credit of the user. The CheckerService class contain the property as the reference to
any type of checker, the CheckerService class will work with any type of checker via IcreditChecker
Interface. In other words, The IcreditChecker interface makes FactChecker and ComplexChecker
classes interchangeable in the CheckerService Class. The bidirectional association between
CheckerService and User class will be demonstrated by AutomaticChecker.
 Enum
There are two primary enums which are StatusType(Good, Pure, Remarkable and
Bad) and CreditType(High, Medium, Low). The StatusType is frequently used to set
the LoanStatus of User and The CreditType is the resulting return of Checker class
when it performs checking on customer.

Figure 7:Enum


C. IMPLEMENTATION
1. Code(Related to Class Diagram)
Because The Code which is related to Class Diagram above will be used many times in the program, all of
the codes below have been located in the Class Library, which is a library that contains classes, interfaces,
functions, etc… that can be used by more than one program at a time.
1.1. Loan Concrete Class
Based on the class diagram above, the code of the Loan Concrete Class will be a total of 6 classes
including one BaseClass and five SubClasses which inherit the BaseClass.
a) BaseClass – “Loans” class:

Figure 8: Loans CLass

Explanation: The “loans” class has declared all the properties in common which the subclasses(5
Loan type concrete class) would inherit to use them. These properties also have been introduced in
the class diagram above. All of these properties also have been set to public access modifier and
protected setter with the data type presented in the image above. To ensure that the client code
cannot initialise any instance of Loans Class directly by using the new() operator, The access modifier
of the “Loans” constructor has been set to “Protected”(only inherited classes could inherit this
constructor).
To follow the Single Responsibility principle, this class only has two methods and both of them also
be used to get the parameter and assign it to the properties in this class. Method SetLiability which
gets the double input as a parameter will set the Liability resulting after calculating by business logic
in other class to the Liability Property for the instance of Loans. Method SetInterestRate also is like


the SetLiability method, it also gets the double input as a parameter and takes this parameter
assigning it to the interest rate Property.
This class also has overridden the tostring() function to format the output for an object of this class.
CulcutureInfo is an available service used by adding the System.Globalization library of C#, which
allows getting the VND format for the VND output of Liability and the Amount of Loan. After all,
return the string as output.
b) SubClasses of “Loans” Class(HotLoan, UnsecuredLoans, OverdraftLoans, InstalmenLoans,
MortgageLoans)
 HotLoans Class

Figure 9: HotLoans Class

Explanation: This class inherits the Loans class to take the properties in common. However,
instead of set Interest Rate by function, the InterestRate property of this one will be assign to
26 whenever the instance of Hotloans is initialized(It may look a bit illogical because client
code also could call setInterestRate to set the interest rate of it. Although this issues partly

might be solved by using factory method it will hide concrete class, I also could optimize by
setting the Loans class to abstract class and the SetInterestRate method would be abstract;
so, each class could implement it or do nothing with it).
The constructor of HotLoans takes three parameter: amount(double), user(User),
loanTerm(double) and the properties also would be assigned based on the inputted
parameter. This one also override the ToString() method to return its own ouput.


 UnsecuredLoans Class

Figure 10: Unsecured Loan Class

Explanation: UnsecuredLoans class inherits the Loans class to take the properties in
common. However, instead of set Interest Rate by function, the InterestRate property of this
one will be assign to 21 whenever the instance of UnsecuredLoans is initialized(It may look a
bit illogical because client code also could call setInterestRate to set the interest rate of it.
Although this issue partly might be solved by using the factory method it will hide the
concrete class, I also could optimize by setting the Loans class to abstract class and the
SetInterestRate method would be abstract; so, each class could implement it or do nothing
with it).
The RequiredIncome property also would be set to 4000 whenever the instance of
UnsecuredLoan class is initialized.
Like HotLoans, the constructor of UnsecuredLoans also takes three parameter:
amount(double), user(User), loanTerm(double) and the properties also would be assigned
based on the inputted parameter. This one also overrides the ToString() method to return its
own output.
 OverdraftLoans Class


Figure 11: Overdraft Loan Class

Explanation: Above class inherits the Loans class to take the properties in common. However, this
class declares two new properties: Collateral(Item) defining the Collateral that user use it to make
the Overdraft Loan package and BankAccount(Bank) which store the information for bank
account of the user because of the feature of Overdraft(Overdraft Loan will decide the Loan limit
based on the balance of user’s bank account). The RequiredIncome property also would be set to
5000 whenever the instance of the OverdraftLoan class is initialized.
Because Overdraft Loan has two options which are making an Overdraft Loan without Collateral
and without Collateral, The Interest and something else also change based on two options. So,
this class also applies overloading to have two constructors with a different number of
parameters. The first constructor of OverdraftLoans will take the option in which the user has
collateral and it takes five parameters: amount(double), user(User), loanTerm(double),
bank(Bank) and collateral(Item) and the properties also would be assigned based on the inputted
parameter. The other Constructor will take less than the first constructor one parameter and it is
collateral(Item) because the second constructor will meet the option which doesn’t have
collateral. This one also overrides the ToString() method to return its own output.


 InstalmenLoans Class

Figure 12: InstalmentLoan Class

Explanation: This class inherits the Loans class to take the properties in common. However,
this class declares two new properties: Item(Item) defining the instalment Item that user
want to make the Instalment Loan package to help buy it and Prepayment(Bank) which store
the amount that the user needs to pre-pay before the office disburse this loan to the user.
The RequiredIncome property also would be set to 6000 whenever the instance of the
InstalmentLoan class is initialized.
The constructor of InstalmentLoans will take four parameters: amount(double), user(User),
loanTerm(double), and Item(Item) and the properties also would be assigned based on the

inputted parameter.
Specifically, unlike other concrete Loan Classes, this class declares the new method for only
this one and it is the SetPrepayment method. This method will get the double input as a
paramenter and assign this parameter for the prepayment property of its object. This one
also overrides the ToString() method to return its own ouput.


 MortgageLoans Class

Figure 13: MortgageLoan class

Explanation: This class also inherit the Loans class to take the properties in common.
Nevertheless, this class declares two new properties: Collateral(Item) defining the Collateral
that user use it to make the Mortgage Loan package and Purpuse(string) which store the
purpose why the user wants to make this mortgage Loan.
Because Mortgage Loan always need a collateral, the constructor of MortgageLoans will take
five parameters: amount(double), user(User), loanTerm(double), purpose(string) and
collateral(Item) and the properties also would be assigned based on the inputted parameter.
Specifically, this class also declare the new method and it is the SetRequiredIncome method.
This method will get the double input as a paramenter and assign this parameter for the
RequiredIncome property of its object. This one also overrides the ToString() method to return
its own ouput.


1.2.

Client Concrete Classes
As I said in the class diagram, Client concrete classes are some classes created to store and define
the information for the client-side. They include User, Bank and Item classes.
a) User Class

Figure 14: User Class

Explanation: Because this class was created to define and store the particular information of
the user, it and its objects are used, called and initialized widely and frequently in other classes
such as 5 factory concrete classes, Credit Checker classes, calculator classes and also in GUI
code.
The properties of this User class have been introduced in the class diagram above. This class has
two constructors, the first constructor is called when the user enters their bank account as their
information and the second one is called when the user signs up for this app without any bank
account.
For testing the ability of the Credit checker service, the LoanStatus of this Loan will be random
whenever the instance of the user class is initialized. This method will be random based on the
length of StatusType.
SetLoanStatus method will get the StatusType input as a parameter and assign this parameter
for the LoanStatus property of its object, this function is used in the GUI logic when the user
disposes of the loan suddenly or they violate the Loan principles.


GetLoanList method has applied for each loop and some simple lambda expressions to get all
the Loan information, concat and return them as a string. The setLoanList method will get the
Loans input as a parameter and add this parameter for the LoanLists property of its object. The
RemoveLoanList has the reverse functionality with SetLoanList, it will remove the Loan based on
the inputted index in Loanlist. GetLoan is quite like the normal getter, it just returns the Loan by
the transmitted index from the client code. This one also overrides the ToString() method to
return its own output.
b) Bank Class

Figure 15:Bank Class

Explanation: The properties of this class have been introduced in the class diagram above. The
constructor of it will take three parameters: name(string), cardNumber(string),
expiredDate(string) and the properties also would be assigned based on the inputted
parameter.
The ReceiveMoney method will get the double input as a paramenter and increase this balance
property based on the parameter. The PayMoney method has the same logic with
ReceiveMoney method but it will decrease based on the parameter. For testing purpose,
RandomBalance method will perform random in range and return the double for constructor
assign it to balance property.
This one also overrides the ToString() method to return its own output.


c) Item Class

Figure 16: Item class

Explanation: This one may be the most simple concrete class in my program. The objects of this
class frequently be initialized for mortgage Item or Collateral and they commonly are created in
GUI code. Its properties of it already have been introduced in class diagram.
It has overloaded the constructor to have two constructors with different number of
parameters. The first one will take their parameters: name(string), value(double) and
document(bool) it will be used when the Collateral has a document and the second constructor
will be used when the object of this class will be initialized for creating an instalment item. This
one also overrides the ToString() method to return its own output.
1.3.

Credit Checker Classes
According to the scenario and class diagram, credit seems to be a very crucial part of this Loan
Online app. So, making the Credit checking system become more important and the principles of
Credit checking service will change time by time and maybe in the future when this office extends

the number of Loan Packages or extends more online financial services, these Credit checkers might
become more scalable. So, to make the Credit Checkers could be more straightforward to extend, I
put each Credit checking logic into separate classes and set their objects could be interchangeable.
Here are the explain of Credit Checker Classes:


a) IcreditChecker Interface
Explanation: The IcreditChecker interface declares the
CreditCheck function with the type is CreditType in common to
all supported methods of some credit checker classes which
implement this interface. This interface also supports the
ServiceChecker class below to call the checking logic defined
by CreditChecker Concrete classes. The parameter of this
method is user(User).
Figure 17: ICreditChecker interface

b) FastCreditChecker class

Figure 18: FastCreditChecker Class

Explanation: FastCreditChecker class implement the IcreditChecker and executes some checking
logic while following the base ICreditChecker interface. In the CreditCheck method, the user object
transmitted via the parameter will be checked with some very simple logic(it’s just a hypothesis
checking logic which is partly supposed for the fast-check in real-world and return the result for
UnsecuredLoan and Overdraft credit).
The base condition is that the Identity Card is not null and income is just needed. In case the age of
the user is older than 20 the loan status is not bad, the Credit type return will be High. If the
previous case is missed, the second case will check that the user just needs to be older than 18 and
loan status is not bad, the credit type returned is Medium. Any other case will return the Credit type
will be Low.