Download Challenging major OOP exercises and more Exercises Information Technology in PDF only on Docsity!
Lý thuyết nguyên lý thiết kế hướng đối tượng SOLID
SOLID principles are object-oriented design concepts relevant to software development. SOLID is an acronym for five other class-design principles: S ingle Responsibility Principle, O pen-Closed Principle, L iskov Substitution Principle, I nterface Segregation Principle, and D ependency Inversion Principle. Principle Description Single Responsibility Principle Each class should be responsible for a single part or functionality of the system. Một lớp chỉ nên có 1 vai trò/1 chức năng/1 phần trong tổng thể hệ thống Open-Closed Principle Software components should be open for extension, but not for modification. Khi muốn tạo ra sự thay đổi thì
- không phải thông qua việc chỉnh sửa code của class
- mà thông qua kế thừa nó Liskov Substitution Principle Objects of a superclass should be replaceable with objects of its subclasses without breaking the system. Các đối tượng của lớp cha PHẢI CÓ THỂ THAY ĐƯỢC bằng các đối tượng của lớp con MáyTính RAM ^ ^ | |___RAM_CủaHãngSamsung | |___RAM_CủaHãngHP Interface Segregation Principle No client should be forced to depend on methods that it does not use. nên gom nhóm các method thành interface có liên quan
interface: dùng để mở rộng hệ thống Dependency Inversion Principle High-level modules should not depend on low-level modules, both should depend on abstractions. SOLID is a structured design approach that ensures your software is modular and easy to maintain, understand, debug, and refactor. Following SOLID also helps save time and effort in both development and maintenance. SOLID prevents your code from becoming rigid and fragile, which helps you build long-lasting software.
1. Single responsibility principle
Every class in Java should have a single job to do. To be precise, there should only be one reason to change a class. Here’s an example of a Java class that does not follow the single responsibility principle (SRP): The Vehicle class has three separate responsibilities: reporting, calculation, and database. By applying SRP, we can separate the above class into three classes with separate responsibilities.
2. Open-closed principle
Software entities (e.g., classes, modules, functions) should be open for an extension, but closed for modification. Consider the below method of the class VehicleCalculations: Suppose we now want to add another subclass called Truck. We would have to modify the above class by adding another if statement, which goes against the Open-Closed Principle. A better approach would be for the subclasses Car and Truck to override the calculateValue method:
The Interface Segregation Principle (ISP) states that clients should not be forced to depend upon interface members they do not use. In other words, do not force any client to implement an interface that is irrelevant to them. Suppose there’s an interface for vehicle and a Bike class: As you can see, it does not make sense for a Bike class to implement the openDoors() method as a bike does not have any doors! To fix this, ISP proposes that the interfaces be broken down into multiple, small cohesive interfaces so that no class is forced to implement any interface, and therefore methods, that it does not need.
5. Dependency inversion principle
The Dependency Inversion Principle (DIP) states that we should depend on abstractions (interfaces and abstract classes) instead of concrete implementations (classes). The abstractions should not depend on details; instead, the details should depend on abstractions. Consider the example below. We have a Car class that depends on the concrete Engine class; therefore, it is not obeying DIP.
The code will work, for now, but what if we wanted to add another engine type, let’s say a diesel engine? This will require refactoring the Car class. However, we can solve this by introducing a layer of abstraction. Instead of Car depending directly on Engine, let’s add an interface: Now we can connect any type of Engine that implements the Engine interface to the Car class:
Chiến lược sắp xếp dãy được “tiêm” (inject) vào cho MyDataStructure.
Bài tập về nhà - Quản lý thông tin bãi giữ xe
Một bãi giữ xe có quy tắc hoạt động như sau:
- Bãi xe nhận giữ xe ô tô, xe máy và xe đạp.
- Khi xe được đưa vào bãi, nhân viên bãi giữ xe sẽ ghi nhận các thông tin cần thiết của xe lúc vào bãi (tuỳ từng loại xe sẽ có các loại thông tin khác nhau cần ghi nhận, sẽ được mô tả chi tiết bên dưới)
- Việc tính tiền giữ xe được xác định khi xe đưa ra khỏi bãi, chủ yếu căn cứ vào tổng thời gian xe được gửi trong bãi. Phần dưới đây mô tả chi tiết về thông tin, nghiệp vụ lúc gửi xe và lấy xe ra khỏi bãi. Thông tin ghi nhận khi xe vào bãi:
- Nếu là xe ô tô: biển số xe, thời điểm vào bãi, tình trạng xe lúc vào bãi
- Nếu là xe máy: biển số xe, thời điểm vào bãi
- Nếu là xe đạp: số vé xe (do nhân viên ghi), thời điểm vào bãi
Thông tin ghi nhận lúc xe ra khỏi bãi:
- Nếu là xe ô tô: biển số xe, thời điểm ra, tình trạng xe lúc ra khỏi bãi
- Nếu là xe máy: biển số xe, thời điểm ra
- Nếu là xe đạp: số vé xe, thời điểm ra Các giá trị dữ liệu ví dụ bao gồm:
- Tình trạng xe ô tô (lúc vào bãi giữ xe, lúc ra khỏi bãi giữ xe): NULL (bình thường, không có gì đáng lưu ý), “Bị xước ở cửa bên trái, phía trước”, “Bị vỡ đèn phía sau”, …
- Thời điểm vào, Thời điểm ra: 2023/12/31 10:30:38, …
- Biển số xe: 75A-23456, 38A-12345, 73S-98765, …
- Số vé xe: 001, 009, 382, … Giá tiền gửi xe được xác định lúc xe ra khỏi bãi, theo quy tắc sau: ● Đối với xe ô tô: 5000 đồng/0.5 giờ. Thời gian gửi xe được làm tròn đến 0.5 giờ, tức là, nếu gửi xe 2 giờ 5 phút thì được tính thành 2.5 giờ. Riêng trường hợp có phát sinh tình trạng bất thường (tình trạng của xe lúc vào bãi khác với tình trạng của xe lúc ra khỏi bãi) thì ghi nhận không xác định giá tiền gửi xe. ● Đối với xe máy: 3000 đồng/ngày-đêm. Thời gian gửi xe được làm tròn đến ngày-đêm, tức là nếu gửi xe 30 phút thì được tính thành 1 ngày-đêm, nếu gửi xe 1 ngày-đêm 20 phút thì được tính thành 2 ngày-đêm. ● Đối với xe đạp: 2000 đồng/ngày-đêm. Thời gian gửi xe được làm tròn đến ngày-đêm, theo quy tắc làm tròn đối với xe máy. Với những quy tắc nghiệp vụ nêu trên, hãy thiết kế chương trình:
- Nhập thông tin xe vào bãi dưới dạng một file văn bản, mỗi dòng tương ứng với một lượt xe vào, bao gồm 5 trường dữ liệu cách nhau bởi dấu chấm phẩy (;): Loại xe; Biển số xe; Số vé xe; Thời gian vào bãi; Tình trạng xe lúc vào bãi Tùy vào từng loại xe mà một số trường dữ liệu sẽ không có giá trị. Những trường dữ liệu nào không có thì sẽ nhận giá trị là "Not Available". Loại xe được quy định như sau: 4 là xe ô tô, 2 là xe máy, 0 là xe đạp. Tình trạng xe lúc vào bãi được quy định như sau: Nếu xe không có bất thường nào thì có giá trị là "Binh thuong". Nếu xe có bất kỳ bất thường nào (ví dụ bị trầy xước, mất kính chiếu hậu...) thì phải mô tả rõ. Dưới đây là một file đầu vào như vậy:
- Nhập thông tin xe đi ra khỏi bãi dưới dạng một file văn bản, mỗi dòng tương ứng với một lượt xe ra khỏi bãi, có định dạng như sau: Loại xe; Biển số xe; Số vé xe; Thời gian ra bãi; Tình trạng xe lúc ra bãi Tùy vào từng loại xe mà một số thông tin sẽ không có giá trị. Những thông tin nào không có thì sẽ nhận giá trị là "Not Available". Các thông tin trên được phân cách với nhau bởi dấu chấm phẩy (;). Loại xe được quy định như sau: 4 là xe ô tô, 2 là xe gắn máy, 0 là xe đạp. Giá trị của trường dữ liệu "Tình trạng xe lúc ra bãi" (dành cho xe ô tô) được mô tả như sau:
- Nếu xe không có phát sinh bất thường nào khi ra bãi (so với lúc vào bãi) thì giá trị của thông tin này là "Binh thuong".
