SOLID:

1. Single Responsibility Principle:

2. Open-closed Principle
3. Liskov Subtitution Principle
4. Interface Segregation Principle
5. Dependency Inversion Principle

1. Single Responsibiltiy Principle:

Một class chỉ nên giữ một trách nhiệm duy nhất

Một class nếu giữ quá nhiều chức năng sẽ trở nên cồng kềnh. Với sự phát triển của ứng dụng
dẫn tới sự thay đổi của code. Nếu 1 class có quá nhiều chức năng thì sẽ khó thay đổi, tốn nhiều tg
thay đổi và còn có thể ảnh hưởng đến nhiều module khác ==>để dễ dàng cho việc bảo trì và mở rộng
sau này thì nên thiết kế theo hướng Single Responsibility

2. Open-closed Principle
Nên hạn chế việc thay đổi 1 class mà thay vào đó hãy xem xét để mở rộng

+) Hạn chế sửa đổi : K nên chỉnh sửa soure code của một module hay một class có sẵn vì nó sẽ
làm ảnh hưởng đến tính đúng đắn của chương trình.
+) Ưu tiên mở rộng: Khi cần thêm chức năng mới nên kế thừa và mở rộng các module có sẵn
thành các module con lớn hơn. Các module con có sẵn đặc tính của lớp cha, vừa được bổ sung tính
năng mới phù hợp với yêu cầu

Một trong những cách để thay đổi là “kế thừa” từ class cũ

3. LisKov Subtitution Principle:

Các lớp cha nên có thể thay thế được bằng các đối tượng của lớp con mà không ảnh hưởng đến
tính đúng đắn của chương trình.

4. Interface Segregation Principle

Chia nhỏ các interface để khi các class hoặc interface implement không bị dư thừa

- Có thể chia thành phần chung để cho tất cả sự dụng và phần rieeng biệt cho từng interface
hoặc class implement
5. Dependendcy Inversion:
 Mỗi thành phần của hệ thống chỉ nên phụ thuộc vào các abstracttion hoặc interface, không nên
phụ thuộc vào các lớp cụ thể

Ý nghĩa thứ nhất:

class ChinaEngine { ... }

class Car {
private ChinaEngine engine;
public Car() {
// Khi tạo Car thì nhớ gắn engine vào :D
engine = new ChinaEngine();
}
}
Code trên sự phụ thuộc của Car vào ChinaEngine rất mạnh
=>> dẫn đến khó khắn khi:
+ muốn thay đổi động cơ cần sửa class Car =>> tính phụ thuộc rất lớn
+ Khó có thể thêm loại xe có động cơ khác vào nếu k can thiệu vào để sửa code =>>
kjhó sửa đổi, bảo trì

Interface Engine{}
Class ChinaEngine implement Engine{}
Class Car {
// một loại engine nào đó, lợi dụng tính đa hình trong OOP
Private Engine engine;
// Khi khởi tạo Car thì tạo engine trước rồi inject vào constructor này
Public Car(Engine engine){
This.engine = engine;
}
}
Với code sau khi sửa đổi lúc này mqh giữa Cả và ChinaEngine đã lỏng lẻo hơn rất nhiều chúng ta
dễ dàng thêm các loại động cơ khác vào

Class VNEngine implement Engine{}

Khi khởi tạo:
Engine goodEngine = new VNEngine();
Engine cheapEngine = new ChinaEngine();
// Tạo xe, khi tạo thì gắn động cơ vào (qua constructor)
Car myCar = new Car(goodEngine);
Car yourCar = new Car(cheapEngine); // and bad :)

Ý nghĩa thứ 2: abstraction không nên phụ thuộc vào chi tiết, mà ngược lại

chúng ta chỉ cần biết abstraction Engine có method là run, còn những loại động cơ khác
nhau thực hiện run như thế nào (chi tiết) thì không cần quan tâm

// Mọi loại Engine đều có thể run

interface Engine { void run(); }
// Động cơ VNEngine run theo hiểu khác
class VNEngine implements Engine {
public void run() { // Run nhanh, bền, ít tốn xăng }
}
// Động cơ ChinaEngine run theo kiểu khác
class ChinaEngine implements Engine {
public void run() { // Run nhanh, bền nhưng tốn xăng }
}