Mối quan hệ giữa định hướng đối tượng và thuật toán

Khi tôi đọc một số sách giáo khoa thuật toán, chúng có đầy đủ các quy trình thông minh cho một số vấn đề (sắp xếp, đường đi ngắn nhất) hoặc một số phương pháp chung (thuật toán đệ quy, phân chia và chinh phục, lập trình động ...). Tôi tìm thấy một vài dấu vết của lập trình hướng đối tượng ở đó; (Tại sao họ định hướng thủ tục nhiều hơn?).

Sau đó tôi đã suy nghĩ:

• Mối quan hệ giữa các thuật toán và OOP là gì? Có phải họ là hai chủ đề độc lập?
• Có một số vấn đề chỉ có thể được trình bày và giải quyết bằng OOP?
• Làm thế nào OOP có thể giúp các thuật toán? Hoặc theo hướng nào nó có thể ảnh hưởng đến nó?

Đầu tiên, hãy xác định những gì chúng ta muốn nói bởi OOP. Theo OOP, ý tôi là chủ yếu:

• Đóng gói và ẩn các chi tiết trong lớp.
• Đa hình của hành vi thông qua kế thừa và phương pháp ảo.

Bây giờ để trả lời câu hỏi của bạn:

Mối quan hệ giữa các thuật toán và OOP là gì? Có phải họ là hai chủ đề độc lập?

Đúng.

Có một số vấn đề chỉ có thể được trình bày và giải quyết bằng OOP?

Số OOP chính cung cấp sự tiện lợi và khả năng suy luận về mã cho lập trình viên. Nó không làm tăng sức mạnh biểu cảm của bạn.

Làm thế nào OOP có thể giúp các thuật toán? Hoặc theo hướng nào nó có thể ảnh hưởng đến nó?

Giống như tôi đã nói ở trên. Cả hai điểm tôi mô tả OOP là áp dụng ở đây. Có thể ẩn chi tiết của các thuật toán và cấu trúc dữ liệu của chúng có thể giúp lý do về toàn bộ sự việc. Nhiều thuật toán chứa các chi tiết bạn không muốn người dùng sử dụng thuật toán đó. Ẩn những chi tiết đó giúp ích rất nhiều.

Khả năng có hành vi đa hình là tuyệt vời quá. Listđược định nghĩa là có thể thêm / xóa / xóa các mục ở bất kỳ đâu trong bộ sưu tập. Nhưng nó có thể được triển khai dưới dạng mảng có thể thay đổi kích thước, liên kết đôi hoặc liên kết đơn, v.v ... Có API đơn cho nhiều triển khai có thể giúp sử dụng lại.

Tại sao sách giáo khoa thuật toán được định hướng thủ tục nhiều hơn?

Như tôi đã nói, OOP không cần thiết để thực hiện một thuật toán. Ngoài ra, nhiều thuật toán đã cũ và được tạo khi OOP vẫn chưa phổ biến. Vì vậy, nó cũng có thể là một điều lịch sử.

Thuật toán và OOP là hai thuật ngữ khác nhau, chỉ có điểm chung, chúng là CS -terms. Đơn giản - Một thuật toán giống như một công thức nấu ăn : để làm x bạn cần các thành phần sau và thực hiện bước 1,2,3,4,5,6 ... sau đó bạn đã chuẩn bị bữa ăn.

Điều đó nói rằng, có vẻ như một sự phù hợp tự nhiên cho các thuật toán đại số được mô tả theo một cách thủ tục . Thủ tục có nghĩa là không có gì khác hơn: đầu tiên làm x và sau đó làm y .

Một vấn đề phổ biến là: »Cách sắp xếp một bộ x ?«. Một giải pháp dễ hiểu là bubble-sort:

1. Lặp lại tập hợp từ phần tử cuối cùng miễn là bạn chưa đạt đến phần tử đầu tiên và trong khi lặp lại
2. Bắt đầu lần lặp thứ 2 từ đầu đến phần tử hiện tại của lần lặp đầu tiên và
3. So sánh yếu tố hiện tại của (2) với người kế nhiệm
4. Nếu lớn hơn, hoán đổi vị trí

Đó là mô tả thuật toán / bằng lời nói của thuật toán bubblesort.

Ở đây có một triển khai thủ tục / mã giả

bubbleSort(Array A)
  for (n=A.size; n>1; n=n-1){
    for (i=0; i<n-1; i=i+1){
      if (A[i] > A[i+1]){
        A.swap(i, i+1)
    } 
  } 
}

Điều đó thật dễ dàng.

Làm thế nào mà nó liên quan đến OOP ? Bạn có thể sử dụng thuật toán này để xử lý các bộ sưu tập (một đối tượng) của các đối tượng :

Ví dụ trong Javascript (mặc dù không có OO-Lingo sạch , nhưng gần như không có bản tóm tắt và dễ hiểu)

objects =[{"name":"Peter"}, {"name":"Paul"}, {"name":"Mary"}]

compareObjects=function(x,y){ return x.name>y.name };

sorted = objects.sort(compareObjects)

console.log(sorted)

Chúng ta có a) một bộ sưu tập objects, b) một phương thức phổ biến cho bộ sưu tập sortnày chứa / tóm tắt thuật toán sắp xếp và c) các đối tượng của chúng ta Peter , Paul và Mary . Các đặc điểm kỹ thuật để phân loại được tìm thấy ở đây .

Mối quan hệ giữa các thuật toán và OOP là gì? Có phải họ là hai chủ đề độc lập?

Từ những gì đã nói, cần phải rõ ràng, câu trả lời nên là: có, họ đang độc lập.

Làm thế nào OOP có thể giúp các thuật toán? Hoặc theo hướng nào nó có thể ảnh hưởng đến nó?

OOP chỉ là một phong cách lập trình. Nó không thể giúp đỡ dưới bất kỳ hình thức nào. Mặt khác, một thuật toán có thể được thực hiện bằng ngôn ngữ OO để làm một cái gì đó cho các đối tượng (như được hiển thị)

Có một số vấn đề chỉ có thể được trình bày và giải quyết bằng OOP?

Tôi không thể nghĩ về một (nhưng điều đó không có nghĩa, đó là điều không thể). Nhưng nếu bạn nhìn nó theo một cách khác: OOP rất hữu ích, nếu bạn muốn mô hình hóa một số vấn đề và giải quyết nó bằng một thuật toán thích hợp. Giả sử bạn có một kỷ lục của friendsbạn có thể mô hình chúng như objectsvới propertiesvà nếu bạn muốn có một listsố friends được sắp xếp trong bất kỳ cách nào, bạn có thể sử dụng ví dụ mã đưa ra ở trên để làm chính xác điều đó.

Tại sao sách giáo khoa thuật toán được định hướng thủ tục nhiều hơn?

Như đã nói: nó tự nhiên hơn , vì thủ tục là đặc tính của thuật toán.

bạn có một vấn đề

Mô hình miền doanh nghiệp mô tả vấn đề của bạn và các khái niệm từ miền vấn đề bạn sẽ xử lý.

Các thuật toán mô tả cách bạn sẽ giải quyết vấn đề của mình, về mặt khái niệm; việc thực hiện của bạn sẽ như thế nào; và làm thế nào để bạn giải quyết vấn đề của mình sau khi bạn dịch nó thành thuật ngữ "Khoa học máy tính".

Mô hình lập trình cho dù OOP, Chức năng, Hợp lý, Thủ tục hoặc thậm chí Không cấu trúc, mô tả cách bạn sẽ cấu trúc giải pháp của mình, hình thức nào sẽ sử dụng, mà bạn sẽ sử dụng khái niệm "Kỹ thuật phần mềm" nào và " Lý thuyết ngôn ngữ lập trình "các khái niệm bạn sẽ sử dụng.

Nói một cách đơn giản hơn, các thuật toán mô tả chung về giải pháp của bạn cho vấn đề ("Đây là điều tôi sẽ làm"). Trong khi mô hình lập trình liên quan đến việc triển khai thực tế của bạn ("Đây là cách tôi sẽ thực hiện").

Thuật toán = kể câu chuyện " Cách " (nghĩa là cách thao tác dữ liệu đầu vào bằng cách sử dụng cấu trúc dữ liệu kịp thời để tạo ra kết quả mong muốn)

OOP = một " Phương pháp luận " được các ngôn ngữ OO tạo điều kiện để viết chương trình (= thuật toán + cấu trúc dữ liệu) mang lại cho bạn sự an toàn và trừu tượng về bộ nhớ

OOP chỉ là một mô hình của việc thực hiện các thuật toán.

Tương tự tốt : phim

Bạn có thể ghi lại cảnh bằng cách sử dụng diễn viên đóng thế hay không. Kịch bản (thuật toán) không thay đổi. Mọi người không nên thấy bất kỳ sự khác biệt trong kết quả cuối cùng.

EDIT: bạn có thể dùng thử MOOC chất lượng tốt: https://www.coursera.org/c thuyết / achs4partI xen kẽ các chủ đề thảo luận (đặc biệt là phương pháp OOP) và đưa ra bản chất của những gì bạn hỏi ở đây.

Alexander Stepanov là người tạo ban đầu của Thư viện mẫu tiêu chuẩn C ++, (STL), là thư viện thuật toán nền tảng cho C ++. C ++ là một ngôn ngữ đa mô hình bao gồm các tính năng "Hướng đối tượng", nhưng Alexander Stepanov có điều này để nói về Định hướng đối tượng:

http://www.stlport.org/resource/StepanovUSA.html

STL không hướng đối tượng. Tôi nghĩ rằng tính định hướng đối tượng gần như là một trò lừa bịp như Trí tuệ nhân tạo. Tôi vẫn chưa thấy một đoạn mã thú vị đến từ những người OO này.

Tôi thấy OOP không có kỹ thuật. Nó cố gắng phân hủy thế giới theo các giao diện khác nhau trên một loại. Để giải quyết các vấn đề thực sự, bạn cần các đại số đa biến - họ của các giao diện trải rộng trên nhiều loại. Tôi thấy OOP không hợp lý về mặt triết học. Nó tuyên bố rằng tất cả mọi thứ là một đối tượng. Ngay cả khi đó là sự thật thì nó cũng không thú vị lắm - nói rằng mọi thứ là một đối tượng không nói gì cả. Tôi thấy OOP sai về phương pháp. Nó bắt đầu với các lớp học. Như thể các nhà toán học sẽ bắt đầu với các tiên đề. Bạn không bắt đầu bằng tiên đề - bạn bắt đầu bằng bằng chứng. Chỉ khi bạn đã tìm thấy một loạt các bằng chứng liên quan, bạn mới có thể đưa ra các tiên đề. Bạn kết thúc với tiên đề. Điều tương tự cũng đúng trong lập trình: bạn phải bắt đầu với các thuật toán thú vị. Chỉ khi bạn hiểu rõ về chúng,

Tôi đã dành nhiều năm cố gắng tìm một số sử dụng cho thừa kế và ảo, trước khi tôi hiểu tại sao cơ chế đó bị lỗi cơ bản và không nên được sử dụng.

Stepanov thể hiện thư viện thuật toán của mình không phải bằng Đối tượng, mà bằng Trình lặp chung .

Các thuật toán mô tả những gì máy tính nên làm. Cấu trúc mô tả cách thuật toán được trình bày [trong mã nguồn]. OOP là một phong cách lập trình tận dụng các cấu trúc "hướng đối tượng" nhất định.

Sách thuật toán thường tránh OOP vì chúng tập trung vào thuật toán, không phải cấu trúc. Các đoạn mã dựa nhiều vào cấu trúc có xu hướng là những ví dụ nghèo nàn để đưa vào một cuốn sách thuật toán. Tương tự như vậy, các cuốn sách OOP thường tránh các thuật toán vì chúng làm xáo trộn câu chuyện. Điểm bán hàng của OOP là tính linh hoạt của nó và việc gắn nó vào một thuật toán làm cho nó có vẻ cứng nhắc hơn. Đó là về trọng tâm của cuốn sách hơn bất cứ điều gì khác.

Trong mã thực tế, bạn sẽ sử dụng cả hai bên cạnh nhau. Theo định nghĩa, bạn không thể giải quyết các vấn đề máy tính mà không có thuật toán và bạn sẽ khó có thể viết các thuật toán tốt mà không có cấu trúc (OOP hoặc cách khác).

Để làm ví dụ về nơi chúng mờ, hãy lấy Lập trình động. Trong một cuốn sách thuật toán, bạn sẽ mô tả cách lấy một tập dữ liệu đồng nhất trong một mảng và sử dụng Lập trình động để đi đến một giải pháp. Trong một cuốn sách OOP, bạn có thể bắt gặp một cấu trúc như Khách truy cập, đây là một cách để thực hiện các thuật toán tùy ý trên một tập hợp các đối tượng không đồng nhất. Ví dụ về sách DP có thể được coi là một Khách truy cập rất đơn giản hoạt động trên các đối tượng theo thứ tự từ dưới lên. Mô hình của Khách truy cập có thể được coi là bộ xương của vấn đề DP, nhưng thiếu thịt và khoai tây. Trong thực tế, bạn sẽ thấy bạn thường cần cả hai cùng nhau: Bạn sử dụng mẫu Khách truy cập để xử lý sự không đồng nhất trên tập dữ liệu của bạn (DP rất tệ ở đó) và bạn sử dụng DP trong cấu trúc của Trình truy cập để sắp xếp thuật toán của bạn để giảm thiểu thời gian chạy không

Chúng tôi cũng thấy các thuật toán hoạt động trên đầu của các mẫu thiết kế. Ví dụ từ khó hơn trong một không gian nhỏ, nhưng một khi bạn có cấu trúc, bạn bắt đầu muốn thao tác cấu trúc đó và bạn sử dụng thuật toán để thực hiện.

Có một số vấn đề chỉ có thể được trình bày và giải quyết bằng OOP?

Đây là một câu hỏi khó trả lời hơn bạn nghĩ. Theo thứ tự đầu tiên, không có lý do tính toán tại sao bạn cần OOP để giải quyết bất kỳ vấn đề nào. Bằng chứng đơn giản là mọi chương trình OOP đều được biên dịch thành tập hợp, đây là ngôn ngữ không phải là OOP.

Tuy nhiên, trong sơ đồ lớn hơn, câu trả lời bắt đầu ngại ngùng đối với có. Bạn hiếm khi bị giới hạn bởi các phương pháp tính toán. Hầu hết thời gian có những thứ như nhu cầu kinh doanh và kỹ năng của nhà phát triển là yếu tố của phương trình. Nhiều ứng dụng ngày nay không thể được viết mà không có OOP, không phải vì OOP bằng cách nào đó là cơ bản cho nhiệm vụ, mà bởi vì cấu trúc được cung cấp bởi OOP là điều cần thiết để giữ cho dự án đi đúng hướng và ngân sách.

Điều này không nói rằng chúng tôi sẽ không bao giờ từ bỏ OOP trong tương lai cho một số cấu trúc mới hài hước. Nó chỉ nói rằng nó là một trong những công cụ hiệu quả nhất trong hộp công cụ của chúng tôi cho một phần lớn các nhiệm vụ lập trình đáng ngạc nhiên hiện nay. Các vấn đề trong tương lai có thể khiến chúng ta tiếp cận phát triển bằng các cấu trúc khác nhau. Đối với một người, tôi hy vọng mạng lưới thần kinh đòi hỏi một cách tiếp cận phát triển rất khác, có thể hoặc không thể trở thành "Hướng đối tượng".

Tôi không thấy OOP biến mất trong tương lai gần do cách các nhà thiết kế thuật toán nghĩ. Đến nay, mô hình thông thường là ai đó thiết kế một thuật toán không sử dụng OOP. Cộng đồng OOP nhận ra thuật toán không thực sự phù hợp với cấu trúc OOP và thực sự không cần thiết, vì vậy họ bao bọc toàn bộ thuật toán trong cấu trúc OOP và bắt đầu sử dụng nó. Hãy xem xét boost::shared_ptr. Các thuật toán đếm tham chiếu mà phần còn lại bên trong shared_ptrkhông thân thiện lắm với OOP. Tuy nhiên, mô hình đã không trở nên phổ biến cho đến khi shared_ptrtạo ra một trình bao bọc OOP xung quanh nó cho thấy khả năng của các thuật toán ở định dạng có cấu trúc OOP. Bây giờ, nó phổ biến đến mức nó biến nó thành thông số kỹ thuật mới nhất cho C ++, C ++ 11.

Tại sao điều này rất thành công? Các thuật toán rất tốt trong việc giải quyết các vấn đề, nhưng chúng thường đòi hỏi một khoản đầu tư nghiên cứu ban đầu đáng kể để hiểu cách sử dụng chúng. Phát triển hướng đối tượng rất hiệu quả trong việc gói các thuật toán như vậy và cung cấp một giao diện đòi hỏi đầu tư ban đầu ít hơn để học.

Ngoài các câu trả lời tuyệt vời, tôi sẽ đề cập đến một điểm chung về khái niệm bổ sung giữa OOP và Thuật toán.

Cả OOP và Thuật toán đều nhấn mạnh vào việc sử dụng các điều kiện tiên quyết và hậu điều kiện để đảm bảo tính chính xác của mã.

Nói chung, đây là thực hành tiêu chuẩn trong tất cả các lĩnh vực của khoa học máy tính; tuy nhiên, nguyên tắc chỉ đạo này dẫn đến một con đường tiến hóa trong OOP giúp cho việc thực hiện các thuật toán trong môi trường OOP có lợi cho cả hai bên.

Trong OOP, một nhóm các đối tượng có thể thỏa mãn cùng một hợp đồng (điều kiện tiên quyết và hậu điều kiện) có thể được thực hiện để thực hiện một giao diện. Người dùng giao diện như vậy sẽ không cần biết triển khai nào được sử dụng trong đối tượng cơ bản, ngoại trừ trong một số tình huống hiếm gặp (trong đó xảy ra sự trừu tượng hóa rò rỉ).

Một thuật toán là việc thực hiện các bước được sử dụng để thực hiện tính toán, một bước sẽ lấy điều kiện tiên quyết và tạo ra hậu điều kiện.

Do đó, người ta có thể mượn ý tưởng trừu tượng theo cách tiên quyết và hậu điều kiện, và áp dụng nó vào các thuật toán. Bạn sẽ thấy rằng đôi khi các thuật toán phức tạp có thể được phân tách thành các bước nhỏ hơn và các bước nhỏ hơn này có thể cho phép các chiến lược thực hiện khác nhau miễn là các điều kiện tiên quyết và hậu điều kiện được đáp ứng.

Bằng cách thực hiện các thuật toán trong OOP, người ta có thể làm cho các bước nhỏ hơn này có thể hoán đổi cho nhau.

Cuối cùng, hãy nhớ rằng FP và OOP không loại trừ lẫn nhau. Bất cứ điều gì được mô tả ở trên cũng có thể được áp dụng như nhau cho FP.

What is the relation between algorithms and OOP? Are they two independent topics?

Các thuật toán là về cách giải quyết vấn đề (Cách tạo đầu ra từ đầu vào đã cho), OOP là về cách xây dựng hoặc thể hiện giải pháp của chúng tôi (các bước của thuật toán).

Một thuật toán có thể được mô tả bằng ngôn ngữ tự nhiên hoặc bằng ngôn ngữ lắp ráp, nhưng các khái niệm chúng ta có trong ngôn ngữ tự nhiên giúp chúng ta viết và hiểu nó tốt hơn. Ví dụ: thuật toán sắp xếp bong bóng có thể là:

bubbleSort(Array A)
  for (n=A.size; n>1; n=n-1){
    for (i=0; i<n-1; i=i+1){
      if (A[i] > A[i+1]){
        A.swap(i, i+1)
    } 
  } 
}

Để ẩn các chi tiết swapvà liên quan nó với Acú pháp và tính năng OOP, sau đó OO làm cho thuật toán gần với ngôn ngữ tự nhiên và sự hiểu biết của chúng ta.

Are there some problems which can only be presented and solved by OOP?

Không, nếu bạn cho rằng bất kỳ chương trình (hoặc thuật toán) nào trên máy tính sẽ được dịch sang một bộ hướng dẫn được thực thi trên CPU ( Turing Machine ) và nếu chúng tôi coi các hướng dẫn này là thuật toán cuối cùng giải quyết vấn đề trên máy tính , thì OOP không thể làm gì thêm. Nó chỉ làm cho nó gần hơn với sự hiểu biết và lý luận của con người. Đó là một cách để đóng gói các thủ tục và cấu trúc dữ liệu của chúng tôi.

How OOP can help algorithms? Or in which direction it can affect it?

Nó có thể giúp nêu hoặc xây dựng một thuật toán dễ dàng hơn hoặc dễ hiểu hơn. Nó có thể ẩn chi tiết và cung cấp một bức tranh lớn của giải pháp.

Về lý thuyết, thuật toán là thứ nhất và thực hiện nó thứ hai . Nhưng trong thực tế, chúng tôi không thể chắc chắn rằng thuật toán của chúng tôi hoạt động như mong đợi cho đến khi chúng tôi theo dõi nó hoặc tạo ra đầu ra dự kiến. Máy tính giúp chúng tôi làm điều đó, nhưng bạn không nên viết nó bằng ngôn ngữ máy (lắp ráp).

Về vấn đề này, OOP tạo điều kiện cho việc triển khai, kiểm tra và hoàn thiện thuật toán của chúng tôi trên máy tính và viết nó cho máy tính bằng ngôn ngữ gần với ngôn ngữ tự nhiên của chúng tôi.