Cách giải thích khái niệm lập trình hướng đối tượng cho trẻ 6 tuổi

Bạn có nhận thấy những câu hỏi sáo rỗng giống nhau luôn được hỏi trong các cuộc phỏng vấn xin việc - lặp đi lặp lại không?

Tôi chắc rằng bạn biết tôi muốn nói gì.

Ví dụ:

Nơi nào bạn nhìn thấy mình trong năm năm?

hoặc thậm chí tệ hơn:

Bạn coi điểm yếu nhất của mình là gì?

Ugh… cho tôi nghỉ ngơi. Tôi coi việc trả lời câu hỏi này là một điểm yếu lớn! Dù sao, không phải quan điểm của tôi.

Những câu hỏi như thế này có thể là tầm thường, nhưng chúng rất quan trọng vì chúng cung cấp manh mối về bạn. Trạng thái tâm trí hiện tại của bạn, thái độ của bạn, quan điểm của bạn.

Khi trả lời, bạn nên cẩn thận, vì bạn có thể tiết lộ điều gì đó mà sau này bạn sẽ hối hận.

Hôm nay tôi muốn nói về một dạng câu hỏi tương tự trong thế giới lập trình:

Các nguyên tắc chính của Lập trình Hướng Đối tượng là gì?

Tôi đã ở trên cả hai mặt của câu hỏi này. Đó là một trong những chủ đề được hỏi thường xuyên đến mức bạn không thể cho phép mình không biết.

Các nhà phát triển sơ cấp và sơ cấp thường phải trả lời nó. Bởi vì đó là một cách dễ dàng để người phỏng vấn nói ba điều:

  1. Ứng viên đã chuẩn bị cho cuộc phỏng vấn này chưa?

    Thưởng điểm nếu bạn nghe câu trả lời ngay lập tức - nó cho thấy một cách tiếp cận nghiêm túc.

  2. Ứng viên đã qua giai đoạn hướng dẫn chưa?

    Việc hiểu các nguyên tắc của Lập trình hướng đối tượng (OOP) cho thấy bạn đã vượt ra ngoài sao chép và dán từ các hướng dẫn - bạn đã nhìn thấy mọi thứ từ một góc nhìn cao hơn.

  3. Sự hiểu biết của ứng viên là sâu hay nông?

    Mức độ năng lực của câu hỏi này thường tương đương với mức độ năng lực của hầu hết các môn học khác . Hãy tin tôi.

Bốn nguyên tắc của lập trình hướng đối tượng là đóng gói , trừu tượng hóa , kế thừa ,đa hình .

Những từ này nghe có vẻ đáng sợ đối với một nhà phát triển cơ sở. Và những lời giải thích phức tạp, dài dòng quá mức trong Wikipedia đôi khi làm tăng gấp đôi sự nhầm lẫn.

Đó là lý do tại sao tôi muốn giải thích đơn giản, ngắn gọn và rõ ràng cho từng khái niệm này. Nghe có vẻ giống như một điều gì đó bạn giải thích cho một đứa trẻ, nhưng tôi thực sự rất thích nghe những câu trả lời này khi tôi thực hiện một cuộc phỏng vấn.

Đóng gói

Giả sử chúng tôi có một chương trình. Nó có một vài đối tượng khác nhau về mặt logic giao tiếp với nhau - theo các quy tắc được xác định trong chương trình.

Việc đóng gói đạt được khi mỗi đối tượng giữ trạng thái riêng tư , bên trong một lớp. Các đối tượng khác không có quyền truy cập trực tiếp vào trạng thái này. Thay vào đó, họ chỉ có thể gọi một danh sách các hàm công khai - được gọi là các phương thức.

Vì vậy, đối tượng quản lý trạng thái của chính nó thông qua các phương thức - và không lớp nào khác có thể chạm vào nó trừ khi được phép rõ ràng. Nếu bạn muốn giao tiếp với đối tượng, bạn nên sử dụng các phương pháp được cung cấp. Nhưng (theo mặc định), bạn không thể thay đổi trạng thái.

Giả sử chúng tôi đang xây dựng một trò chơi Sims nhỏ. Có người và có một con mèo. Họ giao tiếp với nhau. Chúng tôi muốn áp dụng tính năng đóng gói, vì vậy chúng tôi đóng gói tất cả logic "mèo" vào mộtCatlớp học. Nó có thể trông như thế này:

Ở đây "trạng thái" của con mèo là các biến riêng tưmood , hungryenergy. Nó cũng có một phương pháp riêng meow(). Nó có thể gọi nó bất cứ khi nào nó muốn, các lớp khác không thể nói với con mèo khi nào thì meo meo.

Những gì họ có thể làm được xác định trong các phương thức công khaisleep() , play()feed(). Mỗi người trong số họ sửa đổi trạng thái bên trong bằng cách nào đó và có thể gọi meow(). Như vậy, ràng buộc giữa nhà nước tư nhân và phương thức công được thực hiện.

Đây là sự đóng gói.

Trừu tượng

Tính trừu tượng có thể được coi là một phần mở rộng tự nhiên của tính đóng gói.

Trong thiết kế hướng đối tượng, các chương trình thường cực kỳ lớn. Và các đối tượng riêng biệt giao tiếp với nhau rất nhiều. Vì vậy, việc duy trì một cơ sở mã lớn như thế này trong nhiều năm - với những thay đổi trong quá trình thực hiện - là rất khó.

Trừu tượng hóa là một khái niệm nhằm giảm bớt vấn đề này.

Áp dụng tính trừu tượng có nghĩa là mỗi đối tượng chỉ nên hiển thị một cơ chế cấp cao để sử dụng nó.

Cơ chế này nên ẩn chi tiết triển khai nội bộ. Nó chỉ nên tiết lộ các hoạt động liên quan đến các đối tượng khác.

Hãy suy nghĩ - một máy pha cà phê. Nó hoạt động rất nhiều thứ và tạo ra những tiếng động kỳ quặc dưới mui xe. Nhưng tất cả những gì bạn phải làm là cho cà phê vào và nhấn một nút.

Tốt hơn là cơ chế này phải dễ sử dụng và hiếm khi thay đổi theo thời gian. Hãy coi nó như một tập hợp nhỏ các phương thức chung mà bất kỳ lớp nào khác có thể gọi mà không cần “biết” cách chúng hoạt động.

Một ví dụ thực tế khác về sự trừu tượng?

Hãy nghĩ về cách bạn sử dụng điện thoại của mình:

Bạn tương tác với điện thoại của mình chỉ bằng một vài nút. Chuyện gì đang xảy ra vậy? Bạn không cần phải biết - chi tiết triển khai được ẩn. Bạn chỉ cần biết một vài thao tác ngắn.

Các thay đổi triển khai - ví dụ, một bản cập nhật phần mềm - hiếm khi ảnh hưởng đến phần trừu tượng mà bạn sử dụng.

Di sản

OK, chúng tôi đã thấy cách đóng gói và trừu tượng có thể giúp chúng tôi phát triển và duy trì một cơ sở mã lớn.

Nhưng bạn có biết một vấn đề phổ biến khác trong thiết kế OOP là gì không?

Các đối tượng thường rất giống nhau. Họ chia sẻ logic chung. Nhưng chúng không hoàn toàn giống nhau. Hự…

Vậy làm thế nào để chúng ta sử dụng lại logic chung và trích xuất logic duy nhất thành một lớp riêng biệt? Một cách để đạt được điều này là kế thừa.

Nó có nghĩa là bạn tạo một lớp (con) bằng cách dẫn xuất từ ​​một lớp (cha) khác. Bằng cách này, chúng tôi tạo thành một hệ thống phân cấp.

Lớp con sử dụng lại tất cả các trường và phương thức của lớp cha (phần chung) và có thể triển khai riêng (phần duy nhất).

Ví dụ:

Nếu chương trình của chúng tôi cần quản lý giáo viên công lập và tư nhân, cũng như những loại người khác như sinh viên, chúng tôi có thể thực hiện phân cấp lớp học này.

Bằng cách này, mỗi lớp chỉ thêm những gì cần thiết cho nó trong khi sử dụng lại logic chung với các lớp cha.

Tính đa hình

Chúng ta đang tìm từ phức tạp nhất! Đa hình có nghĩa là "nhiều hình dạng" trong tiếng Hy Lạp.

Vậy là chúng ta đã biết sức mạnh của sự kế thừa và vui vẻ sử dụng nó. Nhưng có vấn đề này.

Giả sử chúng ta có một lớp cha và một vài lớp con kế thừa từ nó. Đôi khi chúng ta muốn sử dụng một tập hợp - ví dụ như một danh sách - chứa hỗn hợp của tất cả các lớp này. Hoặc chúng tôi có một phương thức được triển khai cho lớp cha - nhưng chúng tôi cũng muốn sử dụng nó cho lớp con.

Điều này có thể được giải quyết bằng cách sử dụng tính đa hình.

Nói một cách đơn giản, tính đa hình cung cấp cách sử dụng một lớp giống hệt như lớp cha của nó để không có sự nhầm lẫn với các kiểu trộn.Nhưng mỗi lớp con giữ các phương thức riêng của nó như chúng vốn có.

Điều này thường xảy ra bằng cách xác định một giao diện (cha) được sử dụng lại. Nó phác thảo một loạt các phương pháp phổ biến. Sau đó, mỗi lớp con thực hiện phiên bản riêng của các phương thức này.

Bất cứ khi nào một tập hợp (chẳng hạn như một danh sách) hoặc một phương thức yêu cầu một thể hiện của phương thức chính (trong đó các phương thức chung được nêu ra), ngôn ngữ sẽ quan tâm đến việc đánh giá việc triển khai đúng phương pháp chung - bất kể phương thức con nào được chuyển qua.

Hãy xem bản phác thảo của việc triển khai các hình hình học. Họ sử dụng lại một giao diện chung để tính toán diện tích bề mặt và chu vi:

Có ba nhân vật kế thừa phụ huynh Figure Interfacecho phép bạn tạo một danh sách các hỗn hợp triangles, circlesrectangles. Và đối xử với chúng như cùng một loại đối tượng.

Sau đó, nếu danh sách này cố gắng tính toán bề mặt cho một phần tử, thì phương pháp chính xác sẽ được tìm thấy và thực thi. Nếu phần tử là một tam giác,CalculateSurface()được gọi là. Nếu đó là một vòng kết nối - thì vòng tròn củaCalculateSurface()được gọi là. Và như thế.

Nếu bạn có một hàm hoạt động với một hình bằng cách sử dụng tham số của nó, bạn không phải xác định nó ba lần - một lần cho hình tam giác, hình tròn và hình chữ nhật.

Bạn có thể xác định nó một lần và chấp nhận một Figurenhư một lập luận. Cho dù bạn vượt qua hình tam giác, hình tròn hay hình chữ nhật - miễn là chúng triển khai CalculateParamter(), loại của chúng không quan trọng.

Tôi hy vọng điều này đã giúp. Bạn có thể trực tiếp sử dụng những lời giải thích chính xác này tại các cuộc phỏng vấn việc làm.

Nếu bạn thấy điều gì đó vẫn còn khó hiểu - đừng ngần ngại hỏi trong phần bình luận bên dưới.

Cái gì tiếp theo?

Chuẩn bị để trả lời một trong những câu hỏi phỏng vấn kinh điển mọi thời đại là điều tuyệt vời - nhưng đôi khi bạn không bao giờ được gọi đi phỏng vấn.

Tiếp theo, tôi sẽ tập trung vào những gì nhà tuyển dụng muốn thấy ở một lập trình viên cấp dưới và cách để nổi bật giữa đám đông khi tìm việc.

Giữ nguyên.