Nguyên tắc SOLID

S: Một Class chỉ nên thực hiên một công việc, tách nhỏ từng
class ra để sau này dễ maintain

O: Khi thêm một chức năng cho một class ko nên sữa class
đó mà nên kế thừa class đó rồi sữa, ko làm ảnh hưởng đến
class cũ. + Ví dụ class A dùng ở 50 chỗ trên chương trình thì
sữa chết lun.

L: class con thay thế được class cha nhưng ko làm thay đổi
tính đúng đắn của chương trình.+Ví dụ: class Vịt khi tạo các
Class con kế thừa class vịt như vịt đen vịt trời, nhưng nếu là
vịt cau su thì sẽ làm mất đi tính đúng đắn chương trình

I: Thay vì chúng ta sử dụng 1 interface lớn thì nên tách nhỏ ra

để sử dụng, ví dụ có 100method có những class cần class ko
cần. Ví dụ: Ta tạo một Interface có các phương thức thuộc
tính: Bay, Bơi, Đi Bộ. Thì nếu như con chó nó kế thừa cái
Interface đó thì nó sẽ phải thực thi hết à? Nên là Tách
Interface ra từng cụm nhất định để dễ dàng quản lý,
inplement

D: các module cấp cao ko được phụ thuộc vào module cấp
thấp mà nó nên được phụ thuộc vào interface module cấp
thấp. Ví dụ: muốn đổi toàn bộ Service A thành B thì chỉ cần
quan tâm đến interface của nó( cấu trúc của nó).

Design Pattern

-có một class vịt là class cha có: bay kêu bơi, có class con của con vịt bay kêu bơi như con vịt, mọi thứ
rất ổn không có gì xảy ra , đột nhiên vịt cỏ xuất hiện: kêu , bơi được nhưng ko bay được. điều đầu tiên
là chúng ta overite bay ở con vịt, nhưng làm vậy có đúng k? xong rồi cái tất cả con vịt nào ko bay được
như vịt cỏ, con nào k bay được thì in ra “ko bay” còn tất cả con vịt bay được thì”bay được”.

vấn đề bắt đầu một ngày đẹp trời bạn đi làm ông khách hàng yêu cầu thằng nào k bay được thì in ra
” con này ko bay được” rồi lôi những con vịt k bay được ra đổi lại? rồi mai bảo đổi lại như cũ.

ở trog thực tế mà ta phải đổi đi đổi lại một String rất nhiều lần thì sử dụng kế thừa có tốt không, kế
thừa vẫn tốt nếu chỉ có 1 loại behaviours một là bay hết 2 là ko bay hết, vì thay đổi quá nhiều lần quá
nhiều chỗ -> quá tải cho mình, phải làm thế nào để hạn chế thay đổi ở class con?

Solutions: có rất nhiều class con chung quy lại có 2 hoặc vài loại hành vi nhất định ví dụ hành vi bay thì
có: ko bay , bay cao, bay thấp. ->áp dụng design patter đưa 3 cách bay đó thành 3 thuật toán khác
nhau cho hàm bay, nó implement interface khác, có nghĩa là từng thằng ko bay được 1 chỗ, bay cao 1
chỗ, bay thấp 1 chỗ.

Tất cả bọn nó imp từ 1 interface có nghĩa là chúng ta có thể sử dụng interface đó 1 cách độc lập trong
class con vịt, ví dụ class cho có hàm bay thì tất cả những thằng con đều có hàm bay vì được đóng gói
trong thằng vịt, ở trong thằng vịt ta có hàm set vào hàm bay của con vịt, ví dụ ta khởi tạo con vjt cỏ thì
ta có thể set khả năng bay của nó vào “ko bay”. Ví dụ khi khởi tạo thằng vịt cỏ ta cho nó”k bay” thì gọi
hàm bay của nó ->”k bay” tại nó được imp vào ròi!. Ví dụ thằng vịt trời ta set “bay cao” vào. Ví dụ
chúng ta muốn thay đổi “bay cao” “bay thấp”… thì chúng ta có thể thay đổi trong những cái imp nhỏ
thì hạn chế thay đổi code trong class con. Nếuhệ thống đang chạy mà một lúc nào đó , ví dụ vịt cỏ tiến
hóa thì ta có thể set cái “bay cao” vào con vịt cỏ bằng những imp của inter đã tạo trước đó.
 Tại sao nên dùng strategy design pattern: có một đoạn
code nào đó thay đổi quá nhiều lần thì ta dùng.. để tách
phần đó ra khỏi chương trình chính đưa ra chỗ khác, ví
dụ chỗ này nọ xài class a xài b xài mà đùng 1 phát mình
thay đổi thì phải đổi rất nhiều chỗ, thay vì we sữa từng
chỗ thì gom lại rồi sữa, TH2: ví dụ tất cả con vit bay được
thì imp hàm bay rồi qua đống k bay được thì imp quá
nhiều->mệt, tách ra. TH3: thay đổi behaviours: