[C++ OOP Thực Chiến] Bài 41: Các kiểu kế thừa - Khám phá "gia phả" của hệ thống Class

Chào anh em! Từ đầu chương Kế thừa đến giờ, chúng ta thường xuyên làm việc với cấu trúc 1 Lớp Cha đẻ ra 1 Lớp Con. Nhưng thế giới phần mềm rộng lớn hơn thế rất nhiều.

C++ là một trong số ít những ngôn ngữ lập trình hỗ trợ TẤT CẢ các kiểu tổ chức Kế thừa. Hãy cùng điểm danh 5 mô hình gia phả mà bạn sẽ gặp khi thiết kế kiến trúc hệ thống nhé!

1. Kế thừa đơn (Single Inheritance)

Đây là kiểu "Gia đình hạt nhân", cơ bản và an toàn nhất.

Định nghĩa: Một Lớp Con kế thừa từ DUY NHẤT một Lớp Cha.
Ví dụ: Chúng ta đã quá quen thuộc với mô hình này: Class NhanVien (Cha) $\rightarrow$ Class DevBackend (Con).
Độ phổ biến: 90% các dự án thực tế dùng kiểu này để đảm bảo mã nguồn dễ đọc, dễ bảo trì.

2. Kế thừa đa cấp (Multilevel Inheritance)

Đây là kiểu "Gia phả nhiều đời" (Ông nội $\rightarrow$ Cha $\rightarrow$ Con $\rightarrow$ Cháu).

Định nghĩa: Một Class được kế thừa từ một Class khác, và bản thân nó lại tiếp tục làm Cha để cho một Class thứ 3 kế thừa. Tài sản sẽ được truyền "chảy tràn" từ trên cùng xuống dưới cùng.
Ví dụ thực chiến Backend:

Tầng 1 (Ông): Class BaseModel chứa các trường id, created_at, updated_at.
Tầng 2 (Cha): Class User kế thừa BaseModel, có thêm email, password.
Tầng 3 (Con): Class Admin kế thừa User, có thêm hàm xoaTaiKhoan(). Lúc này, một Object Admin đúc ra sẽ nghiễm nhiên có đủ cả id, email và chức năng xóa tài khoản.

3. Kế thừa thứ bậc (Hierarchical Inheritance)

Đây là kiểu "Cha đông con".

Định nghĩa: MỘT Lớp Cha đẻ ra NHIỀU Lớp Con khác nhau. Các Lớp Con này hoàn toàn độc lập với nhau, không đụng chạm gì tài sản của nhau, chỉ chung một nguồn cội.
Ví dụ: Từ Class NhanVien (Cha), công ty tuyển thêm người và bạn tạo ra 3 Class con song song: DevBackend, Tester, HR. Cả 3 đều xài chung hàm chamCong() của NhanVien.

4. Đa kế thừa (Multiple Inheritance)

Đây là sức mạnh làm nên sự khác biệt của C++, nhưng cũng là một "lời nguyền".

Định nghĩa: MỘT Lớp Con nhận tài sản từ NHIỀU Lớp Cha cùng một lúc. (C# hay Java cấm tiệt trò này ở cấp độ Class).
Ví dụ hệ thống AFC (Soát vé tự động): Bạn có Class MayIn (chuyên in biên lai) và Class DauDocThe (chuyên đọc mã RFID). Bây giờ bạn cần chế tạo một cái Máy bán vé (Ticket Vending Machine - TVM). Bạn sẽ cho class TVM : public MayIn, public DauDocThe. Lập tức, TVM vừa biết in vé, vừa biết đọc thẻ khách hàng. Rất mạnh mẽ!
Lưu ý: Như đã cảnh báo ở [Bài 39], mô hình này cực kỳ dễ gây ra lỗi Kim Cương (Diamond Problem) nếu các Lớp Cha có chứa những hàm trùng tên nhau.

5. Kế thừa lai (Hybrid Inheritance)

Kiểu này là sự pha trộn hỗn mang của 4 kiểu trên.

Định nghĩa: Kết hợp giữa Đa kế thừa và Kế thừa thứ bậc/đa cấp.
Nhận xét: Trong môi trường doanh nghiệp, nếu bạn vẽ sơ đồ Class (UML) mà thấy nó ra hình dáng của Kế thừa lai chằng chịt, Tech Lead sẽ yêu cầu bạn đập đi thiết kế lại ngay lập tức vì không ai có thể bảo trì nổi hệ thống này.

Tạm kết & Gợi mở

Anh em đã có cái nhìn tổng quan về cách các Object nối kết gia phả với nhau. Dù cấu trúc có phức tạp đến đâu (đa cấp hay đa kế thừa), thì bản chất cốt lõi nhất của việc truyền dữ liệu vẫn phụ thuộc vào cái màng lọc truy xuất mà chúng ta đặt ở giữa.

Ở [Bài 40], chúng ta đã biết màng lọc public, protected, private có khả năng hạ cấp quyền truy cập. Nhưng để nói về "Tiêu chuẩn vàng" trong thiết kế hướng đối tượng, 99.99% các kỹ sư phần mềm trên thế giới đều thống nhất sử dụng Kế thừa public.

Tại sao public lại được ưu ái tôn làm chuẩn mực? Nó thể hiện triết lý gì của nguyên tắc IS-A (Là-Một)? Hẹn gặp lại anh em ở Bài 42: Kiểu kế thừa public - Tiêu chuẩn vàng của hệ thống OOP! Nhớ Upvote để mình có động lực gõ phím nhé!