2.1 Các khái niệm cơ bản của OOP
Nền tảng của lập trình hướng đối tượng là paradigm OOP. Đó là khi mọi thực thể trong chương trình đều được xem như đối tượng. Đối tượng là dữ liệu + phương thức/hàm thực hiện một cái gì đó trên dữ liệu đó.
Có thể nói rằng đối tượng có trạng thái và hành vi. Trạng thái của đối tượng được đảm bảo bởi dữ liệu của nó, được lưu trữ trong các biến bên trong. Hành vi của đối tượng là tập hợp toàn bộ các hành động mà các phương thức của nó thực hiện.
Có hàng ngàn đối tượng trong một chương trình trung bình, và hàng triệu trong một chương trình lớn. Để giảm bớt sự hỗn loạn, người ta quyết định tổ chức các đối tượng thành các lớp, và các lớp đối tượng thành một số loại hệ thống phân cấp.
Mỗi đối tượng có một lớp, thông qua đó nó được hình thành. Từ một phía, lớp là một mẫu đối tượng, từ phía khác, nó là một đối tượng độc lập với đặc điểm riêng của nó (được đề cập dưới đây).
Để hiểu rõ hơn về khái niệm lớp, hãy tìm hiểu các định nghĩa sau:
Lớp — là một mẫu hoặc sơ đồ để tạo ra các đối tượng, xác định thuộc tính và phương thức đặc trưng cho tất cả các đối tượng thuộc loại này. Các lớp cho phép tổ chức dữ liệu và hàm làm việc với dữ liệu này thành một tổng thể.
Đối tượng — là một thể hiện của lớp. Mỗi đối tượng có trạng thái (được xác định bởi các thuộc tính) và hành vi (được xác định bởi các phương thức).
Đóng gói — là việc che giấu việc thực hiện nội bộ của lớp và cung cấp giao diện để tương tác với các đối tượng của lớp này. Điều này giúp bảo vệ dữ liệu và quản lý truy cập vào chúng.
Kế thừa — cho phép một lớp (con) kế thừa thuộc tính và phương thức của lớp khác (cha). Điều này giúp tái sử dụng mã và đơn giản hóa việc bảo trì nó.
Đa hình — cho phép sử dụng một giao diện chung để làm việc với các đối tượng của các lớp khác nhau. Điều này đạt được thông qua việc ghi đè phương thức trong các lớp con, mà được thừa hưởng từ lớp cha.
Trừu tượng hóa — là việc tìm ra các đặc điểm chung của đối tượng và tạo ra các lớp đại diện cho các đặc điểm chung này. Điều này giúp đơn giản hóa hệ thống phức tạp và cải thiện sự rõ ràng của chúng.
Nếu bạn hiểu ít nhất một nửa những khái niệm trên, tuyệt vời. Chúng ta sẽ phân tích chi tiết từng điểm trong phần tiếp theo.
2.2 Trừu tượng hóa
Một ví dụ điển hình về trừu tượng hóa trong đời sống thực là mô tả các vị trí công việc trong công ty hoặc tổ chức. Tên vị trí là một thứ, còn trách nhiệm của từng vị trí cụ thể là một thứ khác.
Hãy tưởng tượng bạn đang thiết kế cấu trúc của công ty tương lai của mình. Bạn có thể phân chia trách nhiệm của thư ký: "phân chia" chúng cho một số vị trí khác. Bạn có thể chia vị trí giám đốc điều hành thành một số vị trí độc lập: giám đốc tài chính, giám đốc kỹ thuật, giám đốc marketing, giám đốc nhân sự. Hoặc, chẳng hạn, gộp vị trí quản lý văn phòng và tuyển dụng thành một vị trí.
Từ góc độ lập trình, trừu tượng hóa là, hãy nói như vậy, cách phân chia chương trình thành đối tượng đúng cách. Thông thường, bất kỳ chương trình lớn nào cũng có thể được đại diện bằng các đối tượng tương tác theo hàng chục cách. Trừu tượng hóa cho phép bạn chọn các đặc điểm chính và bỏ qua các đặc điểm phụ.
Trừu tượng hóa giống như chiến lược trong quân sự. Chiến lược tồi - và không có chiến thuật tài trí nào có thể cứu vãn tình hình.
2.3 Đóng gói
Mục tiêu của đóng gói là cải thiện chất lượng tương tác của các thứ bằng cách đơn giản hóa chúng.
Và cách tốt nhất để đơn giản hóa điều gì đó là giấu đi mọi thứ phức tạp khỏi con mắt của những người khác. Ví dụ, nếu bạn được ngồi trong buồng lái Boeing, bạn sẽ không nhanh chóng tìm ra cách điều khiển nó:
Mặt khác, đối với hành khách trên máy bay, mọi thứ trông đơn giản hơn: mua vé, ngồi vào máy bay, cất cánh và hạ cánh. Bạn có thể dễ dàng đi từ lục địa này sang lục địa khác, chỉ cần có kỹ năng 'mua vé' và 'ngồi trên máy bay'. Mọi sự phức tạp như chuẩn bị máy bay để bay, cất cánh, hạ cánh và các tình huống khẩn cấp ẩn giấu khỏi chúng ta. Chưa kể đến điều hướng vệ tinh, tự động hóa và các trung tâm điều phối ở sân bay. Và điều này giúp cuộc sống chúng ta đơn giản.
Từ góc độ lập trình, đóng gói là "giấu việc thực thi". Tôi thích định nghĩa này. Lớp của chúng ta có thể chứa hàng trăm phương thức và thực hiện hành vi rất phức tạp trong các tình huống khác nhau. Nhưng chúng ta có thể giấu đi tất cả các phương thức của nó khỏi con mắt của người khác (bao quanh tên của chúng bằng "__" từ hai phía), và để tương tác với các lớp khác, chỉ để lại vài phương thức. Khi đó tất cả các lớp khác của chương trình của chúng ta sẽ chỉ thấy ba phương thức trong lớp này, và sẽ gọi chính chúng. Và tất cả sự phức tạp sẽ được giấu bên trong lớp, như buồng lái ẩn khỏi hành khách hạnh phúc.
2.4 Kế thừa
Kế thừa có hai mặt: mặt lập trình và mặt đời sống thực. Từ góc độ lập trình, kế thừa là mối quan hệ đặc biệt giữa hai lớp. Nhưng thú vị hơn nhiều là kế thừa trong đời sống thực là gì.
Nếu chúng ta cần tạo ra thứ gì đó trong đời sống thực, chúng ta có hai giải pháp:
- tạo ra thứ cần thiết từ đầu, tốn rất nhiều thời gian và công sức;
- tạo ra thứ cần thiết dựa trên những gì đã có sẵn.
Chiến lược tối ưu nhất là: chúng ta lấy giải pháp tốt có sẵn, cải thiện một chút, điều chỉnh theo nhu cầu của mình và sử dụng.
Nếu chúng ta theo dõi lịch sử xuất hiện của con người, thì dường như từ khi sinh ra cuộc sống trên trái đất đã trôi qua hàng tỷ năm. Và nếu tưởng tượng rằng con người xuất hiện từ con khỉ (dựa trên con khỉ), thì chỉ mất vài triệu năm. Tạo ra từ đầu - lâu hơn. Rất lâu hơn.
Trong lập trình cũng có khả năng tạo ra một lớp dựa trên lớp khác. Lớp mới trở thành hậu duệ (thừa kế) của lớp đã tồn tại. Điều này rất có lợi khi có một lớp chứa 80%-90% những gì chúng ta cần về dữ liệu và phương thức. Chúng ta chỉ cần tuyên bố lớp phù hợp là cha của lớp mới của chúng ta, và khi đó lớp mới sẽ tự động có tất cả dữ liệu và phương thức của lớp cha. Thật tiện lợi, phải không?
2.5 Đa hình
Đa hình — là khái niệm trong lập trình. Nó mô tả tình huống khi một giao diện che giấu các thực thi khác nhau. Nếu cố gắng tìm kiếm các tương tự của nó trong đời sống thực, một trong số đó sẽ là quá trình điều khiển xe.
Nếu một người có thể điều khiển xe tải, anh ta có thể ngồi sau vô-lăng của xe cứu thương và xe thể thao. Người điều khiển được xe bất kể xe đó là gì, bởi vì tất cả chúng đều có giao diện điều khiển giống nhau: vô-lăng, bàn đạp và cần hộp số. Cấu trúc bên trong của xe khác nhau, nhưng tất cả chúng đều có cùng giao diện điều khiển.
Nếu trở lại với lập trình, đa hình cho phép xử lý một cách đồng nhất các đối tượng của các lớp khác nhau (thường có tổ tiên chung) — một điều không thể đánh giá được hết giá trị. Giá trị của nó càng cao khi chương trình càng lớn.
OOP — là các nguyên tắc. Các quy luật nội bộ. Mỗi quy luật hạn chế chúng ta ở điểm nào đó, nhưng đổi lại mang lại lợi thế lớn khi chương trình phát triển đến kích thước lớn. Bốn nguyên tắc của OOP giống như bốn chân của một chiếc ghế. Loại bỏ một trong số đó, và toàn bộ hệ thống trở nên không ổn định.
GO TO FULL VERSION