Download Application Development with Class Diagrams and Design Patterns and more Assignments Advanced Algorithms in PDF only on Docsity!
ASSIGNMENT 2 FRONT SHEET
Qualification BTEC Level 5 HND Diploma in Computing Unit number and title Unit 20: Advanced Programming Submission date September 13 th^ 2022, Date Received 1st submission September 11 st^ 2022, Re-submission Date Date Received 2nd submission Student Name Ha Quang Thong Student ID GCS 200763 Class GCS0903A Assessor name Lâm Nguyễn Trung Nam 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 THONG Grading grid P3 P4 M3 M4 D3 D
Summative Feedback: Resubmission Feedback:
Grade: Assessor Signature: Date: Lecturer Signature:
- Result of a small program implemented based on the class diagram, explain how you translate from design diagram to code.
- Discussion of a range of DPs related / similar to your DP, evaluate them against your scenario and justify your choice (why your DP is the most appropriate in that case). Learning Outcomes and Assessment Criteria Pass Merit Distinction LO 3 Implement code applying design patterns P3 Build an application derived from UML class diagrams. M3 Develop code that implements a design pattern for a given purpose. D3 Evaluate the use of design patterns for the given purpose specified in M3. LO4 Investigate scenarios with respect to design patterns P4 Discuss a range of design patterns with relevant examples of creational, structural and behavioral pattern types. M4 Reconcile the most appropriate design pattern from a range with a series of given scenarios. D4 Critically evaluate a range of design patterns against the range of given scenarios with justification of your choices.
Table of Contents
- Introduction
- Scenario analysis
- Implementation
- 3.1 Code
- User Interface
- Class Book
- Class Booklist
- Addbook Command
- Delete Book Command...............................................................................................................................
- Exit program
- Show command
- 3.2 Program screenshots
- Create a new book....................................................................................................................................
- Delete book
- Discussion
- 4.1 Range of similar patterns
- o Creational design patterns
- o Structural design patterns
- o Behavioral design patterns
- 4.2 Usage of pattern
- Benefit while using app
- Disadvantage
LibaryManageSystem : can request the BookList to execute add, remove or showing book
3. Implementation
3.1 Code User Interface
Class Book Class Booklist
Show command 3.2 Program screenshots Create a new book
Delete book
4. Discussion
Design patterns are conventional responses to typical issues that arise in software design. To fix a reoccurring design issue in your code, you can modify them like pre-made blueprints. When using pre-made functions or libraries, you may simply find a pattern and copy it into your software. The pattern is a broad idea for addressing a specific issue rather than a specific piece of code. You can implement a solution that works for the specifics of your application by adhering to the pattern's instructions. 4.1 Range of similar patterns o Creational design patterns The development of objects or classes is made possible by this tool, as the name would imply, and thus increases the code's adaptability and reuse. In order to avoid dealing with the complicated architecture, they lessen dependency and regulate how users interact with our class. Builder Create connected defendant objects in the same way as an abstract factory would. Abstract Factory designs are being used to construct groups of items that are connected or defendant on one another. It also referred as "the factory lord." Factory Method Singleton Prototype
You quickly conclude that this strategy is seriously faulty. First of all, there are a ton of subclasses, which would be OK if you didn't run the risk of breaking the code in these subclasses whenever you changed the main Button class. Simply put, the volatile code of the business logic has become awkwardly dependant on your GUI code. The worst part is right here. Some activities, such copying and pasting text, might require numerous calls to execute. For instance, a user might utilize the context menu, the little "Copy" icon on the bar, or merely the keyboard shortcut Ctrl+C to copy something. The implementation of numerous operations could initially be placed in the button subclasses when our program simply had the toolbar. In other words, it was OK to include the text copying code inside the Copy Button subclass. But when you add context menus, shortcuts, and other features, you have to repeat the operation's code over several classes, which is a bad idea, or make menus dependent on buttons, which is even worse. Figure 2 : Each button similar subclasses
A GUI object could call a method of a business logic object in the code by handing it certain parameters. One common way to characterize this process is as one item making a request of another. The Command pattern advises against using GUI objects to explicitly deliver these queries. Instead, you must extract all of the request information, including the object being invoked, the method name, and the list of arguments, and place it in a different command class with a single method that initiates this request. Links between various GUI and business logic items are provided via command objects. The GUI object is no longer required to know which piece of business logic will receive the request or how it will be handled. The GUI object only initiates the command, which takes care of every aspect. Making your commands implement the same interface is the next step. Typically, it has a single, parameter less execution method. This interface decouples it from specific classes of commands and allows you to use many commands with the same request sender. Additionally, you may now change command objects that are associated to the sender, allowing you to dynamically alter the sender's behavior. The request parameters are one of the puzzle's missing pieces, as you may have seen. It's possible that a GUI object gave the business-layer object certain parameters. How would we communicate the specifics of the request to the recipient given that the command execution mechanism lacks any
