OOP là mô hình lập trình thống trị trong thế giới thực?

Đối tượng không bao giờ? Vâng, hầu như không bao giờ

Trong phần VIEWPOINT của Truyền thông của ACM, tôi đã tìm thấy một bài viết thú vị có tên " Đối tượng không bao giờ? Vâng, hầu như không bao giờ ". Đó là một viễn cảnh hoàn toàn khác so với các đối tượng - trước tiên hoặc các đối tượng - muộn. Ông gợi ý "đối tượng - không bao giờ" hoặc có thể "đối tượng - trường đại học".

Tác giả đã nói về OOP và đặt câu hỏi về cách sử dụng OOP trong môi trường lập trình thế giới thực. Ông nghĩ rằng OOP không phải là mô hình lập trình thống trị. Ví dụ, ông tuyên bố, 70% chương trình được thực hiện cho Hệ thống nhúng trong đó OOP không thực sự phù hợp.

Khi một số giáo sư trong các trường đại học muốn nói về lợi ích của OOP, họ nói về việc tái sử dụng mã. Một ví dụ khác, một lần nữa, ông tuyên bố, đây không phải là trường hợp thực tế trong thế giới thực. tái sử dụng mã khó hơn những gì được tuyên bố trong các trường đại học:

Tôi cho rằng việc sử dụng OOP không phổ biến như hầu hết mọi người tin, rằng nó không thành công như những người đề xuất tuyên bố, và do đó, vị trí trung tâm của nó trong chương trình giảng dạy CS là không chính đáng.

Thật thú vị cho tôi khi biết mọi người trong stack-over nghĩ gì về điều này? OOP có phải là mô hình lập trình thống trị theo quan điểm của lập trình viên không?

Nếu tôi nên chọn / học / sử dụng chỉ một cách tiếp cận, đó có phải là OOP hay không? tại sao?

Trong phần VIEWPOINT của Truyền thông của ACM

Nếu bạn quan tâm đến lập trình thực tế , các thủ tục tố tụng của ACM và lượt thích là nguồn cuối cùng bạn muốn đọc. Đây thường là các ấn phẩm khoa học [giả] không có ứng dụng trong thế giới thực. Đây thường là những ý kiến ​​không chính thống được đưa ra để công khai, cho nhà văn để phân biệt chính mình với đám đông và quảng bá con người của chính mình.

Tôi cho rằng việc sử dụng OOP không phổ biến như hầu hết mọi người tin, rằng nó không thành công như những người đề xuất tuyên bố, và do đó, vị trí trung tâm của nó trong chương trình giảng dạy CS là không chính đáng.

Tôi có xu hướng không đồng ý với quan điểm của bạn. OOP được lan truyền rộng rãi và hoạt động tốt. Theo số lượng các dự án dựa trên OOP có khả năng vượt qua các phát triển được thực hiện với các chiến lược khác (hãy nói về thời hiện đại, 15-20 năm).

Tuy nhiên OOP không phải là viên đạn bạc. Nó hoạt động cho một số phát triển, không làm việc cho những người khác. Cũng giống như bất kỳ phương pháp khác.

Nhưng một điều tôi cần đề cập là một chương trình giảng dạy nên truyền đạt kiến ​​thức về các phương pháp khác nhau. Nếu nó dựa trên OOP, nó sai. Nếu nó dựa trên FP, nó sai. Nó sẽ bao gồm tất cả hoặc không chạm vào chủ đề này hoàn toàn.

PS Tại sao quan tâm về những gì chiếm ưu thế và những gì không? Chỉ cần lấy những gì phù hợp cho dự án trong tay và để lại những con số cho "các nhà nghiên cứu".

Nếu OOP là mô hình duy nhất bạn biết, có lẽ bạn nên tìm hiểu thêm. Nhưng thực sự, OOP thực sự có nghĩa là gì? Nó có nghĩa là Java hay C ++? Nó có nghĩa là Smalltalk? Nó có nghĩa là khe giá trị có thể giải quyết và đóng cửa? (Xin chào, Đề án!) Có nghĩa là gửi tin nhắn? (Xin chào, Erlang!)

Nói tóm lại, có vẻ như một câu hỏi không thú vị để hỏi. "OO có hữu ích không?" là một câu hỏi tốt hơn. Và, tốt, có vẻ như vậy. (Chắc chắn nó là dành cho tôi.)

Tất cả các nhà phát triển đang thực hiện những "70% chương trình" đó ở đâu? trong số tất cả các nhà phát triển tôi biết có ít hơn 1% đang làm việc trên các hệ thống nhúng.

Vì vậy, chúng tôi có 3 tùy chọn:

1. Tôi là duy nhất và tất cả bạn bè của bạn thực sự làm chương trình nhúng
2. Có những đội quân của các nhà phát triển bị nhốt dưới tầng hầm ở đâu đó làm 70%
3. thống kê này được tạo thành và bài báo là nhảm nhí

trừ khi tôi thấy một số bằng chứng cho thấy các tùy chọn 1 hoặc 2 thực sự đúng, tôi sẽ sử dụng tùy chọn 3.

(BTW, tôi không xem xét lập trình nhúng phát triển di động hiện đại và phát triển di động thường là OO, sau tất cả Apple buộc bạn phải sử dụng * Objective * C để phát triển cho iPhone)

Tôi không có sự thật để theo dõi nó, nhưng OOP không phải là mô hình lập trình thống trị. Chỉ cần tưởng tượng tất cả những ứng dụng nội bộ được phát triển bởi một người đã tham gia khóa học cơ bản trực quan hoặc thực hiện một số chương trình macro trong Excel.

Rất nhiều ứng dụng chỉ đang thực hiện lập trình bắt buộc trong đó tất cả logic được xếp chồng lên nhau trong một lớp hoặc dạng xem. Đây có lẽ là phần lớn các ứng dụng đơn giản nội bộ chạy trên tất cả các doanh nghiệp.

Không có gì sai với điều đó, có một số cách để giải quyết vấn đề tương tự. Một số phù hợp hơn so với những người khác.

Cũng như bạn đã chỉ ra, OOP không hữu ích cho tất cả các kịch bản. Có những mô hình khác là tốt.

Việc OOP có phải là mô hình lập trình thống trị hay không là không liên quan, chỉ cần đặt các mô hình khác nhau phù hợp với các trường hợp khác nhau.

Không có viên đạn bạc.

Những gì Moti Ben Ari đang tranh luận là một khẳng định học thuật, vốn đã vô nghĩa. Tuy nhiên, anh tự nhận rằng mình chưa bao giờ thấy OOP "có ý nghĩa", rõ ràng nó làm được với hàng ngàn nhà phát triển và kỹ sư phần mềm và đã được sử dụng trong nhiều hệ thống ...

Nhưng, thực sự quan điểm của câu trả lời của tôi là thế này, có ích gì khi nói rằng mô hình này hay mô hình khác chiếm ưu thế hay không, đó có phải là lý do tốt để sử dụng nó một cách mù quáng? Tất nhiên, không phải vậy.

Đây thực sự là một câu hỏi khó trả lời đáng tin cậy. Lý do lớn nhất là những người như tôi, người làm việc trong các ứng dụng tùy chỉnh, nội bộ, nơi mã không bao giờ rời khỏi tòa nhà của chúng tôi. Chúng ta có sử dụng OO ở đây không? Tôi không nói. Có bao nhiêu lập trình viên khác có công việc tương tự? Họ cũng không nói. Chúng tôi có các trang web việc làm, nhưng không phải tất cả các công việc đều được đăng, và không phải tất cả các bài đăng đều dành cho các công việc thực tế trái ngược với các nhà tuyển dụng đang cố gắng thu thập danh sách tên.

Ngay cả khi tôi đã nói rằng chúng tôi sử dụng OO nơi tôi làm việc, điều đó có nghĩa là định nghĩa truyền thống từ bài viết được liên kết: Đối tượng, Lớp học, Kế thừa? Hay nó có nghĩa là tôi sử dụng các đối tượng chủ yếu như một phương tiện tổ chức mã? Hay nó có nghĩa là tôi thực sự chỉ lập trình cho các giao diện và hầu như không sử dụng tính kế thừa nào cả? Tôi vẫn không nói, nhưng cái nào trong số này thực sự được tính là OO?

Nó thậm chí không có ý nghĩa để hỏi nếu OO có hữu ích cho đến khi các câu hỏi trên đã được trả lời, hãy để một mình chi phối.

Tất nhiên là như vậy, bởi vì đó là từ thông dụng mới nhất mà ban quản lý đã theo đuổi. Nó cũng cung cấp sự đóng gói và trừu tượng tốt hơn cho lập trình mệnh lệnh, vì vậy tôi nghĩ rằng bước nhảy vọt từ oop sang bất cứ điều gì tiếp theo có thể mất nhiều thời gian hơn so với bắt buộc phải thực hiện.

PS2: Nếu tôi nên chọn / học / sử dụng chỉ một cách tiếp cận, đó có phải là OOP hay không? tại sao?

Nếu bạn chỉ học một trường, bạn nên chọn một lĩnh vực khác.

Bạn nên tìm hiểu về các loại và đóng gói và tất cả các lợi ích khác của OOP, sau đó học cách hoàn thành những điều tương tự bằng cách sử dụng một kiểu lập trình chức năng.

OOP chắc chắn là một trong những mô hình lập trình nổi trội hơn trong thế giới thực.

Hãy đối mặt với nó, ngay cả những người thiết kế phần cứng kỹ thuật số, chính các nhà thiết kế chip, đang thực hiện một quá trình chuyển đổi sang bộ đôi SystemVerilog và SystemC. Đây là những ngôn ngữ lập trình hướng đối tượng.

OOP sẽ không được sử dụng ở đâu? Chà, nếu bạn đang mã hóa trình điều khiển thiết bị, thật khó để tưởng tượng tại sao bạn cần lập trình chung hoặc nhiều kế thừa HOẶC nếu bạn đang thực hiện các kỹ thuật lập trình chức năng AI, làm cho nó dễ dàng hơn rất nhiều. Có rất nhiều tình huống khác nữa, đủ để nói rằng mặc dù OOP là một nơi khá mạnh mẽ để có mặt trong một thế giới lập trình độc quyền.

Tôi sẽ nói không.

Tôi hiểu rằng có một số lượng lớn mã được viết bằng ngôn ngữ 'hướng đối tượng', nhưng nói chung tôi thấy rằng mã chỉ là thủ tục được gói trong các lớp. (không phải điều này nhất thiết là một điều xấu). Mã mà tôi đã thấy được viết là OO nhiều hơn trong các ngôn ngữ này có xu hướng là một mớ hỗn độn khủng khiếp của các phụ thuộc giữa các lớp thường không thể duy trì được.

OO được cho là về thông điệp truyền giữa các đối tượng hoàn toàn khép kín và chúng ta thấy điều đó trong mã ngày nay, nhưng ở mức độ lớn hơn nhiều - tức là chúng ta thấy các đối tượng này được triển khai dưới dạng dlls hoặc hội đồng hoặc đối tượng COM. 'Thành phần' Tôi đã nghe họ mô tả là.

vì vậy, tôi nghĩ rằng việc OO có được sử dụng hay không thực sự không quan trọng - nếu mã có thể được duy trì trong suốt vòng đời của nó, có thể sử dụng lại ở mức độ được thiết kế và phát triển nhanh, thì tôi không quan tâm nếu nó hoàn toàn là thủ tục hoặc bán hướng đối tượng hoặc hoàn toàn OO. Tôi nghi ngờ rằng bất cứ ai cũng có thể cho bạn biết liệu phong cách chiếm ưu thế có phải là một trong số đó không, nhưng tôi có thể đoán rằng phong cách thủ tục sẽ là phổ biến nhất, ngay cả khi nó được cắt thành các lớp thay vì các chức năng.

Tôi nghĩ rằng điều quan trọng là phải khác biệt hóa một giải pháp có được bằng cách áp dụng Phương pháp tiếp cận hướng đối tượng và giải pháp thực hiện SỬ DỤNG mô hình hướng đối tượng. Ý kiến ​​của tôi về một phần mềm hướng đối tượng tốt là kết hợp cả hai giải pháp. Nếu bạn nghĩ trong các đối tượng và bạn tôn trọng các định nghĩa và tương tác của đối tượng và vấn đề của bạn có thể được điều chỉnh để sử dụng cấu trúc này, thì bạn sẽ có một mã linh hoạt và mạnh mẽ. Nhưng nếu bạn sử dụng các đối tượng để giải quyết mã bằng mô hình thủ tục, bạn sẽ kết thúc với một số hỗn hợp khó chịu sẽ không tận dụng lợi thế từ các ưu điểm của Đối tượng.

Tôi thực sự thích mã của mình là Hướng đối tượng và tôi nhận ra rằng lúc đầu, việc tạo ra một cấu trúc tốt có thể khó chịu hơn một chút, nhưng khi xử lý các yêu cầu linh hoạt và flash của khách hàng ngày nay, tôi nghĩ rằng nó đáng giá cố gắng.

Tôi không giả vờ biết con số chính xác, hoặc thậm chí để đoán sơ bộ, nhưng có nhiều dự án lập trình không liên quan đến OOP. Tôi làm việc với robot công nghiệp. Các chương trình có xu hướng khá đơn giản và mã thủ tục chuyển tiếp thẳng. Hệ điều hành robot thực tế thậm chí còn hơn thế.

Nhiều "công cụ" mà chúng tôi sử dụng dựa trên OOP, nhưng chúng chạy trên PC chứ không phải bộ điều khiển robot. Chúng bao gồm các biên tập viên, mô phỏng và tiện ích.