Giới hạn của OOP Paradigm trong hệ thống thực sự phức tạp?

Question

Tôi hỏi một câu hỏi trước về Dataset vs Business Objects .NET Dataset vs Business Object : Why the debate? Why not combine the two?

và tôi muốn khái quát các vấn đề ở đây: đâu là bằng chứng cho thấy OOP là thực sự thích hợp cho vấn đề rất phức tạp? Hãy lấy một MMO Game Engine chẳng hạn. Tôi không phải là chuyên gia ở tất cả nhưng khi tôi đọc bài viết này, nó đứng rõ ràng rằng OOP là xa là đủ:

http://t-machine.org/index.php/2007/11/11/entity-systems-are-the-future-of-mmog-development-part-2/

Nó kết luận: trình cũng với Hệ thống Entity rất gần với lập trình với một cơ sở dữ liệu quan hệ. Sẽ không phải là không hợp lý khi gọi ES là một dạng “Lập trình hướng liên quan”.

Vì vậy, OOP không cố gắng loại bỏ thứ gì đó ở đây để ở?

OOP là phi tuyến tính, Quan hệ là tuyến tính, cả hai đều cần thiết tùy thuộc vào một phần của hệ thống, vậy tại sao cố gắng loại bỏ quan hệ chỉ vì nó không phải là đối tượng "thuần túy". OOP có tự kết thúc không?

Câu hỏi của tôi không phải là OOP hữu ích. OOP là hữu ích, câu hỏi của tôi là khá lý do tại sao người thuần túy muốn làm "tinh khiết" OOP?

Answer 1

Là tác giả của bài đăng được liên kết, tôi nghĩ tôi sẽ ném vào một vài suy nghĩ.

FYI: Tôi bắt đầu nghiêm túc (nghĩa là cho công việc thương mại) sử dụng OOP/ORM/UML vào năm 1997 và tôi mất khoảng 5 năm để sử dụng hàng ngày để thực sự tốt với IMHO. Tôi đã lập trình bằng ngôn ngữ ASM và không phải OOP trong khoảng 5 năm trước thời điểm đó.

Câu hỏi có thể không đúng ngữ pháp, nhưng tôi nghĩ đó là một câu hỏi hay khi tự hỏi bản thân và điều tra - khi bạn hiểu cách viết cụm từ tốt hơn, bạn sẽ học được rất nhiều điều hữu ích.

"Vì vậy, OOP không cố gắng loại bỏ một thứ gì đó ở đây để ở lại?"

Thứ nhất, đọc báo Bjarne ở đây: http://www.stroustrup.com/oopsla.pdf

IMHO, không ai nên được dạy bất kỳ OOP mà không đọc báo đó (và đọc lại sau khi họ đã "học" OOP). Vì vậy, nhiều người hiểu lầm những gì họ đang đối phó với.

IME, nhiều khóa học đại học không dạy tốt OOP; họ dạy mọi người cách viết các phương pháp và các lớp học, và cách sử dụng các đối tượng. Họ dạy kém lý do tại sao bạn sẽ làm những điều này, nơi mà các ý tưởng đến từ, v.v. Tôi nghĩ phần lớn việc sử dụng sai đến từ đó: gần như một trường hợp mù dẫn người mù (họ không mù trong "cách "để sử dụng OOP, họ chỉ mù trong" lý do "để sử dụng OOP).

Để trích từ đoạn cuối cùng của tờ báo:

"làm thế nào bạn có hỗ trợ kỹ thuật lập trình tốt và kỹ thuật thiết kế tốt quan trọng hơn nhãn và từ buzz Ý tưởng cơ bản chỉ đơn giản là để cải thiện thiết kế và lập trình thông qua trừu tượng.. Bạn muốn ẩn các chi tiết, bạn muốn khai thác bất kỳ tính phổ biến nào trong một hệ thống, và bạn muốn thực hiện điều này một cách hợp lý, và bạn muốn thực hiện điều này một cách hợp lý. định hướng '' quá thường xuyên bị xóa: - bằng cách đánh dấu nó bằng tốt, - bằng cách cân bằng nó với một ngôn ngữ hoặc - bằng cách chấp nhận mọi thứ theo hướng đối tượng.

Tôi đã lập luận rằng có - và phải là các kỹ thuật hữu ích ngoài lập trình và thiết kế hướng đối tượng. Tuy nhiên, để tránh bị hiểu lầm hoàn toàn, tôi muốn nhấn mạnh rằng tôi sẽ không cố gắng thực hiện một dự án nghiêm túc bằng cách sử dụng chương trình lan- mà không ít nhất hỗ trợ khái niệm cổ điển về lập trình hướng đối tượng. Ngoài các cơ sở hỗ trợ lập trình hướng đối tượng, tôi muốn –và C++ cung cấp các tính năng vượt ra ngoài những hỗ trợ để thể hiện trực tiếp các khái niệm và mối quan hệ. "

Bây giờ ... tôi sẽ hỏi bạn ... của tất cả các lập trình viên OOP và các dự án OOP bạn đã thấy, có bao nhiêu trong số họ có thể trung thực tuyên bố đã tôn trọng những gì Bjarne yêu cầu IME, có

ít hơn phần lớn

Bjarne nói rằng:?.

"Ý tưởng cơ bản chỉ đơn giản là cải thiện thiết kế và lập trình thông qua trừu tượng"

... nhưng nhiều người phát minh ra cho mình một ý nghĩa khác nhau, một cái gì đó như:

"Ý tưởng cơ bản là OOP là tốt, và tất cả mọi thứ-không-OOP là kém hơn"

Người lập trình đã lập trình tuần tự với ASM, sau đó sau đó ASM, sau đó pascal, sau đó C, sau đó C++, và đã được tiếp xúc với sự hỗn loạn đã được lập trình trước đóng gói vv có xu hướng có sự hiểu biết tốt hơn về công cụ này. Họ biết lý do tại sao OOP đến, những gì nó đã cố gắng để giải quyết.

Funnily đủ, OOP là không cố gắng giải quyết mọi vấn đề lập trình. Ai có thể mua nó, để nói nó được nói đến hôm nay như thế nào?

Nó nhằm vào một số lượng nhỏ các vấn đề cực kỳ nguy hiểm mà dự án của bạn càng lớn, và nó trở thành một nơi nào đó giữa "tốt" và "rất tốt" khi giải quyết.

Nhưng ngay cả một số trong số đó cũng không tốt hơn là chỉ "giải quyết tốt"; có mô hình khác được tốt hơn ...

Tất cả IMHO, of course;)

Answer 2

Hệ thống của bất kỳ độ phức tạp đáng chú ý nào không tuyến tính. Ngay cả khi bạn đã làm việc thực sự khó khăn để làm cho một hệ thống một quá trình tuyến tính, bạn vẫn dựa vào những thứ như đĩa, bộ nhớ và kết nối mạng có thể được flaky, vì vậy bạn sẽ cần phải làm việc xung quanh đó.

Tôi không biết ai nghĩ OOP là câu trả lời cuối cùng. Nó chỉ là một cách để đối phó với sự phức tạp bằng cách cố gắng để giữ cho các vấn đề khác nhau được giới hạn trong các quả cầu nhỏ nhất có thể để thiệt hại họ làm khi họ thổi lên được giảm thiểu. Vấn đề của tôi với câu hỏi của bạn là nó giả định sự hoàn hảo là có thể. Nếu có, tôi có thể đồng ý OOP là không cần thiết. Đó là cho tôi cho đến khi ai đó đến với một cách tốt hơn cho tôi để giảm thiểu số lượng sai lầm tôi thực hiện.

Answer 3

Điều chúng tôi cố gắng làm là đặt phong cách OO lên trên một hệ thống quan hệ. Trong đất C#, điều này giúp chúng ta có một hệ thống được đánh máy mạnh mẽ để mọi thứ từ đầu đến cuối có thể được biên dịch và kiểm tra. Cơ sở dữ liệu có một thời gian khó khăn đang được thử nghiệm, tái cấu trúc, vv OOP cho phép chúng tôi tổ chức ứng dụng của chúng ta thành các lớp và các nghiên cứu mà quan hệ không cho phép.

Answer 4

Bạn có câu hỏi lý thuyết.

Trước hết hãy để tôi đồng ý với bạn rằng OOP không phải là giải pháp giải quyết tất cả. Nó tốt cho những điều gì đó, nó không tốt cho người khác. Nhưng điều đó không có nghĩa là nó không mở rộng quy mô. Một số hệ thống khủng khiếp và khổng lồ đã được thiết kế sử dụng OOP.

Tôi nghĩ rằng OOP rất phổ biến vì nó xứng đáng. Nó giải quyết một số vấn đề khá tuyệt vời, nó rất dễ dàng để suy nghĩ về đối tượng bởi vì chúng ta có thể làm điều đó mà không cần lập trình lại chính mình. Vì vậy, cho đến khi tất cả chúng ta có thể đưa ra một lựa chọn thay thế tốt hơn thực sự hoạt động trong cuộc sống thực tế, tôi nghĩ rằng OOP là một ý tưởng khá hay và cũng là cơ sở dữ liệu quan hệ.

Answer 5

Thực sự không có giới hạn đối với những gì OOP có thể giải quyết - cũng giống như không có giới hạn thực sự đối với những gì C có thể giải quyết hoặc lắp ráp cho vấn đề đó. Tất cả đều là Turing-complete, đó là tất cả những gì bạn thực sự cần.

OOP chỉ đơn giản là cung cấp cho bạn một cách cấp cao hơn để phá vỡ chương trình, giống như C là một trình độ cao hơn so với trình biên dịch. Bài viết về hệ thống thực thể không nói rằng OO không thể làm điều này - trên thực tế, có vẻ như họ đang sử dụng OOP để triển khai Thực thể, Thành phần, v.v. Trong bất kỳ miền phức tạp nào, sẽ có nhiều cách khác nhau để phá vỡ nó và sử dụng OOP, bạn có thể phá vỡ nó xuống cấp độ đối tượng/lớp tại một số điểm. Điều này không loại trừ các khung khái niệm mức cao hơn được sử dụng để thiết kế hệ thống OOP.

Answer 6

Vấn đề không phải là cách tiếp cận hướng đối tượng trong hầu hết các trường hợp, vấn đề là hiệu suất và phát triển thực tế của phần cứng cơ bản.

Phát triển phần mềm tiếp cận mô hình OO bằng cách cung cấp cho chúng ta một phép ẩn dụ của thế giới thực, chúng ta có khái niệm xác định các thuộc tính được chấp nhận và mong đợi chung và các đối tượng thực tế trên thế giới. Là cách con người mô hình hóa mọi thứ và chúng ta có thể giải quyết hầu hết các vấn đề với nó.

Về lý thuyết, bạn có thể xác định mọi khía cạnh của trò chơi, hệ thống hoặc bất kỳ thứ gì sử dụng OO. Trong thực tế, nếu bạn làm, chương trình của bạn sẽ đơn giản hành xử quá chậm để mô hình bị rối tung bởi sự tối ưu hóa mà thương mại sự đơn giản của mô hình từ hiệu năng. Theo cách đó, các cơ sở dữ liệu quan hệ không hướng đối tượng nên chúng ta xây dựng một lớp hướng đối tượng giữa mã và cơ sở dữ liệu ... bằng cách làm như vậy bạn mất một số hiệu suất của cơ sở dữ liệu và một số biểu hiện của nó bởi vì, quan điểm của mô hình OO một cơ sở dữ liệu quan hệ là một lớp đầy đủ, là một đối tượng rất phức tạp cung cấp thông tin. Theo quan điểm của tôi, OO là một cách tiếp cận gần như hoàn hảo trong ý nghĩa lý thuyết của từ, vì nó ánh xạ chặt chẽ với cách chúng ta, con người, suy nghĩ, nhưng nó không phù hợp với các nguồn lực hạn chế của tính toán phát triển ... vì vậy chúng tôi có các phím tắt. Tại và, hiệu suất là quan trọng hơn nhiều so với tổ chức lý thuyết hoặc clearness để phím tắt này trở thành tiêu chuẩn hoặc thực hành thông thường.

Tức là, chúng tôi đang thích nghi mô hình lý thuyết với các giới hạn hiện tại của chúng tôi. Trong thời gian của cobol vào cuối những năm 70 đối tượng được định hướng đơn giản là không thể ... nó ngụ ý nhiều khía cạnh và hiệu suất quá ít nên chúng tôi sử dụng một cách tiếp cận đơn giản, vì vậy đơn giản hóa bạn không có các đối tượng hoặc lớp, bạn có các biến .. nhưng khái niệm là, trong thời gian đó, giống nhau. Các nhóm biến được mô tả các khái niệm liên quan, các thuộc tính mà ngày nay sẽ đưa vào một đối tượng. Kiểm soát chuỗi dựa trên giá trị biến được sử dụng để thay thế cấu trúc phân cấp lớp và v.v.

Tôi nghĩ rằng chúng tôi đã sử dụng OOP trong một thời gian dài và chúng tôi sẽ tiếp tục sử dụng nó trong một thời gian dài. Khi khả năng phần cứng được cải thiện, chúng tôi sẽ có thể đơn giản hóa mô hình để nó trở nên thích nghi hơn. Nếu tôi mô tả một cách hoàn hảo (gần như) khái niệm về một con mèo (liên quan đến rất nhiều mô tả cho nhiều khái niệm liên quan) khái niệm đó sẽ có thể được tái sử dụng ở mọi nơi ... vấn đề ở đây không, như tôi đã nói, với chính mô hình nhưng với những hạn chế của chúng ta để thực hiện nó.

EDIT: Để trả lời câu hỏi về lý do sử dụng OO thuần túy. Mỗi "khoa học" muốn có một mô hình hoàn chỉnh để đại diện cho mọi thứ. Chúng tôi có hai mô hình vật lý để mô tả tự nhiên, một ở cấp vi mô và một cho mô hình vĩ mô, và chúng tôi muốn chỉ có một vì nó đơn giản hóa mọi thứ nó cung cấp cho chúng ta một cách tốt hơn để chứng minh, kiểm tra và phát triển mọi thứ. Với OO, quy trình tương tự sẽ được áp dụng. Bạn không thể kiểm tra phân tích và chứng minh một hệ thống nếu hệ thống không tuân theo một bộ quy tắc chính xác. Nếu bạn đang thay đổi giữa các mô hình trong một chương trình thì chương trình của bạn không thể được phân tích đúng cách, nó phải được loại bỏ trong mỗi chương trình, được phân tích và sau đó được phân tích lại để thấy rằng các tương tác là chính xác.Nó làm cho rất nhiều khó khăn hơn để hiểu một hệ thống bởi vì trong thực tế, bạn có hai hoặc ba hệ thống tương tác theo những cách khác nhau.

Answer 7

Bạn có thể làm rõ chính xác những gì bạn đang cố gắng so sánh và chứng minh ở đây không? OOP là một mô hình lập trình, một trong rất nhiều. Nó không hoàn hảo. Nó không phải là một viên đạn bạc.

"Lập trình định hướng liên quan" có nghĩa là gì? Data-centric? Vâng, Microsoft đã hướng tới phong cách lập trình tập trung vào dữ liệu hơn cho đến khi họ từ bỏ Linq2Sql và hoàn toàn tập trung vào O/RM EntityFramework của họ.

Cơ sở dữ liệu quan hệ cũng không phải là tất cả. Có rất nhiều loại kiến ​​trúc cơ sở dữ liệu khác nhau: cơ sở dữ liệu phân cấp, cơ sở dữ liệu mạng, cơ sở dữ liệu đối tượng vv. Và những thứ đó thậm chí còn hiệu quả hơn quan hệ. Quan hệ rất phổ biến vì gần như cùng một lý do tại sao OOP rất phổ biến: nó đơn giản, rất dễ hiểu và thường đủ hiệu quả nhất.

Answer 8

Các bạn, không phải là câu hỏi nhiều hơn về ORM so với OOP? OOP là một kiểu lập trình - thứ thực sự được so sánh là một cơ sở dữ liệu quan hệ được ánh xạ lên các đối tượng.

OOP thực sự không chỉ là ORM! Nó cũng không chỉ là thừa kế và đa hình! Đó là một loạt các mẫu thiết kế cực kỳ rộng lớn và trên hết là cách chúng ta nghĩ về lập trình.

Jorge: ok, bạn đã chỉ ra phần tối ưu hóa - những gì bạn không thêm là bước này nên được thực hiện sau cùng và trong 99% trường hợp phần chậm không phải là OOP.

Bây giờ đơn giản và đơn giản: phong cách OOP với tất cả các hiệu trưởng được thêm vào (mã sạch, sử dụng các mẫu thiết kế, không phải cấu trúc thừa kế sâu và đừng quên kiểm tra đơn vị!) bạn đã viết. Điều đó lần lượt là cần thiết cho các công ty để giữ cho kinh doanh của họ an toàn. Đó cũng là một recepie cho các nhóm nhỏ để có sự hiểu biết tốt hơn với cộng đồng. Nó giống như một ngôn ngữ chung phổ biến ở đầu ngôn ngữ lập trình.

Answer 9

Chỉ cần đọc bài viết yr về Hệ thống thực thể, so sánh ES với OOP và điều này là sai trái về một số khía cạnh của OOP. ví dụ, khi có 100 trường hợp của một lớp, OOP không ủy quyền rằng có 100 bản sao của các phương thức lớp được nạp trong bộ nhớ, chỉ có một bản là cần thiết. Mọi thứ ES mong muốn có thể làm tốt hơn OOP vì nó có "Components", và "Systems", OOP hỗ trợ cũng như sử dụng các giao diện và các lớp tĩnh, (và/hoặc Singletons).

Và OOP tự nhiên phù hợp hơn với thế giới thực, như bất kỳ Miền tưởng tượng thực hoặc tưởng tượng nào, bao gồm nhiều vật thể và/hoặc vật lý và trừu tượng và mối quan hệ giữa chúng có thể được mô hình hóa với thiết kế phù hợp cấu trúc lớp OOP hiearchical.

Answer 10

Sẽ dễ dàng hơn khi nói về các khái niệm từ quan điểm thuần túy. Một khi bạn phải đối mặt với một vấn đề cuộc sống thực, mọi thứ trở nên phức tạp hơn và thế giới không còn là màu đen và trắng nữa. Cũng giống như tác giả của bài viết rất kỹ lưỡng trong việc chỉ ra rằng họ đang không làm OOP "OOP purist" cho bạn biết rằng OOP là chỉ cách để tiếp tục. Sự thật là ở đâu đó ở giữa.

Không có câu trả lời duy nhất, miễn là bạn hiểu các cách khác nhau (OOP, hệ thống thực thể, lập trình chức năng và nhiều hơn nữa) làm việc và có thể đưa ra lý do chính đáng cho tình huống bạn có nhiều khả năng thành công.

Answer 11

Giới thiệu về hệ thống đối tượng. Đó là một quan niệm thú vị nhưng nó mang lại không có gì thực sự mới.Ví dụ: trạng thái:

Kiểu OOP sẽ dành cho mỗi Thành phần không có hoặc nhiều phương pháp, mà một số thứ bên ngoài phải gọi vào một thời điểm nào đó. Phong cách ES là cho mỗi Thành phần không có phương pháp nhưng thay vào đó cho hệ thống chạy liên tục để chạy các phương thức nội bộ riêng của nó đối với các Thành phần khác nhau tại một thời điểm.

Nhưng không giống với mô hình chống lại Martin Fowler được gọi là "Mô hình miền thiếu máu" (được sử dụng rộng rãi ngày nay, trên thực tế) link?

Vì vậy, về cơ bản ES là một "ý tưởng trên giấy". Để mọi người chấp nhận nó, nó phải được chứng minh với các ví dụ mã làm việc. Không có một từ nào trong bài viết về cách thực hiện ý tưởng này trên thực tế. Không có gì nói về mối quan tâm khả năng mở rộng. Không có gì nói về khả năng chịu lỗi ...

Đối với câu hỏi thực tế của bạn, tôi không thấy cách các hệ thống thực thể được mô tả trong bài viết có thể tương tự như cơ sở dữ liệu quan hệ. Cơ sở dữ liệu quan hệ không có những thứ như "các khía cạnh" được mô tả trong bài viết. Trong thực tế, dựa trên cấu trúc dữ liệu bảng quan hệ - là rất hạn chế khi nói đến làm việc với dữ liệu phân cấp, ví dụ. Giới hạn hơn đối với cơ sở dữ liệu đối tượng ví dụ ...

Answer 12

Trớ trêu thay khi oo lập trình đến đã làm cho nó dễ dàng hơn để xây dựng hệ thống lớn hơn, điều này đã được phản ánh trong các đoạn đường nối lên trong phần mềm ra thị trường .

Về quy mô và độ phức tạp, với thiết kế tốt, bạn có thể xây dựng các hệ thống khá phức tạp. xem ddd Eric Evans cho một số mẫu nguyên tắc về xử lý độ phức tạp trong oo.

Tuy nhiên, không phải tất cả các miền sự cố đều phù hợp nhất với tất cả các ngôn ngữ, nếu bạn có quyền tự do chọn ngôn ngữ để chọn ngôn ngữ phù hợp với miền sự cố của mình. hoặc xây dựng một dsl nếu đó là thích hợp hơn.

Chúng tôi là kỹ sư phần mềm sau khi tất cả, trừ khi có được một người nào đó nói cho bạn làm thế nào để thực hiện công việc của bạn, chỉ cần sử dụng những công cụ tốt nhất cho công việc, hoặc viết chúng :)