Làm thế nào người ta có thể dạy OO mà không tham khảo các đối tượng trong thế giới thực? [đóng cửa]

Tôi nhớ đã đọc ở đâu đó rằng các khái niệm ban đầu đằng sau OO là tìm một kiến ​​trúc tốt hơn để xử lý việc nhắn tin dữ liệu giữa nhiều hệ thống theo cách bảo vệ trạng thái của dữ liệu đó. Bây giờ có lẽ đó là một cách diễn đạt kém, nhưng nó khiến tôi tự hỏi liệu có cách nào dạy OO mà không có sự tương tự đối tượng (Xe đạp, Xe hơi, Người, v.v.) không, và điều đó thay vào đó tập trung vào các khía cạnh nhắn tin. Nếu bạn có bài viết, liên kết, sách, vv, điều đó sẽ hữu ích.

Khái niệm ban đầu về OO không liên quan gì đến OO ngày nay. (Xem Vậy điều gì * đã làm * Alan Kay thực sự có nghĩa là thuật ngữ "hướng đối tượng"? ). IS lập trình hướng đối tượng ngày nay về việc tạo ra các đối tượng như ẩn dụ của xe đạp và nhà cửa và con người, v.v. Tôi rất khuyên bạn nên gắn bó với những điều này bởi vì mục đích của các ẩn dụ là giúp mọi người hiểu bằng cách sử dụng một khái niệm mà họ đã hiểu. Giúp họ thấy mối tương quan sau đó giúp họ thấy sự khác biệt THÌ đi sâu vào những điều sâu sắc hơn về OO.

EDIT: OO ngày nay là về việc tạo các đối tượng hoàn toàn khép kín có các thuộc tính và khả năng được mô tả đầy đủ / một phần bằng các phương thức (hàm) và thuộc tính khác nhau (tham chiếu các biến và hằng AKA).

Bạn có thể nói về các khái niệm của khớp nối và sự gắn kết. Các đối tượng nên bao gồm các thuộc tính và phương thức có độ gắn kết cao và khả năng ghép cao. Họ nên ánh xạ tới các hoạt động chi tiết nhất và các thuộc tính cần thiết để hệ thống hoạt động. Họ cũng nên thỏa mãn mong muốn giữ mã càng nhỏ và đơn giản càng tốt, tức là mã hóa với sự bảo trì và mở rộng trong tâm trí.

Điều này cũng ngăn chặn "sự bùng nổ đối tượng", khái quát hóa quá mức và lựa chọn ẩn dụ sai, tất cả đều là những lỗi phổ biến.

Tôi sẽ không tập trung vào các đối tượng trong thế giới thực và tôi cũng sẽ không tập trung vào tin nhắn. Thay vào đó, một ví dụ tôi đã sử dụng là trong đồ họa, nơi bạn muốn có các đối tượng "biết cách tự vẽ".

Ví dụ: nếu bạn đang làm việc trong C, không tích hợp OO, bạn có thể thấy thuận tiện khi lưu trữ các con trỏ tới các chức năng bên trong các đối tượng dữ liệu. Nếu bạn làm như vậy, thì bạn đang bước vào OOP.

Tôi không muốn nhắc đến Alan Kay như thể anh ta là Moses đang đưa những chiếc máy tính bảng xuống. Thay vào đó, anh ấy đã được đào tạo về toán và sinh học, tôi tin thế. Là một người giỏi toán, có lẽ anh ta đã quen với Lambda Tính, một thứ khá trừu tượng, không liên quan đến phần cứng. Trong LC, bạn có thể nói mọi thứ là một "đối tượng" - giống như số 0 và số 1 là các đối tượng đánh giá các thứ khác nhau khi đưa ra một đối số. Điều đó dẫn đến Smalltalk khá độc đáo. Ý tưởng về "thông điệp" là để chúng ta có thể tránh nói về phần cứng. Bạn có thể nói khi bạn gọi một hàm (hoặc một phương thức của một đối tượng) bạn đang gửi nó một tin nhắn và khi nó trả về, nó sẽ gửi một tin nhắn cho bạn (hoặc để bạn tiếp tục). Điều đó đã được đưa vào như một cách mô tả các cách để giao tiếp giữa các chương trình chạy không đồng bộ trên phần cứng riêng biệt. Tốt rồi, nhưng đối với chương trình thông thường, nó sẽ được mang đi. Để có được giá trị của ý tưởng OOP, bạn không cần phải từ chối mức độ liên quan của nhiệm vụ cụ thể mà bạn đang cố gắng thực hiện hoặc từ chối tính cụ thể của phần cứng bạn đang chạy. Tôi nghĩ rằng việc dạy về OOP theo cách tương tự có thể khiến mọi người nghĩ về thiết kế phần mềm quá nhiều về cấu trúc dữ liệu, dẫn đến thiết kế quá mức của nó, dẫn đến sự phình to mã hóa và các vấn đề hiệu năng lớn, mà tôi phải dành thời gian để dọn dẹp khi nó đủ tệ

Tôi cho rằng có rất ít sự khác biệt trong việc sử dụng một đối tượng vật lý làm ví dụ và sử dụng một đối tượng phi vật lý làm ví dụ. Trong mã cả hai đều có các phần chính xác giống nhau. Nếu chúng ta sử dụng ví dụ đồ họa và dạy nó với Sphere, khối lập phương, hình trụ, thì nó gần giống như sử dụng bóng, hộp, cột.

Vì vậy, để dạy nó mà không sử dụng các ví dụ vật lý, tôi khuyên bạn không nên sử dụng bất kỳ ví dụ nào, nhưng tôi không hiểu tại sao bạn không muốn các ví dụ vật lý để lập trường của tôi về chủ đề này là

Không, bạn không nên dạy nó mà không có các đối tượng trong thế giới thực

Tôi không thấy làm thế nào bạn có thể tránh bắt đầu bằng những ẩn dụ trong thế giới thực, nhưng bạn không muốn ở lại đó. Nếu bạn đang thực hiện OOP đúng, nó sẽ nhanh chóng trở nên trừu tượng, nhưng ở cấp độ hiểu biết tiếp theo, người học nên hiểu các đối tượng như các đối tượng.

Điều thú vị là một số ví dụ yêu thích của tôi không phải là đối tượng vật lý. Lấy tài khoản ngân hàng làm ví dụ. Mọi người "được" tại sao tiền gửi () và rút tiền () nên tính phí dịch vụ, thay vì dựa vào mã gọi để thay đổi giá trị của số dư và nhớ gỡ bỏ phí dịch vụ. Hình dạng trên màn hình là vô hình gấp đôi, và Stroustrup nói với tôi ví dụ "Hình dạng" kinh điển là một trong hai ví dụ OO lâu đời nhất mà anh biết, có từ 40 năm trước (cái kia là phương tiện, hiện đã 44 tuổi.)

Điều quan trọng là mọi người hiểu ví dụ của bạn ngay lập tức. Thang máy làm một ví dụ tốt chỉ với những người quen thuộc với thang máy. Vân vân.

Nếu bạn ở trong một nhóm lập trình, hãy tập hợp một vài người và bắt đầu thảo luận về cách bạn sẽ bảo nhau làm những gì bạn cần hệ thống để làm. Nghĩa đen là đảm nhận các vai trò trong hệ thống (bạn có thể tự mình làm điều này bằng cách chỉ chơi mỗi vai trò, nhưng sẽ dễ dàng hơn với một nhóm người. Đồ chơi giúp bạn nếu bạn tự mình làm). Tập trung vào những gì mỗi người đang làm / sẽ làm, hơn là vào những dữ liệu họ có. Làm điều này với mọi người giúp điều này tập trung vào các thông điệp và vai trò bởi vì mọi người có xu hướng nhớ những gì họ đang làm nhưng không phải là dữ liệu họ có.

Hãy lưu ý về những gì bạn phải yêu cầu nhau làm, và những thông tin bạn cần để làm điều đó. Hãy bảo vệ dữ liệu của riêng bạn, nếu một lập trình viên khác yêu cầu dữ liệu của bạn cho điều gì đó nói không và hỏi anh ta tại sao anh ta cần nó (giúp đóng gói dữ liệu).

Tôi nghĩ rằng một cách tiếp cận từ dưới lên / kim loại có thể hữu ích. Đầu tiên giải thích các cấu trúc và con trỏ kiểu C, để chỉ ra cách dữ liệu có thể được cấu trúc thay vì chỉ sử dụng trực tiếp nguyên thủy. Sau đó giải thích ràng buộc muộn và con trỏ chức năng. Sau đó giải thích rằng bạn có thể sử dụng những thứ này để xây dựng các đối tượng, về cơ bản là các đống dữ liệu được đóng gói tốt và các con trỏ tới các chức năng cần thiết để vận hành trên dữ liệu đã nói.

Giải thích này mâu thuẫn với cách dạy toán / comp sci thông thường trong việc giảng dạy khái niệm một cách độc lập với việc thực hiện, nhưng đó là viễn cảnh khiến tôi (phải thừa nhận là một người có kỹ thuật, không phải là một sci, nền tảng) cuối cùng cũng nhận được OO.