Download Assignment 2 unit 20 Advanced Programming and more Assignments Advanced Data Analysis in PDF only on Docsity!
ASSIGNMENT 2 FRONT SHEET
Qualification TEC Level 5 HND Diploma in Computing Unit number and title Unit 20: Advanced Programming Submission date Date Received 1st submission Re-submission Date Date Received 2nd submission Student Name Student ID Class Assessor name 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 D
❒ Summative Feedback: ❒ Resubmission Feedback:
Grade: Assessor Signature: Date: Internal Verifier’s Comments: Signature & Date:
Table of contents
- Table of contents........................................................................................................................
- I. Introduction............................................................................................................................
- II. Build an application derived from UML class diagrams......................................................
- III. Design Patterns..................................................................................................................
- What is design pattern......................................................................................................
- When use design patterns.................................................................................................
- Categorization of patterns................................................................................................
- 3.1 Creational Pattern.......................................................................................................
- 3.1.1 Factory pattern....................................................................................................
- 3.1.2 Abstract Factory Pattern.....................................................................................
- 3.1.3 Builder Pattern....................................................................................................
- 3.1.4 Singleton Pattern.................................................................................................
- 3.1.5 Prototype Pattern.................................................................................................
- 3.2 Structure Patterns.......................................................................................................
- 3.2.1 Adapter Pattern...................................................................................................
- 3.2.2 Bridge Pattern.....................................................................................................
- 3.2.3 Composite Pattern...............................................................................................
- 3.2.4 Decorator Pattern................................................................................................
- III.1.5 Flyweight Pattern..............................................................................................
- 3.3 Behavior Patterns.......................................................................................................
- 3.3.1 Chain-of-responsibility Pattern...........................................................................
- 3.3.2 Command Pattern................................................................................................
- 3.3.3 Observer Pattern..................................................................................................
- 3.3.4 State Pattern........................................................................................................
- 3.3.5 Strategy Pattern...................................................................................................
- IV. Conclusion.........................................................................................................................
- V. References...........................................................................................................................
I. Introduction
Based on the class diagram created in assignment 1, in this assignment I will build an application derived from that UML class diagram. Then, I will cover a series of design patterns with relevant examples of creative, structural, and behavioral patterns. My report includes two parts: Build an application derived from UML class diagram. Design patterns.
II. Build an application derived from UML
class diagrams.
I have just made a contract with FPT company and are about to be appointed as a project leader for a group of programmers to develop its Product Management System. In this Product Management System, I am required to create an application to store list of products and list of products. With the system, the user can enter information about technology products and home appliances such as id, name, price, … in the system, correct the information if it is incorrect, or completely delete the information of the product. View a list of all of the system’s products. To create this system, I used the Java programming language. My product management system includes the following features:
- Add a technology product
- Display list of technology product
- Update a technology product
- Delete a technology product
- Add a houseware product
- Display list of houseware product
- Update a houseware product
- Delete a houseware product. Below is the main menu of the program.
Figure 1. Main menu And below is the result of the program.
- Add a Tech product The first is the feature of adding a new technology product. With this feature, I will enter product information such as id, name, price, description.
- Update a tech product When I need to update information technology product, I will choose the third feature " Update a tech product”. List of technology products before updating.
And list of technology products after updating.
- Delete a tech product List of technology products before deleting. And list of technology products after deleting.
The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations. The solution is not the complete code, but it works as a template which can be fulfilled with code. Instead, the pattern provides an abstract description of a design problem and how a general arrangement of elements (classes and objects in our case) solves it. The results and consequences of applying the pattern.
2. When use design patterns Flexibility: Using design patterns, your code becomes flexible. It helps to provide the correct level of abstraction so that objects are loosely linked together, which makes your code easy to change. Reusability: Loosely coupled and cohesive objects and classes can make your code more reusable. This kind of code becomes easier to test than highly coupled code. Shared Vocabulary: Shared vocabulary makes it easy to share your code and thought with other team members. It creates more understanding between the team members related to the code. Design patterns make it easier to reuse successful designs and architectures. 3. Categorization of patterns Design patterns can be categorized in following categories: Creational patterns create objects for you. These give you some flexibility in using different object types in different scenarios. For example, you don't need to prepare your own value meal when you go to a fast-food restaurant. There are many different varieties but all serve the same goal of giving you a meal (with modest nutritional value). Instead, a staff member takes your order and prepares the meal for you. Here is an example of a builder pattern. Structural patterns are about composing several objects into larger structures. A simple example is like a power adapter. The European wall socket has two round pins and the power supply is 220V. An unfortunate North American may have an appliance whose plug will not fit and will expect a measly 110V. Thus, an adapter is needed so that every traveler need not worry about how to bridge this electrical divide herself. Here's an example of one of the simplest structural patterns, called (not surprisingly) an adapter. Ultimately, behavior patterns are about communication and flow control. A common example is someone subscribing to a magazine. Subscribers cannot keep track of all the details on topics they might be interested in, but periodically they receive a succinct update on relevant information. This type of pattern is called an observer, in which automatic status updates about one object are sent automatically to another object (the subscriber).
The below table shows the list of patterns under their respective categories: Figure 2. List of patterns
3.1Creational Pattern
As their name suggests, the family of creational patterns all deal with creating instances of objects. The OOP principle of polymorphism allows our programs to work flexibly with many different specific types of objects that share particular properties. The specific, runtime object type is sometimes unimportant and depends on the situation. We can extend this idea to the act of creating objects as well. While there are several standard creational patterns, we will consider four: factory, abstract factory, builder, and singleton. Let us look at each of these in more detail. 3.1.1 Factory pattern Definition : Factory pattern provides a way to use an instance as an object factory. The factory may return an instance of one of several possible classes (in the subclass hierarchy), depending on the data provided to it. When to use : When a class can't anticipate which kind of class of object it must create. You want to localize the knowledge of which class gets created. When you have classes that is derived from the same subclasses, or they may in fact be unrelated classes that just share the same interface. Either way, the methods in these class instances are the same and can be used interchangeably. When you want to insulate the client from the actual type that is being instantiated.
When Test is executed, the result is: 3.1.2 Abstract Factory Pattern Definition : The Abstract Factory pattern is a creational pattern which is related to the Factory Method pattern, but it adds another level of abstraction. When to use : The Abstract Factory is often employed when there is a need to use different sets of objects and where the objects could be added or changed sometime during the lifetime of an application. Benefits : Use of this pattern makes it possible to interchange concrete classes without changing the code that uses them, even at runtime. 3.1.3 Builder Pattern Definition : The Builder pattern can be used to ease the construction of a complex object from simple objects. The Builder pattern also separates the construction of a complex object from its representation so that the same construction process can be used to create a different composition of objects. Related patterns include Abstract Factory and Composite. When to use : When the algorithm for creating a complex object should be independent of the parts that make up the object and how they are assembled. When the construction process must allow different representations for the object that is constructed.
When you want to insulate clients from the knowledge of the actual creation process and/or resulting product. Benefits : The built object is shielded from the details of its construction. Code for construction is isolated from code for representation and both are easy to replace without affecting the other. Gives you control over the construction process. Gives you the possibility to reuse and/or change the process and/or product independently. 3.1.4 Singleton Pattern Definition : While the singleton pattern falls in with other creational patterns, it is somewhat distinctive in that it limits creation of objects. A singleton restricts a class to one and only one instance, providing a single, global means of accessing that instance. When to use : When only one instance or a specific number of instances of a class are allowed. Facade objects are often Singletons because only one Facade object is required. Benefits : Controlled access to unique instance. Reduced name space. Allows refinement of operations and representations. 3.1.5 Prototype Pattern Definition : The Prototype pattern is basically the creation of new instances by duplicating existing instances. By creating a prototype, new objects are created by copying this prototype. When to use When a system needs to be independent of how its objects are created, composed, and represented. When adding and removing objects at runtime. When specifying new objects by changing an existing object’s structure. When configuring an application with classes dynamically. When keeping trying to keep the number of classes in a system to a minimum. Benefits
3.2.2 Bridge Pattern Definition : Decouple an abstraction or interface from its implementation so that the two can vary independently. Bridge makes a clear-cut between abstraction and implementation. When to use : When you want to separate the abstract structure and its concrete implementation. When you want to share an implementation among multiple objects, when you want to reuse existing resources in an 'easy to extend' fashion. When you want to hide implementation details from clients. Changes in implementation should have no impact on clients. Benefits : Implementation can be selected or switched at run-time. The abstraction and implementation can be independently extended or composed. 3.2.3 Composite Pattern Definition : The Composite pattern helps you to create tree structures of objects without the need to force clients to differentiate between branches and leaves regarding usage. The Composite pattern lets clients treat individual objects and compositions of objects uniformly. Where to use When you want to represent a part-whole relationship in a tree structure. When you want clients to be able to ignore the differences between compositions of objects and individual objects. When the structure can have any level of complexity and is dynamic. Benefits Define class hierarchies consisting of primitive objects and composite objects. Makes it easier to add new kind of components. 3.2.4 Decorator Pattern Definition : The Decorator pattern lets you attach additional responsibilities and modify an instance functionality dynamically. Decorators provide a flexible alternative to subclassing for extending functionality, using composition instead of inheritance. Where to use When you want to add responsibilities to individual objects dynamically and transparently, without affecting the original object or other objects.
When you want to add responsibilities to the object that you might want to change in the future. When extension by static subclassing is impractical. Benefits More flexibility than static inheritance. Avoids feature-laden classes high up in the hierarchy. Simplifies coding because you write a series of classes each targeted at a specific part of the functionality rather than coding all behavior into the object. Enhances the object's extensibility because you make changes by coding new classes. III.1.5 Flyweight Pattern Definition Flyweight pattern provides a mechanism by which you can avoid creating a large number of 'expensive' objects and instead reuse existing instances to represent new ones. Where to use When there is a very large number of objects that may not fit in memory. When most of an object’s state can be stored on disk or calculated at runtime. When there are groups of objects that share state. When the remaining state can be factored into a much smaller number of objects with shared state. Benefits Reduce the number of objects created, decrease memory footprint and increase performance. Example of Structure pattern Here, I will take the example of adapter pattern. First, I will create interfaces for CreditCard. Then, I will create a BankDetails class.
