Đối với những vấn đề là lập trình hướng đối tượng không phải là một lựa chọn tốt? [đóng cửa]

Một phần lấy cảm hứng từ câu hỏi này: Đối với những vấn đề phổ biến là lập trình chức năng không phù hợp? - nhưng vẫn là một câu hỏi mà tôi luôn muốn, nhưng quá ngại để hỏi.

Tôi đã ở ... tốt, hãy gọi nó là phát triển phần mềm kỹ thuật trong suốt cuộc đời tôi, và trong suốt thời gian đó, mặc dù OO luôn ở đó (tốt, hầu hết thời gian đó) tôi chưa bao giờ có nhu cầu sử dụng "Cách của nó", cũng không phải để tìm hiểu mô hình đó. Chúng tôi đã luôn sử dụng các cấu trúc chương trình, thói quen / chức năng / mô-đun khá đơn giản và mặc dù nó trái ngược với các thực tiễn tốt nhất hiện nay khi quản lý các chương trình đó (các chương trình lên tới khoảng 300 nghìn LỘC, không có gì quá lớn) không bao giờ tỏ ra khó khăn.

Vì vậy, tôi muốn hỏi bạn, điều gì sẽ là vấn đề sắp xếp cho mô hình hướng đối tượng sẽ không phải là một lựa chọn tốt? So với lập trình thủ tục?

Lập trình hướng đối tượng là lập trình thủ tục. Điều làm cho đối tượng OO được định hướng là, như Robert Harvey đã đề cập trong một nhận xét, rằng OO trừu tượng hóa dữ liệu theo một cách cụ thể (để dí dỏm: gói các chức năng hoạt động trên một cấu trúc với cấu trúc đó).

William Cook giải thích sự khác biệt giữa các đối tượng và các loại dữ liệu trừu tượng độc đáo.

Vì vậy, có nguy cơ nghe có vẻ không ổn, tôi nói rằng các đối tượng không phù hợp khi bạn cần dễ dàng mở rộng (số lượng) thao tác thực hiện trên dữ liệu của mình và bạn không cần phải triển khai các cách khác nhau dữ liệu. Phải nói rằng, có những điều bạn có thể làm để đưa hai người lại gần nhau hơn.

Giá trị chính của OO là nó cung cấp sự tách rời giữa các thành phần trong hệ thống của bạn, giúp viết mã DRY dễ dàng hơn và thích ứng với các loại thay đổi cụ thể mà bạn dự định thực hiện trong thiết kế của mình. Cái giá phải trả là nó bổ sung các lớp không xác định, điều này có thể khiến mã khó lý giải hơn, kém hiệu quả hơn và khó sửa đổi hơn theo những cách không lường trước được (những cách không được hỗ trợ bởi việc tách rời thiết kế của bạn cung cấp). Do đó, thật lãng phí thời gian cho bất kỳ dự án con nào mà bạn không cần tách rời mà nó cung cấp. Cụ thể, thật lãng phí thời gian nếu bạn có thể dễ dàng viết mã DRY mà không cần mã đó và không lường trước bất kỳ thay đổi yêu cầu cụ thể nào có lợi từ việc tách rời mạnh mẽ mà OO cung cấp.

đồng thời: cơ chế khóa có vẻ như có vấn đề; chỉ một số nhà phát triển rất giỏi được đưa vào làm việc trên phần phân luồng của các dự án

mở rộng: không biết các ngôn ngữ OO hiện tại có thể mở rộng như thế nào. chỉ biết rằng Java là xấu. do đó DSL (ngôn ngữ dành riêng cho tên miền) phải được triển khai dưới dạng Khung. Clojure mặt khác (đó là chức năng), có macro.

Hầu hết các lập trình viên, hiểu biết OO hay không, sử dụng các khái niệm như trừu tượng hóa, ẩn thông tin và giao diện trong mã của họ. Các ngôn ngữ OO đơn giản làm cho điều đó dễ dàng hơn vì các khái niệm này đã được tích hợp sẵn. Bạn không phải tự phát minh ra chúng.

Một thuật toán cốt lõi như qsort()sử dụng trừu tượng để so sánh các đối tượng tùy ý. fread()sử dụng một giao diện để trừu tượng hóa các chi tiết của luồng, v.v.

Từ quan điểm đó, tôi thấy khó có thể đưa ra bất kỳ vấn đề cụ thể nào được giải quyết tốt hơn với cách tiếp cận không OO.

Tôi nghĩ rằng khi xây dựng các hệ thống kết hợp các hệ thống khác thông qua web apis (phần còn lại, xmlprc, curl / wget), bạn có thể viết các trình bao bọc OO nhưng rõ ràng đó chỉ là sự tiện lợi. Nếu dịch vụ web được sử dụng là đơn giản và đó chỉ là vấn đề của một hoặc hai dòng, thì OO là quá nhiều. Mặt khác, nếu bạn cuối cùng phải bọc một api web phức tạp (ví dụ như Amazon AWS) thì thật tuyệt khi có một thư viện trình bao bọc (như boto trong python cho AWS).

Suy nghĩ?

Các ngôn ngữ hướng đối tượng PURE không phù hợp với nhiều trường hợp. Bởi vì có một số tiêu chí cần được đáp ứng để trở thành ngôn ngữ hướng đối tượng thuần túy. Xem-
/programming/250062/what-is-meant-by-the-term-true-object-orientation/250098#250098

Nhưng hầu hết các ngôn ngữ lập trình được sử dụng rộng rãi là đa mô hình. Họ kết hợp nhiều tính năng không phải OO để gặp các loại vấn đề lập trình và phát triển khác nhau. C ++, C #, Java hoặc Ruby đều có chức năng không phải OO. Vì vậy, họ có thể phải đối mặt với các vấn đề mà OO thuần túy không giỏi.

Lập trình hướng đối tượng có thể được sử dụng để mô hình hóa miền của bạn. Các lớp có thể được sử dụng để thể hiện trạng thái và hành vi của các thực thể, tập hợp, hợp tác, dịch vụ trong mô hình miền của bạn. Hơn nữa, các yêu cầu phương thức và giao thức giữa các đối tượng có thể mô hình hóa các mối quan hệ động giữa các thực thể.

Tôi đã thấy đó là một cách hữu ích để tạo ra một mô hình DRY có thể trình bày rõ ràng các quy tắc và hành vi của ứng dụng của bạn theo cách tách rời khỏi các vấn đề kỹ thuật (chẳng hạn như việc sử dụng cơ sở dữ liệu hoặc hàng đợi tin nhắn hoặc thực tế nó là một ứng dụng web) Một cuốn sách hay về chủ đề này là Domain Driven Design

Một điều quan trọng cần lưu ý ở đây là "các thực thể" mà tôi đã đề cập ở trên không phải ánh xạ lên các vật thể trong thế giới thực! Chúng có thể đại diện cho các phần trừu tượng của miền ứng dụng của bạn.

Vì vậy, nếu đó là những gì lập trình Object Orientated giỏi; cái gì không tốt Vâng, bất cứ điều gì mà mô hình miền không thể được thể hiện tốt như các đối tượng. Ví dụ, một số chương trình toán học, (thống kê, logic, v.v.) hoặc kỹ thuật (ví dụ: trình biên dịch) có thể biểu hiện tốt hơn trong các phong cách khác nhau. Tôi đã thấy rằng đối với các ứng dụng quy trình công việc kinh doanh, sự kết hợp giữa OO và các kỹ thuật DSL tùy chỉnh đã rất hiệu quả trong việc cho phép chúng tôi mô hình hóa các loại mối quan hệ và sự kiện xảy ra trong quy trình kinh doanh. Để xác minh chương trình và kiểm tra bằng chứng tự động, một cách tiếp cận chức năng thường được sử dụng, bởi vì các hàm thuần túy của nó cho phép lý luận toán học trực tiếp hơn.