Contents
Lập trình hướng đối tượng là gì?
Lập trình hướng đối tượng (tiếng Anh: object-oriented programming, viết tắt: oop) là mô hình lập trình dựa trên khái niệm “công nghệ đối tượng”, trong đó đối tượng chứa dữ liệu, trường, thường được gọi là thuộc tính; và mã nguồn, tổ chức thành các phương pháp. Các phương thức cho phép một đối tượng truy cập và sửa đổi các trường dữ liệu của các đối tượng khác mà đối tượng hiện tại tương tác (đối tượng hỗ trợ phương thức “this” hoặc “self”). Trong lập trình hướng đối tượng, một chương trình máy tính được thiết kế bằng cách tách phạm vi của các đối tượng tương tác với nhau. [1] [2] Các ngôn ngữ lập trình hướng đối tượng khá đa dạng, hầu hết là các ngôn ngữ dựa trên lớp, nghĩa là các đối tượng trong các ngôn ngữ này được coi là thể hiện của một lớp, được dùng để định nghĩa một kiểu dữ liệu. . (theo wiki)
Xem thêm: Tính trừu tượng trong oop
Bốn thuộc tính của oop
Lập trình hướng đối tượng là một phương pháp lập trình có bốn thuộc tính chính:
- trừu tượng hóa: Đây là khả năng chương trình bỏ qua hoặc phớt lờ một số khía cạnh nhất định của thông tin mà nó xử lý trực tiếp, ngụ ý khả năng tập trung vào các yếu tố cần thiết. Mỗi đối tượng hoạt động như một “con vật” có thể hoàn thành nhiệm vụ bên trong, báo cáo, thay đổi trạng thái của chính nó và giao tiếp với các đối tượng khác mà không cần biết đối tượng thực hiện các hoạt động như thế nào. Thuộc tính này thường được gọi là trừu tượng hóa dữ liệu.
-
Đóng gói và ẩn thông tin: Thuộc tính này không cho phép người dùng của đối tượng thay đổi trạng thái bên trong của đối tượng. Chỉ các phương thức bên trong của đối tượng được phép thay đổi trạng thái của nó. Cách thức mà môi trường bên ngoài được phép ảnh hưởng đến dữ liệu bên trong của đối tượng hoàn toàn phụ thuộc vào bộ mã hóa. Đây là thuộc tính đảm bảo tính toàn vẹn của đối tượng.
-
Tính đa hình: Được thể hiện bằng cách gửi tin nhắn. Gửi các tin nhắn này tương đương với việc gọi một chức năng nội bộ của đối tượng. Các phương thức được sử dụng để trả lời tin nhắn sẽ phản hồi khác nhau tùy thuộc vào đối tượng mà tin nhắn được gửi đến. Lập trình viên có thể định nghĩa một thuộc tính cho một loạt các đối tượng gần nhau (ví dụ theo tên phương thức), nhưng khi thực hiện trùng tên thì việc thực thi từng đối tượng sẽ tự động diễn ra theo đặc điểm của từng đối tượng mà không bị nhầm lẫn.
Ví dụ khi định nghĩa hai đối tượng “hinh_vuong” và “hinh_tron” thì có một phương thức chung là “chu_vi”. Khi phương thức này được gọi, nếu đối tượng là “hinh_vuong” thì công thức tính sẽ khác với khi đối tượng là “hinh_tron”.
- kế thừa: Thuộc tính này cho phép một đối tượng kế thừa một thuộc tính mà đối tượng khác đã có. Điều này cho phép các đối tượng chia sẻ hoặc mở rộng các thuộc tính hiện có mà không cần xác định lại chúng. Tuy nhiên, không phải tất cả các ngôn ngữ hướng đối tượng đều có chung tính chất này. (theo wiki)
Trừu tượng hóa và tư duy trong lập trình oop
Giáo viên kỹ thuật phần mềm cũ của tôi đã từng nói điều gì đó như thế này:
Khả năng yếu nhất của lập trình viên Việt Nam là tính trừu tượng.
Tôi không hoàn toàn đồng ý vào thời điểm đó, nhưng trớ trêu thay, tôi ngày càng mất đi nhiều lý lẽ thuyết phục hơn để chống lại nhận xét này.
Đang xem: Trường cao đẳng George Brown – George Brown college
Tôi đã làm việc ở nhiều công ty công nghệ, từ các tập đoàn lớn đến các công ty mới thành lập chỉ có một số người, từ gia công phần mềm đến các công ty làm về sản phẩm, erp hoặc dịch vụ tài chính.
Tôi đã bắt gặp mã như thế này ở mọi nơi: Một ngày nọ, chúng tôi được yêu cầu triển khai một tính năng cho phép chúng tôi gửi email cho khách hàng khi có biến động tài chính trong tài khoản cá nhân. . Ai đó đã ngay lập tức tạo một lớp email bằng phương thức sendemail() và triển khai chức năng này trong vòng 30 phút. Càng xa càng tốt.
public void sendemail(Chuỗi email, Nội dung chuỗi…)
Sau một thời gian, chúng tôi được yêu cầu tiếp tục triển khai thêm chức năng gửi SMS trong chuỗi hiện tại. Một số người đã đề xuất thêm phương thức sendms() vào lớp email hiện có (wtf, ném phương thức gửi SMS và đối tượng email?). Mọi người dường như nhận ra rằng đây là một ý tưởng tồi và họ quyết định tạo một lớp SMS mới với phương thức sendms().
Tham khảo: Điều kiện để được sang lao động tại Úc
public void sendms(chuỗi số điện thoại, chuỗi nội dung…)
Mọi thứ có vẻ ổn cho đến khi chúng tôi được yêu cầu triển khai thêm khả năng gửi thông báo đến hồ sơ của khách hàng. Một số người vẫn ngoan cố cho rằng nên tiếp tục tạo thêm các lớp gọi là thông báo, những người khác bắt đầu lờ mờ nhận ra rằng họ đã sai khi bắt đầu, nhưng phải tiếp tục một chuỗi khủng khiếp vì họ đã tạo ra quá nhiều phụ thuộc. không để phá vỡ cấu trúc của hệ thống (mà họ cho là có lý).
<3 bước thiết kế ban đầu.
Một sai lầm phổ biến trong thiết kế hệ thống là mọi người tin tưởng quá nhiều, rằng những gì họ biết và chắc chắn sẽ không thay đổi. nhưng không! Chúng ta không biết nhiều như chúng ta nghĩ. Tôi đã từng đọc một (vài) câu trích dẫn của một người nổi tiếng (ai đó không nhớ tên), như:
Sau một thời gian triển khai, chúng tôi nhận thấy những gì chúng tôi tạo ra hoàn toàn khác với những gì chúng tôi tưởng tượng ban đầu.
Nếu bạn không thể dự đoán điều gì sẽ thay đổi, hãy trừu tượng hóa nó càng nhiều càng tốt. Trừu tượng hóa luôn là một trong những yếu tố quan trọng nhất của oop, nhưng không nhiều người thực sự nhận ra điều đó. Nhưng ngay cả khi chúng ta hiểu điều này, như vậy đã đủ chưa? Tôi đã từng thấy một lập trình viên “có kinh nghiệm” triển khai lớp sender theo cách sau:
public void sendemail(Chuỗi email, Nội dung chuỗi…)
Tham khảo: Điều kiện để được sang lao động tại Úc
public void sendms(chuỗi số điện thoại, chuỗi nội dung…)
Rõ ràng, email, số điện thoại hoặc nội dung phải là thuộc tính của đối tượng, chỉ có thể tương tác với thông qua các phương thức get(), set() hoặc hàm tạo(). Vấn đề ngay lập tức phát sinh khi tôi muốn lưu trữ email và số điện thoại trong một số bảng tạm thời. Một số sẽ chỉ kết xuất mã được lưu trữ vào từng phương thức (f***), một số khác sẽ tạo một phương thức mới, ví dụ:
ghi nhật ký khoảng trống công khai (xâu chuỗi một số thứ…)
Nhưng rõ ràng phương pháp này tiềm ẩn rất nhiều nguy cơ xung đột dữ liệu không cần thiết. Chúng ta thường nói về oop, và thường vi phạm nghiêm trọng việc đóng gói các đối tượng.
Hãy nhìn xung quanh và bạn có thể bắt gặp những người sử dụng Mẫu chiến lược, cá nhân tôi thích Mẫu người quan sát hơn. Tư duy trong lập trình là một thứ rất dễ thay đổi, nhưng trớ trêu thay, thuyết phục một người thay đổi suy nghĩ lại khó hơn nhiều.
Tôi đã gặp nhiều lập trình viên ngay lập tức từ chối những ý tưởng mới, mặc dù họ không hiểu ý tưởng đó là gì. Thật không may, những lời biện hộ có vẻ rất thuyết phục, chẳng hạn như “Tôi nghĩ thiết kế này phù hợp với chức năng hiện có” hoặc “hệ thống hiện có được thiết kế theo cách này”. Chúng ta thường áp dụng tư duy cũ vào hệ thống mới và hy vọng vào sự thay đổi tích cực. Nhưng khi sự liên kết lỏng lẻo hay sự gắn kết cao vẫn là những khái niệm rất mơ hồ, thì việc thuyết phục sự thay đổi là vô cùng khó khăn.
Sự điên rồ là làm đi làm lại một việc và mong đợi những kết quả khác nhau. (Hãy nhớ tên lần này: albert einstein)
Biên dịch từ nguồn:
Lập trình hướng đối tượng
Xin lỗi
Tham khảo: Cách Làm Thơ Tán Gái Đổ 100% ❤️️50 Bài Thơ Cua Gái Chế Vui
Tính trừu tượng cũng thể hiện ở chỗ một đối tượng ban đầu có thể có một số đặc điểm chung cho nhiều đối tượng khác, chẳng hạn như phần mở rộng của nó, nhưng bản thân đối tượng ban đầu có thể không có các thước đo đó. Sự trừu tượng hóa này thường được định nghĩa trong một khái niệm được gọi là lớp trừu tượng hoặc lớp cơ sở trừu tượng.
