Làm thế nào để giải thích các khái niệm OOP cho một người không có kỹ thuật?

Tôi thường cố gắng tránh nói với mọi người Tôi là lập trình viên vì hầu hết thời gian tôi đều giải thích cho họ điều đó thực sự có nghĩa là gì. Khi tôi nói với họ Tôi đang lập trình bằng Java, họ thường hỏi những câu hỏi chung về ngôn ngữ và nó khác với x và y như thế nào. Tôi cũng không giỏi trong việc giải thích mọi thứ vì 1) Tôi không có nhiều kinh nghiệm trong lĩnh vực này và 2) Tôi thực sự ghét việc giải thích mọi thứ cho những người không có kỹ thuật.

Họ nói rằng bạn thực sự hiểu mọi thứ một khi bạn giải thích chúng cho người khác, trong trường hợp này bạn sẽ giải thích thuật ngữ và khái niệm OOP cho một người không có kỹ thuật như thế nào?

Tôi thường thử và mô tả Lập trình hướng đối tượng bằng cách sử dụng các ví dụ trong thế giới thực.

Ví dụ, tôi có thể nói rằng một lớp được gọi là Vehiclemô tả những điều tối thiểu mà một chiếc xe là. Tôi sẽ yêu cầu người đó cho tôi biết xe của họ là gì. Đôi khi họ nói những câu như "Chà, như xe hơi hay xe tải", và tôi sẽ gật đầu và đồng ý với họ. Sau đó, tôi sẽ hỏi sự khác biệt giữa xe hơi và xe tải. Đôi khi họ đề cập đến kích thước, đôi khi mục đích và những thứ khác.

Sau đó, tôi sẽ yêu cầu họ quên đi một chiếc xe hơi, hoặc một chiếc xe tải và chỉ yêu cầu họ tiếp tục mô tả một chiếc xe:

"Ồ, nó di chuyển"

"Nó có một nhà điều hành, hoặc một trình điều khiển"

Vân vân...

Chẳng mấy chốc, chúng ta biết Xe là gì và tôi đã nói rằng trong OOP, chúng ta sẽ định nghĩa một phương tiện, và để tranh luận, nó có thể di chuyển và đưa cho nó một trình điều khiển. Sau đó tôi sẽ hỏi, ok, vậy xe hơi có gì?

"Cửa ra vào"

"Các cửa sổ"

Và rồi một chiếc xe tải ....

"Cửa" "cửa sổ" "Thêm bánh xe!"

Ngay sau đó, sau rất nhiều cuộc thảo luận, người khác thường đã xác định:

1) Cái gì tạo thành một chiếc xe

2) Cái gì tạo thành một chiếc xe hơi

3) Cái gì tạo thành một chiếc xe tải

4) Những gì tạo thành một chiếc máy bay.

Tất cả không có bất kỳ kỹ thuật. Chúng tôi đã chia các thuộc tính của từng trong các khu vực bên phải. Họ hiểu sự kế thừa ("Vâng, xe hơi là phương tiện, xe tải là phương tiện, nhưng xe hơi không phải là xe tải, đó là ĐƠN GIẢN, duh!").

Họ thậm chí hiểu đa hình, "Chắc chắn, về cơ bản họ cũng làm như vậy, nhưng điều đó có thể làm nó hơi khác một chút." Chúng ta có thể nói về hành vi và nơi mà nên sống trong cây đồ vật của chúng ta.

Tùy thuộc vào trình độ học vấn và nền tảng của họ, một số người nhận được nó nhanh hơn những người khác. Nhưng khi tôi so sánh OOP với các đối tượng trong đời thực, hầu hết mọi người luôn hiểu nó. Trong thực tế, tôi đã tìm thấy trong các cuộc trò chuyện với những người phi kỹ thuật những điều tôi chưa bao giờ nghĩ tới. Các phương tiện không phải có người lái, ví dụ (máy bay không người lái), nhưng liệu một lập trình viên có nghĩ người điều khiển phương tiện là tài sản của nó không? Tôi không nói rằng đúng hay sai khi có một nhà điều hành được đề cập, nhưng nó khiến chúng ta phải suy nghĩ về những gì chúng ta đang mô hình hóa và những gì chúng ta đang cố gắng đạt được khi chúng ta phát triển phần mềm.

Bây giờ, chuyên môn mẫu một phần, mặt khác .... :)

Đối tượng là danh từ, phương thức là động từ.

Đây là một số phiên bản của câu trả lời đóng hộp của tôi mà tôi dành cho người cực kỳ kỹ thuật:

Lập trình là một nỗ lực để tạo ra một đại diện của thực tế trên máy tính. Có rất nhiều công cụ và thiết bị tồn tại đã làm điều này - hãy nghĩ về cách bảng tính giúp chúng tôi dễ dàng trình bày kế toán hoặc thống kê hơn hoặc cách trình bày Powerpoint cho phép chúng tôi lưu trữ và hiển thị bản trình bày của mình.

Đôi khi chúng ta cần xây dựng các biểu diễn tùy chỉnh của thực tế thành các ứng dụng mới hoặc hiện có phản ánh các quy trình kinh doanh của chúng ta. Có rất nhiều cách để lập trình, và một trong những cách phổ biến nhất để lập trình là lập trình hướng đối tượng, trong đó mã chúng tôi xây dựng được thiết kế đặc biệt để sao chép các khái niệm của thực tế. "Những thứ" trong thực tế có thuộc tính và hành vi. Chẳng hạn, một con người thường có tay và chân, màu tóc, sắc tộc và thường có thể nói và đi bộ.

Nói và Đi bộ có thể có nhiều loại khác nhau, chẳng hạn như ngôn ngữ mà người ta đang nói, hoặc tốc độ hoặc cách thức mà người đó đang đi.

Con người thường có tương tác với các loại "vật" khác, cho dù chúng là động vật, người khác, sinh vật sống khác hay vật vô tri. Có những chủ đề trong thực tế thường cần một cách để được trình bày, chẳng hạn như tương tác giữa "sự vật", phân loại sự vật, v.v. Hãy xem xét các quy trình kinh doanh diễn ra trong tổ chức của chúng tôi. Tồn tại "logic kinh doanh" rất phức tạp cần được thể hiện trong phần mềm mà tổ chức của chúng tôi sử dụng.

Lập trình hướng đối tượng cung cấp một phương tiện để thể hiện chính xác các "khái niệm thế giới thực" và "logic kinh doanh" này.

-> Câu nói này thường đủ để ngăn chặn sự tò mò của họ (hoặc có thể khiến họ rơi nước mắt), nhưng nếu họ có nhiều câu hỏi hơn, câu nói trên (tôi tin) sẽ đặt nền tảng tốt cho cuộc trò chuyện có thể đi đến đâu. Tôi thực sự không nghĩ rằng người phi kỹ thuật quan tâm quá nhiều đến các thuật ngữ kỹ thuật như "Trừu tượng hóa", "Thành phần", "Đa hình", v.v., nhưng nếu họ là, ngôn ngữ tôi sử dụng trong tuyên bố đóng hộp cho phép tôi để lấy ví dụ dựa trên nó.

Tôi luôn học OOP như thế này:

Bạn có một chiếc đồng hồ, và nó cho biết thời gian - tốt, trong lập trình, bạn đặt tất cả mã và những thứ bạn phải làm cùng nhau (nghe có vẻ khá rõ ràng, nhưng mọi người đã không sử dụng cách này trở lại trong những ngày đầu). Dù sao, đó được gọi là đóng gói .

Bây giờ bạn đã có một thứ đồng hồ, bạn có thể muốn một chiếc đồng hồ báo thức - tốt, khi bạn đã có tất cả mọi thứ cùng nhau, bạn có thể thêm mọi thứ vào đó để làm cho nó hoạt động nhiều hơn - như đặt báo thức và làm cho nó reo. Đây được gọi là thừa kế .

Ngoài ra, bạn nhìn vào đồng hồ tôi có trên cổ tay, nhưng bạn có thể thấy những chiếc đồng hồ khác trông giống như đồng hồ của ông nội hoặc đồng hồ kỹ thuật số. Nó xuất hiện khác nhau, nhưng nó vẫn là một chiếc đồng hồ - tốt, đó gọi là đa hình .

Và ở đó bạn có 3 góc của lập trình hướng đối tượng. Tất cả phần còn lại chỉ là mã hóa.

Tôi chỉ bảo họ đăng ký một khóa học trong OOP nếu họ thực sự muốn hiểu nó.

Ý tôi là, tất cả những sự tương tự như Car.startEngine (); là, hãy đối mặt với nó - rap thuần túy. Khi tôi lần đầu tiên tham gia OOP nhiều năm trước, tôi đã tìm thấy những điều này chỉ để trừu tượng hóa tên miền hơn nữa.

Thay vì chỉ giải thích rằng OOP là về việc quản lý sự phức tạp của các ngôn ngữ thủ tục, gần 80% các tác giả sách lập trình cho rằng các lập trình viên là những kẻ ngốc không biết nói những điều đơn giản (xem điều trớ trêu ở đây?).

Vâng, việc giải thích Danh sách và Vectơ là hoàn toàn bình thường, bởi vì đó là những gì chúng tôi chủ yếu làm việc với, không phải Car.Engine và PoliceMan.Arrest (trừ khi bạn là một nhà phát triển trò chơi, nhưng một lần nữa, bạn vẫn phải có phần của bạn về trước đây).

Quay trở lại chủ đề, tôi sẽ chỉ nói với họ, tôi tạo ra những vật thể không thể tồn tại hoàn toàn trong tâm trí lập trình viên, với mục đích xử lý biên chế / chơi trò chơi / điều hướng tàu con thoi, v.v.

Nếu họ vẫn còn thắc mắc, hãy ngừng thảo luận, vì nó không đáng. Hầu hết mọi người thất bại trong việc tưởng tượng các khái niệm trừu tượng và cần các ví dụ cho mọi thứ (có nghĩa là đơn giản hóa / chuyên môn hóa hơn về chủ đề thực sự, thực sự).

Tôi đã nói về một cuộc trò chuyện với vợ tôi về điều này, trong câu trả lời này tại đây: /software/45464/how-to-convince-non-programmer-his-notions-about- máy tính bị lỗi / 45467 # 45467

EDIT: Câu hỏi tôi đã trả lời ở đó đã được kiểm duyệt, vì vậy tôi sẽ trả lời câu trả lời của tôi ở đây.

Ngồi trong một nhà hàng với vợ tôi, cô ấy hỏi tôi "Hướng đối tượng có nghĩa là gì?"

Tôi bắt đầu viết về việc tái sử dụng mã và đóng gói và đa hình, và đến một lúc nào đó tôi nhận ra đôi mắt của cô ấy đang bị trừng phạt.

Vì vậy, tôi lấy một gói Splenda ra khỏi container. Tôi nói, "Đây là một đối tượng. Thuộc tính của nó là gì?"

Cô nói, "Nó là hình chữ nhật, nó được làm bằng giấy, nó chứa splenda, nó màu xanh, nó được in trên đó."

Tôi nhặt một gói đường. "Nó có điểm gì chung với cái này?"

Cô nói, "Hình chữ nhật, tờ giấy, có in."

Tôi nói, "Thế còn cả hai đều chứa thứ gì đó ngọt ngào?"

Cô nói, "Chắc chắn."

Tôi nói, "Vì vậy, đây là cả hai trường hợp của cái mà chúng ta có thể gọi là gói chất làm ngọt trừu tượng. Một gói chất làm ngọt lý tưởng nguyên chất, nếu bạn thích."

Cô nói, "Chắc chắn."

Tôi nói, "Và mỗi cái đều có các thuộc tính được kế thừa từ gói trừu tượng, và sau đó các biến thể trên đó là đặc trưng cho loại sự vật của nó."

Cô ấy nói, "Phải rồi. Ôi

Tôi nói, "Bingo: Lập trình hướng đối tượng."

Bạn và tôi biết cô ấy chỉ hướng đến mẫu thiết kế Factory. Bất cứ điều gì. Nó minh họa sự kế thừa, đóng gói, nhận dạng lớp đối tượng ... Thứ tốt.

Câu hỏi này có vẻ như là một ứng cử viên cho việc đóng cửa, tuy nhiên ...

Giống như hầu hết mọi thứ, OOP thực sự rất đơn giản để giải thích ở cấp độ khái niệm. Lập trình viên mô hình các đối tượng; và:

• các đối tượng có trạng thái (trường / thành viên dữ liệu)
• các đối tượng có hành động (phương thức / hàm)
• các đối tượng xây dựng lẫn nhau (kế thừa)

Đây là hàng trăm chi tiết tốt hơn, chắc chắn. Nhưng nếu bạn chỉ cố gắng cung cấp cho ai đó tổng quan 10 giây, tôi nghĩ đó là một khởi đầu tốt. Có những khái niệm cụ thể hơn mà bạn gặp khó khăn để giải thích?

Ví dụ về Điện thoại di động:

Hãy tưởng tượng bạn là chủ sở hữu nhà máy, bạn muốn mô tả một chiếc điện thoại chung

• Bước 1: Liệt kê các thuộc tính chung của điện thoại này, ví dụ: chiều cao, cân nặng, màu sắc, v.v.
• Bước 2: Liệt kê các chức năng điện thoại chung này, ví dụ: thực hiện cuộc gọi, nhận cuộc gọi, gửi tin nhắn, v.v.

Bây giờ bạn có "bản thiết kế" chung chung, hãy tạo cho tôi các điện thoại sau:

Điện thoại 1:

• Chiều cao-> 102mm

• Cân nặng-> 85g

• Màu sắc-> Màu hồng

Điện thoại 2:

• Chiều cao-> 125mm

• Cân nặng-> 96g

• Màu sắc-> Đỏ

Tôi nghĩ cách tốt nhất để giải thích cho một loại phi kỹ thuật về OOP là liên hệ nó với họ.

Về cơ bản, OOD & OOP muốn bạn nghĩ về hệ thống bạn đang thiết kế và triển khai như một thế giới của những thứ tương tác.

Vì vậy, cho phép, để tranh luận (điều này không bao giờ diễn ra tốt đẹp trên internet), hãy nói rằng bạn đang giải thích cho một nhà sưu tập từ chối về OOD & P. Tên anh ta là Bob. Bạn đã từng đi học cùng anh ấy 15 năm trước, bạn tình cờ gặp anh ấy tại một quán bar và cả hai bạn đều thích thú với cuộc sống của nhau.

"Vì vậy, John, bạn nói bạn là một lập trình viên. Cháu trai tôi là tất cả những điều vô nghĩa. Tiếp tục về lập trình hướng đối tượng, hoặc một cái gì đó. Tất cả những gì về?" Lưu ý rằng Bob là người Anh từ cách anh ấy viết sai chính tả.

"Chà, Bob," bạn trả lời, co rúm lại theo định hướng. "Nó thực sự khá đơn giản. Bạn thu thập từ chối, phải không? Nói chung, bạn làm gì trong công việc của mình?"

"Chà, tôi đi theo chiếc xe tải quanh thị trấn nhặt rác và bỏ nó vào xe," Bob trả lời một cách thắc mắc.

và bạn sẽ cần lắng nghe điều đó. Đó là những hành vi của chúng ta. Đó là tất cả những gì bạn cần cho thiết kế. Lập trình hướng đối tượng về cơ bản là cách bạn thực hiện thiết kế. Nó khác với ngôn ngữ này sang ngôn ngữ khác. "

Bob đã ngủ thiếp đi trong bia của mình. Bạn bước đi.

Tôi thích ví dụ về xe hơi để giải thích sự kế thừa (tôi có xu hướng sử dụng động vật hơn là phương tiện nhưng đó là ý tưởng tương tự) nhưng để giải thích cách một chương trình hướng đối tượng hoạt động, tôi đề cập đến một sự tương tự tôi từng đọc trên trang web của Chris Crawford: chương trình này giống như một bộ máy quan liêu thực sự hiệu quả. Tất cả các đối tượng khác nhau trong chương trình giống như các phòng ban khác nhau trong một bộ máy quan liêu; mỗi bộ phận có nhiệm vụ được chỉ định riêng, họ có đầu vào được xác định rõ (nói chuyện với ai và điền vào mẫu nào) và các bộ phận khác thường không biết nhiều về những gì diễn ra bên trong. Nhân sự giống như một nhà máy trừu tượng, CNTT là một đơn vị, v.v.

Nhận thông báo lỗi vì bạn đã gõ sai trong chương trình máy tính giống hệt như điền vào biểu mẫu sai để gửi đến văn phòng.

OOP là một sự đơn giản hóa tổng thể nếu bất cứ điều gì - một sự trừu tượng - về quá trình suy nghĩ của con người và sự hiểu biết về thế giới để chiếu chức năng vào một "khoảng trống" kỹ thuật số để bắt chước các quy trình và phân loại kỹ thuật số quen thuộc. Về nhiều mặt, đó là về trạng thái ngôn ngữ nguyên thủy của chúng ta hơn là "suy nghĩ giống máy tính" hơn.

Nếu lập trình bắt chước thực tế hoặc con người nghĩ rằng nó sẽ hữu cơ hơn, hỗn loạn và hỗn loạn trong tự nhiên - thậm chí là bên. Thay vào đó, chúng tôi đơn giản hóa thực tế thành các bước bé, "logic 2 + 2", các thể loại thô sơ, các công cụ nhỏ có thể sử dụng lại và lý luận tiền sử.

Chúng tôi vẫn đang cố gắng tìm ra cách tải suy nghĩ và mong muốn của mình vào một giao thức và ngôn ngữ chung và tôi nghĩ rằng các nhà sử học sẽ bị mê hoặc bởi sự thô sơ tinh vi của nó một ngày nào đó - như bây giờ chúng ta thấy chữ tượng hình. Nó hoàn toàn không "thông minh" - nó chỉ đơn giản nêu bật cách chúng ta không thể dễ dàng giải thích cách chúng ta quyết định hoặc hiểu ngay cả những điều đơn giản nhất. Điện toán vẫn ở mức "tiến hóa của một con chó bởi vì nó không phải là một con mèo" của sự tiến hóa tư tưởng - đó là hàng ngàn năm đằng sau ngôn ngữ nói cơ bản.

Có hai loại pháp sư. Có anh chàng làm cho những điều cụ thể xảy ra với những từ ma thuật. Anh ta có một từ để triệu tập lửa. Anh ta có một từ để làm cho một con gà đông lạnh xuất hiện trong không khí mỏng. Và một từ khác để tạo ra một nồi lực (tôi thích lực lượng của tôi màu xanh lá cây, rực rỡ và mờ) đầy lòng tốt lành. Với việc áp dụng đúng lời nói của mình, anh ta có thể sản xuất một con gà rán.

Và sau đó là trình hướng dẫn OOP. Ai chỉ cần triệu tập một người biết cách đi đến cửa hàng tạp hóa, mua một con gà (hoặc nguyên liệu cho bất kỳ thực phẩm nào khác mà bạn muốn anh ấy chuẩn bị), nấu nó và phục vụ bữa tối cho bạn. Thuật sĩ OOP không cần phải nói với imp của mình cách làm. Anh ta chỉ cần cho anh ta biết những gì anh ta muốn trong trường hợp này là gà rán. Không chỉ vậy, thuật sĩ OOP có thể triệu tập các tay sai khác để nói với đầu bếp của mình phải làm gì.

Vì vậy, anh chàng bùa chú gây ấn tượng trong các bữa tiệc nhưng phù thủy OOP là người bạn muốn khi bạn bắt đầu một nhà hàng ma thuật với một loạt các nhân vật (như nói, một người phục vụ kỳ lân bực mình, và một người quản lý sàn troll) phải làm việc cùng nhau Nếu bạn cố gắng thực hiện từng bước của vấn đề giải quyết "nhà hàng", bạn có thể dễ dàng bị vướng vào các chi tiết và thực sự rất dễ mắc lỗi. Thuật sĩ OOP huấn luyện trước các tay sai của anh ta để sắp xếp các chi tiết cho anh ta để anh ta có thể tập trung giải quyết vấn đề lớn hơn bằng cách để người của anh ta tương tác.

Chưa kể việc sử dụng lại đầu bếp của bạn cho vấn đề căng tin ở trường học của bạn thì dễ dàng hơn, đó là tách tất cả rác mà bạn có thể hoặc không thể sử dụng lại khi bạn thực hiện từng bước một bằng cách gọi từ và các từ gọi các nhóm từ khác (sẽ có số lượng nhiều hơn khi bạn phải xử lý nhiều vấn đề hơn).

Công bằng mà nói, với ứng dụng rất, rất cẩn thận, thuật sĩ bùa chú có thể hoàn thành mọi việc nhanh như thuật sĩ OOP. Anh ta có thể phá vỡ mọi thứ theo cách đúng đắn để gọi đúng phép thuật không đòi hỏi nhiều công việc của anh ta hơn thuật sĩ OOP. Nhưng công việc khó hiểu hơn hoặc trùng lặp và khó hơn nhiều để sử dụng lại các phần lớn vì tất cả đều gắn liền với nhau cho một vấn đề phức tạp cụ thể.