Quan điểm của OOP là gì?

Theo như tôi có thể nói, mặc dù có vô số hàng triệu hoặc hàng tỷ chi cho giáo dục, ngôn ngữ và công cụ OOP, OOP đã không cải thiện năng suất của nhà phát triển hoặc độ tin cậy của phần mềm, cũng như không giảm chi phí phát triển. Rất ít người sử dụng OOP theo bất kỳ ý nghĩa nghiêm ngặt nào (ít người tuân thủ hoặc hiểu các nguyên tắc như LSP); dường như có rất ít sự đồng nhất hoặc nhất quán đối với các phương pháp mà mọi người thực hiện để mô hình hóa các lĩnh vực vấn đề. Tất cả quá thường xuyên, lớp được sử dụng đơn giản cho đường cú pháp của nó; nó đặt các hàm cho một loại bản ghi vào không gian tên nhỏ của riêng chúng.

Tôi đã viết một số lượng lớn mã cho nhiều ứng dụng. Mặc dù đã có những nơi mà phân nhóm thay thế thực sự đóng một vai trò có giá trị trong ứng dụng, những thứ này khá đặc biệt. Nói chung, mặc dù nhiều dịch vụ môi được đưa ra để nói về "tái sử dụng" nhưng thực tế là trừ khi một đoạn mã thực hiện chính xác những gì bạn muốn nó làm, có rất ít "sử dụng lại" hiệu quả về chi phí. Thật khó để thiết kế các lớp có thể mở rộng theo đúng cách , và vì vậy chi phí gia hạn thường rất lớn đến mức "sử dụng lại" đơn giản là không đáng giá.

Về nhiều mặt, điều này không làm tôi ngạc nhiên. Thế giới thực không phải là "OO", và ý tưởng tiềm ẩn trong OO - rằng chúng ta có thể mô hình hóa mọi thứ với một số phân loại giai cấp - dường như tôi rất thiếu sót (tôi có thể ngồi trên bàn, gốc cây, nắp ca-pô xe hơi , vạt áo của ai đó - nhưng không phải một trong số đó là - một cái ghế). Ngay cả khi chúng ta chuyển sang các miền trừu tượng hơn, mô hình OO thường khó khăn, phản trực giác và cuối cùng không có ích (hãy xem xét các ví dụ cổ điển về hình tròn / hình elip hoặc hình vuông / hình chữ nhật).

Vậy tôi còn thiếu gì ở đây? Giá trị của OOP ở đâu và tại sao tất cả thời gian và tiền bạc không làm cho phần mềm trở nên tốt hơn?

Không có bằng chứng thực nghiệm cho thấy rằng định hướng đối tượng là một cách tự nhiên hơn để mọi người nghĩ về thế giới. Có một số công việc trong lĩnh vực tâm lý học lập trình cho thấy OO không phù hợp bằng cách nào đó hơn các phương pháp khác.

Các biểu diễn hướng đối tượng dường như không thể sử dụng phổ biến hơn hoặc ít sử dụng hơn.

Chỉ áp dụng các phương pháp OO là không đủ và yêu cầu các nhà phát triển sử dụng các phương pháp đó, bởi vì điều đó có thể có tác động tiêu cực đến năng suất của nhà phát triển, cũng như chất lượng của các hệ thống được phát triển.

Đó là từ "Về khả năng sử dụng của các đại diện OO" từ Truyền thông của ACM tháng 10 năm 2000. Các bài viết chủ yếu so sánh OO với phương pháp tiếp cận theo quy trình. Có rất nhiều nghiên cứu về cách những người làm việc với phương pháp OO "nghĩ" (Int. J. of Human-Computer Studies 2001, số 54, hay Tương tác giữa người và máy tính 1995, tập 10 có toàn bộ chủ đề về nghiên cứu OO), và từ những gì tôi đọc được, không có gì để chỉ ra một cách tự nhiên nào đó đối với phương pháp OO khiến nó phù hợp hơn phương pháp thủ tục truyền thống hơn.

Thế giới thực không phải là "OO", và ý tưởng tiềm ẩn trong OO - rằng chúng ta có thể mô hình hóa mọi thứ với một số phân loại giai cấp - đối với tôi rất thiếu sót về cơ bản

Trong khi điều này là đúng và đã được quan sát bởi những người khác (lấy Stepanov, người phát minh ra STL), phần còn lại là vô nghĩa. OOP có thể là thiếu sót và chắc chắn nó không phải là viên đạn bạc nhưng nó làm cho các ứng dụng quy mô lớn trở nên đơn giản hơn nhiều vì đó là một cách tuyệt vời để giảm sự phụ thuộc. Tất nhiên, điều này chỉ đúng với thiết kế của OOP tốt. Thiết kế cẩu thả sẽ không cho bất kỳ lợi thế. Nhưng thiết kế tách rời tốt có thể được mô hình hóa rất tốt bằng OOP và không sử dụng tốt các kỹ thuật khác.

Có nhiều mô hình tốt hơn, phổ quát hơn ( mô hình kiểu của Haskell xuất hiện trong tâm trí) nhưng chúng cũng thường phức tạp hơn và / hoặc khó thực hiện một cách hiệu quả. OOP là một sự đánh đổi tốt giữa các thái cực.

OOP không phải là về việc tạo các lớp có thể sử dụng lại, mà là về việc tạo các lớp có thể sử dụng được.

Tất cả quá thường xuyên, lớp được sử dụng đơn giản cho đường cú pháp của nó; nó đặt các hàm cho một loại bản ghi vào không gian tên nhỏ của riêng chúng.

Vâng, tôi thấy điều này là quá phổ biến là tốt. Đây không phải là lập trình hướng đối tượng. Đó là lập trình dựa trên đối tượng và lập trình tập trung vào dữ liệu. Trong 10 năm làm việc với OO Languages, tôi thấy mọi người chủ yếu làm Lập trình dựa trên đối tượng. OBP phá vỡ rất nhanh IMHO vì về cơ bản bạn đang mắc phải cả hai từ tệ nhất: 1) Lập trình theo thủ tục mà không tuân thủ phương pháp lập trình có cấu trúc đã được chứng minh và 2) OOP mà không tuân thủ phương pháp OOP đã được chứng minh.

OOP thực hiện đúng là một điều đẹp. Nó làm cho các vấn đề rất khó trở nên dễ dàng để giải quyết, và đối với người không quen biết (không cố gắng tỏ ra hào hoa ở đó), nó gần như có thể giống như phép thuật. Điều đó đang được nói, OOP chỉ là một công cụ trong hộp công cụ của các phương pháp lập trình. Nó không phải là tất cả kết thúc tất cả các phương pháp. Nó chỉ xảy ra để phù hợp với các ứng dụng kinh doanh lớn.

Hầu hết các nhà phát triển làm việc trong các ngôn ngữ OOP đang sử dụng các ví dụ về OOP được thực hiện ngay trong các khung và loại mà họ sử dụng hàng ngày, nhưng họ không biết về nó. Dưới đây là một số ví dụ rất đơn giản: ADO.NET, Hibernate / NHibernate, Logging Frameworks, các loại bộ sưu tập ngôn ngữ khác nhau, ngăn xếp ASP.NET, ngăn xếp JSP, v.v ... Đây là tất cả những thứ chủ yếu dựa vào OOP trong các cơ sở mã của chúng.

Tái sử dụng không nên là mục tiêu của OOP - hoặc bất kỳ mô hình nào khác cho vấn đề đó.

Tái sử dụng là một tác dụng phụ của một thiết kế tốt và mức độ trừu tượng thích hợp. Mã đạt được tái sử dụng bằng cách làm một cái gì đó hữu ích, nhưng không làm quá nhiều để làm cho nó không linh hoạt. Việc mã đó có phải là OO hay không - chúng tôi sử dụng lại những gì hoạt động và không quan trọng để tự làm. Đó là chủ nghĩa thực dụng.

Ý nghĩ về OO như một cách mới để sử dụng lại thông qua thừa kế về cơ bản là thiếu sót. Như bạn lưu ý các vi phạm LSP rất nhiều. Thay vào đó, OO được coi là một phương pháp quản lý sự phức tạp của một miền có vấn đề. Mục tiêu là khả năng duy trì của một hệ thống theo thời gian. Công cụ chính để đạt được điều này là tách giao diện công cộng khỏi một triển khai riêng. Điều này cho phép chúng tôi có các quy tắc như "Điều này chỉ nên được sửa đổi bằng cách sử dụng ..." được thực thi bởi trình biên dịch, thay vì xem lại mã.

Sử dụng điều này, tôi chắc chắn bạn sẽ đồng ý, cho phép chúng tôi tạo và duy trì các hệ thống cực kỳ phức tạp. Có rất nhiều giá trị trong đó, và không dễ để thực hiện trong các mô hình khác.

Verging về tôn giáo nhưng tôi sẽ nói rằng bạn đang vẽ một bức tranh quá nghiệt ngã về tình trạng của OOP hiện đại. Tôi sẽ lập luận rằng nó thực sự đã giảm chi phí, làm cho các dự án phần mềm lớn có thể quản lý được, v.v. Điều đó không có nghĩa là nó đã giải quyết được vấn đề cơ bản của sự lộn xộn phần mềm và điều đó không có nghĩa là nhà phát triển trung bình là một chuyên gia OOP. Nhưng việc mô đun hóa chức năng thành các thành phần đối tượng chắc chắn đã làm giảm số lượng mã spaghetti trên thế giới.

Tôi có thể nghĩ ra hàng tá thư viện trên đỉnh đầu có thể tái sử dụng đẹp mắt và tiết kiệm thời gian và tiền bạc không bao giờ có thể tính được.

Nhưng đến mức OOP đã lãng phí thời gian, tôi nói rằng đó là do thiếu đào tạo lập trình viên, kết hợp với đường cong học tập dốc của việc học lập bản đồ OOP ngôn ngữ cụ thể. Một số người "có được" OOP và những người khác sẽ không bao giờ.

Tôi nghĩ rằng việc sử dụng các đối tượng bối cảnh mờ đục (HANDLEs trong Win32, FILE * s trong C, để đặt tên cho hai ví dụ nổi tiếng - địa ngục, HandLE sống ở phía bên kia của hàng rào chế độ kernel, và nó thực sự không nhận được đóng gói nhiều hơn thế) cũng được tìm thấy trong mã thủ tục; Tôi đang đấu tranh để xem làm thế nào đây là một cái gì đó đặc biệt đối với OOP.

HANDLEs (và phần còn lại của WinAPI) là OOP! C không hỗ trợ OOP rất tốt nên không có cú pháp đặc biệt nhưng điều đó không có nghĩa là nó không sử dụng các khái niệm tương tự. WinAPI theo mọi nghĩa của từ này là một khung hướng đối tượng.

Hãy xem, đây là rắc rối với mọi cuộc thảo luận liên quan đến OOP hoặc các kỹ thuật thay thế: không ai rõ về định nghĩa, mọi người đều nói về điều gì khác và do đó không thể đạt được sự đồng thuận. Có vẻ như một sự lãng phí thời gian cho tôi.

Đây là một mô hình lập trình .. Được thiết kế để giúp chúng ta dễ dàng hơn để chia nhỏ vấn đề thành các phần nhỏ hơn, có thể thực hiện được ..

Nếu bạn không thấy nó hữu ích .. Đừng sử dụng nó, đừng trả tiền cho việc đào tạo và hãy hạnh phúc.

Mặt khác, tôi thấy nó hữu ích, vì vậy tôi sẽ :)

Liên quan đến lập trình thủ tục thẳng, nguyên lý cơ bản đầu tiên của OOP là khái niệm về ẩn và đóng gói thông tin. Ý tưởng này dẫn đến khái niệm lớp tách biệt giao diện khỏi việc thực hiện. Đây là những khái niệm cực kỳ quan trọng và là cơ sở để đưa ra một khuôn khổ để suy nghĩ về thiết kế chương trình theo một cách khác và tốt hơn (tôi nghĩ). Bạn thực sự không thể tranh cãi với những tài sản đó - không có sự đánh đổi nào được thực hiện và nó luôn là một cách sạch hơn để điều chỉnh mọi thứ.

Các khía cạnh khác của OOP bao gồm thừa kế và đa hình cũng rất quan trọng, nhưng như những khía cạnh khác đã ám chỉ, những thứ đó thường được sử dụng quá mức. tức là: Đôi khi mọi người sử dụng tính kế thừa và / hoặc đa hình vì họ có thể chứ không phải vì họ nên có. Chúng là những khái niệm mạnh mẽ và rất hữu ích, nhưng cần được sử dụng một cách khôn ngoan và không phải là lợi thế chiến thắng tự động của OOP.

Liên quan đến việc sử dụng lại. Tôi đồng ý sử dụng lại được bán cho OOP. Đó là một tác dụng phụ có thể có của các đối tượng được xác định rõ, điển hình là các lớp nguyên thủy / chung hơn và là kết quả trực tiếp của các khái niệm ẩn và đóng gói thông tin. Nó có khả năng dễ dàng hơn để được sử dụng lại bởi vì các giao diện của các lớp được xác định rõ chỉ đơn giản là rõ ràng hơn và phần nào tự ghi lại.

Vấn đề với OOP là nó đã được bán quá mức.

Như Alan Kay ban đầu quan niệm, nó là một sự thay thế tuyệt vời cho thực tiễn trước đây là có dữ liệu thô và các thói quen toàn cầu.

Sau đó, một số loại tư vấn quản lý đã bám lấy nó và bán nó như là mớ hỗn độn của phần mềm, và giống như học thuật và ngành công nghiệp lem luốc theo sau nó.

Bây giờ họ đang lúng túng giống như sụt giảm sau khi các ý tưởng tốt khác bị bán quá mức, chẳng hạn như lập trình chức năng.

Vậy tôi sẽ làm gì khác đi? Rất nhiều, và tôi đã viết một cuốn sách về điều này. (Nó không còn xuất bản - Tôi không nhận được một xu, nhưng bạn vẫn có thể nhận được các bản sao.) Amazon

Câu trả lời mang tính xây dựng của tôi là xem lập trình không phải là một cách mô hình hóa mọi thứ trong thế giới thực, mà là một cách yêu cầu mã hóa.

Điều đó rất khác nhau, và dựa trên lý thuyết thông tin (ở mức độ mà bất cứ ai cũng có thể hiểu). Nó nói rằng lập trình có thể được xem như là một quá trình xác định ngôn ngữ và kỹ năng làm việc đó là điều cần thiết để lập trình tốt.

Nó nâng cao khái niệm về ngôn ngữ dành riêng cho miền (DSL). Nó đồng ý rõ ràng với DRY (đừng lặp lại chính mình). Nó cung cấp cho một ngón tay cái lớn để tạo mã. Nó dẫn đến phần mềm có cấu trúc dữ liệu ồ ạt hơn so với điển hình cho các ứng dụng hiện đại.

Nó tìm cách tiếp thêm sinh lực cho ý tưởng rằng con đường phía trước nằm ở tính sáng tạo và thậm chí những ý tưởng được chấp nhận tốt cũng nên được đặt câu hỏi.

Tay cầm (và phần còn lại của WinAPI) là OOP!

Có phải họ, mặc dù? Chúng không được thừa kế, chúng chắc chắn không thể thay thế, chúng thiếu các lớp được xác định rõ ... Tôi nghĩ rằng chúng không vượt quá "OOP".

Bạn đã bao giờ tạo một cửa sổ bằng WinAPI chưa? Sau đó, bạn nên biết rằng bạn định nghĩa một lớp ( RegisterClass), tạo một thể hiện của nó ( CreateWindow), gọi các phương thức ảo ( WndProc) và phương thức lớp cơ sở ( DefWindowProc), v.v. WinAPI thậm chí còn lấy danh pháp từ SmallTalk OOP, gọi các phương thức là tin nhắn trên mạng (Tin nhắn trên cửa sổ).

Xử lý có thể không được kế thừa nhưng sau đó, có finaltrong Java. Họ không thiếu một lớp học, họ là một người giữ chỗ cho lớp học: Đó là những gì mà từ từ xử lý có nghĩa là. Nhìn vào các kiến ​​trúc như MFC hoặc .NET WinForms, rõ ràng là ngoại trừ cú pháp, không có gì khác biệt so với WinAPI.

Có OOP đã không giải quyết tất cả các vấn đề của chúng tôi, xin lỗi về điều đó. Tuy nhiên, chúng tôi đang làm việc trên SOA sẽ giải quyết tất cả những vấn đề đó.

OOP cho vay rất tốt để lập trình các cấu trúc máy tính bên trong như "widget" GUI, ví dụ như SelectList và TextBox có thể là các kiểu con của Item, có các phương thức phổ biến như "di chuyển" và "thay đổi kích thước".

Vấn đề là, 90% chúng ta làm việc trong thế giới kinh doanh nơi chúng ta đang làm việc với các khái niệm kinh doanh như Hóa đơn, Nhân viên, Công việc, Đặt hàng. Những người này không cho vay rất tốt cho OOP bởi vì các "đối tượng" thì mơ hồ hơn, có thể thay đổi theo kỹ thuật tái cấu trúc doanh nghiệp, v.v.

Trường hợp xấu nhất là OO được áp dụng nhiệt tình vào cơ sở dữ liệu, bao gồm cả "cải tiến" OO nghiêm trọng cho cơ sở dữ liệu SQL - vốn bị bỏ qua một cách chính xác trừ các cơ sở dữ liệu cho rằng chúng phải là cách đúng đắn để làm mọi thứ vì chúng mới hơn.

Theo kinh nghiệm của tôi về việc xem xét mã và thiết kế các dự án tôi đã trải qua, giá trị của OOP không được nhận ra đầy đủ vì rất nhiều nhà phát triển đã không khái niệm đúng về mô hình hướng đối tượng trong tâm trí của họ. Do đó, họ không lập trình với thiết kế OO, rất thường xuyên tiếp tục viết mã thủ tục từ trên xuống làm cho các lớp có thiết kế phẳng khá đẹp . (nếu bạn thậm chí có thể gọi "thiết kế" đó ở vị trí đầu tiên)

Thật đáng sợ khi quan sát cách các đồng nghiệp nhỏ biết về một lớp hoặc giao diện trừu tượng là gì, hãy để một mình thiết kế một hệ thống phân cấp thừa kế phù hợp với nhu cầu kinh doanh.

Tuy nhiên, khi có thiết kế OO tốt, đó chỉ là niềm vui khi đọc mã và thấy mã tự nhiên rơi vào vị trí / thành phần trực quan. Tôi luôn cảm nhận kiến ​​trúc và thiết kế hệ thống như thiết kế các bộ phận và công việc nhân viên khác nhau trong một công ty - tất cả đều ở đó để hoàn thành một công việc nhất định trong sơ đồ lớn, phát ra sức mạnh tổng hợp cần thiết để thúc đẩy tổ chức / hệ thống tiến lên.

Điều đó, tất nhiên, khá hiếm khi không may. Giống như tỷ lệ của các đối tượng vật lý được thiết kế đẹp so với thiết kế khủng khiếp trên thế giới, điều tương tự cũng có thể nói về kỹ thuật và thiết kế phần mềm. Có các công cụ tốt theo ý của một người không nhất thiết mang lại kết quả và thực hành tốt.

Có thể nắp ca-pô, vạt áo hoặc cây không phải là ghế nhưng tất cả chúng đều có thể điều khiển được.

Tôi nghĩ những thứ trong thế giới thực là đồ vật

Bạn làm?

Hóa đơn có những phương pháp nào? Oh, đợi đã. Nó không thể tự trả tiền, nó không thể tự gửi, nó không thể tự so sánh với các mặt hàng mà nhà cung cấp thực sự giao. Nó không có bất kỳ phương pháp nào cả; nó hoàn toàn trơ và không hoạt động. Đó là một loại bản ghi (một cấu trúc, nếu bạn thích), không phải là một đối tượng.

Tương tự như vậy, những điều khác mà bạn đề cập.

Chỉ vì một cái gì đó có thật không làm cho nó trở thành một đối tượng theo nghĩa OO của từ này. Các đối tượng OO là một sự kết hợp đặc biệt giữa trạng thái và hành vi có thể hành động theo ý mình. Đó không phải là thứ gì đó phong phú trong thế giới thực.

Tôi đã viết mã OO trong 9 năm qua hoặc lâu hơn. Ngoài việc sử dụng tin nhắn, tôi khó có thể tưởng tượng ra cách tiếp cận khác. Lợi ích chính mà tôi thấy hoàn toàn phù hợp với những gì CodingTheWheel đã nói: mô đun hóa. OO tự nhiên dẫn tôi xây dựng các ứng dụng của mình từ các thành phần mô-đun có giao diện rõ ràng và trách nhiệm rõ ràng (nghĩa là mã được liên kết lỏng lẻo, có tính gắn kết cao với sự phân tách rõ ràng các mối quan tâm).

Tôi nghĩ nơi OO tan vỡ là khi mọi người tạo ra những người thừa kế giai cấp lồng nhau sâu sắc. Điều này có thể dẫn đến sự phức tạp. Tuy nhiên, bao gồm sự khác biệt chung vào một lớp cơ sở, sau đó sử dụng lại rằng trong các lớp con cháu khác là một điều rất tao nhã, IMHO!

Ở nơi đầu tiên, các quan sát có phần cẩu thả. Tôi không có bất kỳ số liệu nào về năng suất phần mềm và không có lý do chính đáng để tin rằng nó sẽ không tăng. Hơn nữa, vì có nhiều người lạm dụng OO, sử dụng tốt OO sẽ không nhất thiết gây ra sự cải thiện năng suất ngay cả khi OO là điều tuyệt vời nhất kể từ bơ đậu phộng. Rốt cuộc, một bác sĩ phẫu thuật não bất tài có khả năng tồi tệ hơn bất kỳ ai, nhưng một người có năng lực có thể là vô giá.

Điều đó đang được nói, OO là một cách sắp xếp khác nhau, gắn mã thủ tục vào dữ liệu thay vì có mã thủ tục hoạt động trên dữ liệu. Điều này nên có ít nhất một chiến thắng nhỏ của chính nó, vì có những trường hợp cách tiếp cận OO là tự nhiên hơn. Rốt cuộc, không có gì ngăn cản bất cứ ai viết API thủ tục trong C ++, và do đó, tùy chọn cung cấp các đối tượng thay vào đó làm cho ngôn ngữ trở nên linh hoạt hơn.

Hơn nữa, có một cái gì đó OO làm rất tốt: nó cho phép mã cũ tự động gọi mã mới, không có thay đổi. Nếu tôi có mã quản lý mọi thứ theo thủ tục và tôi thêm một loại mới tương tự nhưng không giống với mã trước đó, tôi phải thay đổi mã thủ tục. Trong một hệ thống OO, tôi kế thừa chức năng, thay đổi những gì tôi thích và mã mới được tự động sử dụng do tính đa hình. Điều này làm tăng tính cục bộ của các thay đổi và đó là một điều tốt.

Nhược điểm là OO tốt không miễn phí: nó đòi hỏi thời gian và công sức để học nó đúng cách. Vì đó là một từ thông dụng lớn, có rất nhiều người và sản phẩm làm điều đó rất tệ, chỉ vì lợi ích của việc đó. Thiết kế giao diện lớp tốt không dễ hơn API thủ tục tốt và có tất cả các loại lỗi dễ mắc (như phân cấp lớp sâu).

Hãy nghĩ về nó như một loại công cụ khác nhau, không nhất thiết phải nói chung là tốt hơn. Một cái búa ngoài một cái tuốc nơ vít, nói. Có lẽ cuối cùng chúng ta sẽ thoát ra khỏi thực tiễn của công nghệ phần mềm khi biết nên sử dụng cờ lê nào để vặn ốc vít.

@Sean

Tuy nhiên, bao gồm sự khác biệt chung vào một lớp cơ sở, sau đó sử dụng lại rằng trong các lớp con cháu khác là một điều rất tao nhã, IMHO!

Nhưng các nhà phát triển "thủ tục" đã làm điều đó trong nhiều thập kỷ. Cú pháp và thuật ngữ có thể khác nhau, nhưng hiệu quả là giống hệt nhau. Có nhiều điều với OOP hơn là "tái sử dụng chức năng phổ biến trong một lớp cơ sở", và tôi thậm chí có thể đi xa đến mức nói rằng điều đó thật khó để mô tả là OOP; gọi cùng một hàm từ các bit mã khác nhau là một kỹ thuật cũ như chính bản chất phụ.

@Konrad

OOP có thể là thiếu sót và chắc chắn nó không phải là viên đạn bạc nhưng nó làm cho các ứng dụng quy mô lớn trở nên đơn giản hơn nhiều vì đó là một cách tuyệt vời để giảm sự phụ thuộc

Đó là giáo điều. Tôi không thấy những gì làm cho OOP tốt hơn đáng kể về vấn đề này so với lập trình thủ tục cũ. Bất cứ khi nào tôi thực hiện một cuộc gọi thủ tục, tôi đều tự cô lập bản thân khỏi các chi tiết cụ thể của việc thực hiện.

Đối với tôi, có rất nhiều giá trị trong chính cú pháp OOP. Sử dụng các đối tượng cố gắng biểu diễn các vật thật hoặc cấu trúc dữ liệu thường hữu ích hơn nhiều so với cố gắng sử dụng một loạt các hàm phẳng (hoặc "nổi" khác nhau) để làm cùng một thứ với cùng một dữ liệu. Có một "dòng chảy" tự nhiên nhất định đến những thứ có OOP tốt, giúp đọc, viết và duy trì lâu dài có ý nghĩa hơn.

Không nhất thiết là Hóa đơn không thực sự là một "đối tượng" với các chức năng mà nó có thể tự thực hiện - đối tượng có thể tồn tại chỉ để thực hiện các chức năng trên dữ liệu mà không cần phải biết loại dữ liệu nào thực sự ở đó. Hàm "billing.toJson ()" có thể được gọi thành công mà không cần phải biết "hóa đơn" loại dữ liệu nào - kết quả sẽ là Json, bất kể nó đến từ cơ sở dữ liệu, XML, CSV hay thậm chí là một đối tượng JSON khác . Với các chức năng thủ tục, bạn đột nhiên phải biết nhiều hơn về dữ liệu của mình và kết thúc với các chức năng như "xmlToJson ()", "csvToJson ()", "dbToJson ()", v.v ... Cuối cùng nó trở thành một mớ hỗn độn và một Đau đầu nếu bạn thay đổi kiểu dữ liệu cơ bản.

Quan điểm của OOP là che giấu việc thực hiện thực tế bằng cách trừu tượng hóa nó đi. Để đạt được mục tiêu đó, bạn phải tạo giao diện chung. Để làm cho công việc của bạn dễ dàng hơn trong khi tạo giao diện công cộng đó và giữ mọi thứ DRY, bạn phải sử dụng các khái niệm như các lớp trừu tượng, kế thừa, đa hình và các mẫu thiết kế.

Vì vậy, với tôi, mục tiêu vượt trội của OOP là làm cho việc bảo trì mã trong tương lai và thay đổi dễ dàng hơn. Nhưng thậm chí vượt xa điều đó, nó thực sự có thể đơn giản hóa mọi thứ rất nhiều khi được thực hiện chính xác theo những cách mà mã thủ tục không bao giờ có thể. Sẽ không có vấn đề gì nếu nó không khớp với "thế giới thực" - lập trình với mã không tương tác với các đối tượng trong thế giới thực. OOP chỉ là một công cụ giúp công việc của tôi trở nên dễ dàng và nhanh chóng hơn - tôi sẽ thực hiện điều đó bất cứ ngày nào.

@CodingTheWheel

Nhưng đến mức OOP đã lãng phí thời gian, tôi nói rằng đó là do thiếu đào tạo lập trình viên, kết hợp với đường cong học tập dốc của việc học lập bản đồ OOP ngôn ngữ cụ thể. Một số người "có được" OOP và những người khác sẽ không bao giờ.

Tôi không biết nếu điều đó thực sự đáng ngạc nhiên, mặc dù. Tôi nghĩ rằng các cách tiếp cận âm thanh về mặt kỹ thuật (LSP là điều hiển nhiên) khó sử dụng , nhưng nếu chúng ta không sử dụng các cách tiếp cận như vậy thì nó sẽ khiến mã trở nên giòn và không thể hiểu được (vì chúng ta không còn có thể suy luận về nó nữa). Và tôi nghĩ rằng kết quả trái ngược mà OOP đưa ra khiến chúng ta không ngạc nhiên khi mọi người không nhận nó.

Quan trọng hơn, vì phần mềm về cơ bản quá khó để người bình thường có thể viết một cách đáng tin cậy và chính xác, chúng ta có nên thực sự đưa ra một kỹ thuật luôn được dạy kém và có vẻ khó học? Nếu lợi ích rõ ràng thì có thể đáng để kiên trì mặc dù gặp khó khăn, nhưng dường như đó không phải là trường hợp.

@Jeff

Liên quan đến lập trình thủ tục thẳng, nguyên lý cơ bản đầu tiên của OOP là khái niệm về ẩn và đóng gói thông tin. Ý tưởng này dẫn đến khái niệm lớp tách biệt giao diện khỏi việc thực hiện.

Cái nào có triển khai ẩn hơn: iostreams của C ++, hay FILE * của C?

Tôi nghĩ rằng việc sử dụng các đối tượng bối cảnh mờ đục (HANDLEs trong Win32, FILE * s trong C, để đặt tên cho hai ví dụ nổi tiếng - địa ngục, HandLE sống ở phía bên kia của hàng rào chế độ kernel, và nó thực sự không nhận được đóng gói nhiều hơn thế) cũng được tìm thấy trong mã thủ tục; Tôi đang đấu tranh để xem làm thế nào đây là một cái gì đó đặc biệt đối với OOP.

Tôi cho rằng đó có thể là một phần lý do tại sao tôi đấu tranh để thấy các lợi ích: các phần rõ ràng không tốt cho OOP, trong khi các phần dành riêng cho OOP rõ ràng không tốt! (điều này không có nghĩa là chúng thực sự xấu, mà là tôi chưa thấy bằng chứng cho thấy chúng có thể áp dụng rộng rãi và luôn có lợi).

Trong blog dev duy nhất tôi đọc, bởi anh chàng Joel-On-Software-Founder-of-SO, tôi đã đọc cách đây rất lâu rằng OO không dẫn đến tăng năng suất. Quản lý bộ nhớ tự động nào. Mát mẻ. Ai có thể từ chối dữ liệu?

Tôi vẫn tin rằng OO không phải là OO, lập trình với các chức năng là lập trình mọi thứ nội tuyến.

(Và tôi nên biết, khi tôi bắt đầu với GWBasic.) Khi bạn cấu trúc lại mã để sử dụng các hàm, variable2654trở thành variable3phương thức bạn tham gia. Hoặc, tốt hơn, nó có một tên mà bạn có thể hiểu và nếu hàm đó ngắn , nó được gọi value và đó là đủ để hiểu đầy đủ.

Khi mã không có chức năng trở thành mã với phương pháp này, bạn có thể xóa dặm mã.

Khi bạn refactor code để thực sự OO, b, c, q, và Ztrở thành this, this, thisvà this. Và kể từ khi tôi không tin trong việc sử dụng thistừ khóa, bạn có thể dặm xóa mã. Trên thực tế, bạn có thể làm điều đó ngay cả khi bạn sử dụng this.

Tôi không nghĩ OO là phép ẩn dụ tự nhiên.

Tôi cũng không nghĩ ngôn ngữ là một phép ẩn dụ tự nhiên, tôi cũng không nghĩ rằng "mùi" của Fowler tốt hơn là nói "mã này có vị rất tệ". Điều đó nói rằng, tôi nghĩ rằng OO không phải là về ẩn dụ tự nhiên và những người nghĩ rằng các vật thể bật ra về cơ bản là bạn đang thiếu điểm. Bạn xác định vũ trụ đối tượng và vũ trụ đối tượng tốt hơn dẫn đến mã ngắn hơn, dễ hiểu hơn, hoạt động tốt hơn hoặc tất cả những điều này (và một số tiêu chí tôi đang quên). Tôi nghĩ rằng những người sử dụng các đối tượng tự nhiên của khách hàng / miền làm đối tượng lập trình đang thiếu sức mạnh để xác định lại vũ trụ.

Ví dụ, khi bạn thực hiện một hệ thống đặt chỗ của hãng hàng không, những gì bạn gọi là đặt chỗ có thể không tương ứng với đặt chỗ hợp pháp / kinh doanh.

Một số khái niệm cơ bản là những công cụ thực sự tuyệt vời

Tôi nghĩ rằng hầu hết mọi người đều phóng đại với toàn bộ điều đó "khi bạn có một cái búa, tất cả đều là đinh". Tôi nghĩ rằng mặt khác của đồng xu / gương là đúng như vậy: khi bạn có một tiện ích như đa hình / kế thừa, bạn bắt đầu tìm cách sử dụng ở nơi nó phù hợp như găng tay / vớ / kính áp tròng. Các công cụ của OO rất mạnh mẽ. Kế thừa đơn là, tôi nghĩ, hoàn toàn cần thiết để mọi người không bị mang đi, phần mềm đa thừa kế của riêng tôi không chịu được.

Quan điểm của OOP là gì?

Tôi nghĩ rằng đó là một cách tuyệt vời để xử lý một cơ sở mã hoàn toàn lớn. Tôi nghĩ rằng nó cho phép bạn tổ chức và sắp xếp lại mã của bạn và cung cấp cho bạn một ngôn ngữ để thực hiện điều đó (ngoài ngôn ngữ lập trình bạn đang làm việc) và mô đun hóa mã theo cách khá tự nhiên và dễ hiểu.

OOP bị hiểu lầm bởi phần lớn các nhà phát triển

Điều này là do đó là một quá trình mở mắt như cuộc sống: bạn hiểu OO ngày càng nhiều bằng kinh nghiệm và bắt đầu tránh một số mô hình nhất định và sử dụng người khác khi bạn khôn ngoan hơn. Một trong những ví dụ tốt nhất là bạn ngừng sử dụng tính kế thừa cho các lớp mà bạn không kiểm soát và thay vào đó thích mẫu Mặt tiền .

Về bài tiểu luận / câu hỏi của bạn

Tôi đã muốn đề cập rằng bạn đúng. Tái sử dụng là một giấc mơ ống, đối với hầu hết các phần. Dưới đây là một trích dẫn của Anders Hejilsberg về chủ đề đó (xuất sắc) từ đây :

Nếu bạn yêu cầu các lập trình viên mới bắt đầu viết điều khiển lịch, họ thường tự nghĩ: "Ồ, tôi sẽ viết điều khiển lịch tốt nhất thế giới! Nó sẽ là đa hình đối với loại lịch. Nó sẽ có màn hình hiển thị, và mungers, và cái này, cái kia, và cái kia. " Họ cần gửi một ứng dụng lịch trong hai tháng. Họ đặt tất cả cơ sở hạ tầng này vào vị trí kiểm soát, và sau đó dành hai ngày để viết một ứng dụng lịch tào lao lên trên nó. Họ sẽ nghĩ, "Trong phiên bản tiếp theo của ứng dụng, tôi sẽ làm nhiều hơn thế nữa."

Tuy nhiên, một khi họ bắt đầu nghĩ về cách họ thực sự sẽ thực hiện tất cả những sự cụ thể hóa khác trong thiết kế trừu tượng của họ, thì hóa ra thiết kế của họ hoàn toàn sai. Và bây giờ họ đã tự vẽ mình vào một góc, và họ phải ném toàn bộ ra ngoài. Tôi đã thấy điều đó nhiều lần. Tôi là một người tin tưởng mạnh mẽ vào sự tối giản. Trừ khi bạn thực sự sẽ giải quyết vấn đề chung, đừng thử và đặt một khung để giải quyết một vấn đề cụ thể, bởi vì bạn không biết khung đó sẽ như thế nào.

Bạn đã bao giờ tạo một cửa sổ bằng WinAPI chưa?

Nhiều lần hơn tôi quan tâm để nhớ.

Sau đó, bạn nên biết rằng bạn định nghĩa một lớp (RegisterClass), tạo một thể hiện của nó (CreateWindow), gọi các phương thức ảo (WndProc) và các phương thức lớp cơ sở (DefWindowProc), v.v. WinAPI thậm chí còn lấy danh pháp từ SmallTalk OOP, gọi các phương thức là tin nhắn trên mạng (Tin nhắn trên cửa sổ).

Sau đó, bạn cũng sẽ biết rằng nó không gửi tin nhắn của riêng mình, đó là một khoảng trống lớn. Nó cũng có phân lớp crappy.

Xử lý có thể không được kế thừa nhưng sau đó, có cuối cùng trong Java. Họ không thiếu một lớp học, họ là một người giữ chỗ cho lớp học: Đó là những gì mà từ từ xử lý có nghĩa là. Nhìn vào các kiến ​​trúc như MFC hoặc .NET WinForms, rõ ràng là ngoại trừ cú pháp, không có gì khác biệt so với WinAPI.

Chúng không thể kế thừa cả về giao diện hoặc cách triển khai, có thể thay thế tối thiểu và chúng không khác biệt đáng kể so với những gì các lập trình viên thủ tục đã làm mãi mãi.

Đây thực sự là nó? Các bit tốt nhất của OOP chỉ là ... mã thủ tục truyền thống? Đó là vấn đề lớn?

Tôi hoàn toàn đồng ý với câu trả lời của InSciTek Jeff , tôi sẽ chỉ thêm các sàng lọc sau:

• Ẩn thông tin và đóng gói: Quan trọng đối với bất kỳ mã duy trì nào. Có thể được thực hiện bằng cách cẩn thận trong bất kỳ ngôn ngữ lập trình nào, không yêu cầu các tính năng OO, nhưng thực hiện nó sẽ làm cho mã của bạn hơi giống OO.
• Kế thừa: Có một miền ứng dụng quan trọng mà tất cả các mối quan hệ OO đó là một loại và chứa các mối quan hệ đều phù hợp hoàn hảo: Giao diện người dùng đồ họa. Nếu bạn cố gắng xây dựng GUI mà không có hỗ trợ ngôn ngữ OO, cuối cùng bạn sẽ xây dựng các tính năng giống như OO, và nó khó hơn và dễ bị lỗi hơn nếu không có hỗ trợ ngôn ngữ. Glade (gần đây) và X11 Xt (trong lịch sử) chẳng hạn.

Sử dụng các tính năng OO (đặc biệt là phân cấp trừu tượng lồng nhau sâu sắc), khi không có điểm, là vô nghĩa. Nhưng đối với một số lĩnh vực ứng dụng, thực sự có một điểm.

Tôi tin rằng chất lượng có lợi nhất của OOP là ẩn / quản lý dữ liệu. Tuy nhiên, có rất nhiều ví dụ về việc OOP bị sử dụng sai và tôi nghĩ đây là lúc sự nhầm lẫn xuất hiện.

Chỉ vì bạn có thể biến thứ gì đó thành đối tượng không có nghĩa là bạn nên làm. Tuy nhiên, nếu làm như vậy sẽ làm cho mã của bạn có tổ chức hơn / dễ đọc hơn thì bạn chắc chắn nên làm.

Một ví dụ thực tế tuyệt vời mà OOP rất hữu ích là với lớp "sản phẩm" và các đối tượng mà tôi sử dụng trên trang web của chúng tôi. Vì mỗi trang là một sản phẩm và mọi sản phẩm đều có tham chiếu đến các sản phẩm khác, nên có thể rất khó hiểu về dữ liệu mà bạn có đề cập đến. Đây có phải là biến "strURL" liên kết đến trang hiện tại hoặc trang chủ hoặc trang thống kê không? Chắc chắn rằng bạn có thể tạo ra tất cả các loại biến khác nhau có cùng thông tin, nhưng proCienPage-> strURL, dễ hiểu hơn nhiều (đối với nhà phát triển).

Ngoài ra, việc gắn các chức năng vào các trang đó sẽ sạch hơn rất nhiều. Tôi có thể làm proCienPage-> CleanCache (); Tiếp theo là proDisplayItem-> RenderPromo (); Nếu tôi chỉ gọi những chức năng đó và cho rằng dữ liệu hiện tại đã có sẵn, ai biết loại ác nào sẽ xảy ra. Ngoài ra, nếu tôi phải chuyển các biến chính xác vào các hàm đó, tôi sẽ quay trở lại vấn đề có tất cả các loại biến cho các sản phẩm khác nhau được đặt xung quanh.

Thay vào đó, sử dụng các đối tượng, tất cả dữ liệu và chức năng sản phẩm của tôi đều đẹp, sạch sẽ và dễ hiểu.

Tuy nhiên. Vấn đề lớn với OOP là khi ai đó tin rằng MỌI THỨ nên là OOP. Điều này tạo ra rất nhiều vấn đề. Tôi có 88 bảng trong cơ sở dữ liệu của mình. Tôi chỉ có khoảng 6 lớp và có lẽ tôi nên có khoảng 10. Tôi chắc chắn không cần 88 lớp. Hầu hết thời gian truy cập trực tiếp vào các bảng đó là hoàn toàn dễ hiểu trong các trường hợp tôi sử dụng và OOP thực sự sẽ gây khó khăn / tẻ nhạt hơn khi đi đến chức năng cốt lõi của những gì đang xảy ra.

Tôi tin rằng một mô hình lai của các đối tượng trong đó hữu ích và thủ tục trong đó thực tế là phương pháp mã hóa hiệu quả nhất. Thật xấu hổ khi chúng ta có tất cả những cuộc chiến tôn giáo này, nơi mọi người ủng hộ sử dụng một phương pháp với chi phí khác. Họ đều tốt, và cả hai đều có vị trí của họ. Hầu hết thời gian, có những cách sử dụng cho cả hai phương thức trong mọi dự án lớn hơn (Trong một số dự án nhỏ hơn, một đối tượng hoặc một vài thủ tục có thể là tất cả những gì bạn cần).

Tôi không quan tâm đến việc tái sử dụng nhiều như tôi có thể đọc được. Cái sau có nghĩa là mã của bạn dễ thay đổi hơn. Điều đó một mình có giá trị bằng vàng trong nghề xây dựng phần mềm.

Và OO là một cách khá hiệu quả để làm cho chương trình của bạn có thể đọc được. Tái sử dụng hoặc không sử dụng lại.

"Thế giới thực không phải là" OO ","

Có thật không? Thế giới của tôi đầy những đồ vật. Tôi đang sử dụng một cái bây giờ. Tôi nghĩ rằng việc có các "đối tượng" mô hình hóa các đối tượng thực sự có thể không phải là một điều tồi tệ như vậy.

Thiết kế OO cho những thứ mang tính khái niệm (như Windows, không phải cửa sổ trong thế giới thực, nhưng bảng hiển thị trên màn hình máy tính của tôi) thường để lại nhiều điều mong muốn. Nhưng đối với những thứ trong thế giới thực như hóa đơn, đơn đặt hàng vận chuyển, yêu cầu bảo hiểm và những gì không phải, tôi nghĩ những thứ trong thế giới thực đó là đối tượng. Tôi có một chồng trên bàn của tôi, vì vậy chúng phải là thật.

Quan điểm của OOP là cung cấp cho người lập trình một phương tiện khác để mô tả và truyền đạt một giải pháp cho một vấn đề về mã cho máy móc và con người. Phần quan trọng nhất của nó là giao tiếp với mọi người. OOP cho phép lập trình viên khai báo ý nghĩa của chúng trong mã thông qua các quy tắc được thi hành bằng ngôn ngữ OO.

Trái với nhiều tranh luận về chủ đề này, các khái niệm OOP và OO có sức lan tỏa khắp tất cả các mã bao gồm mã bằng các ngôn ngữ không phải OOP như C. Nhiều lập trình viên không phải OO tiên tiến sẽ ước tính các tính năng của các đối tượng ngay cả trong các ngôn ngữ không phải OO.

Có OO được tích hợp vào ngôn ngữ chỉ mang đến cho lập trình viên một phương tiện biểu đạt khác.

Phần lớn nhất để viết mã không phải là giao tiếp với máy, phần đó rất dễ, phần lớn nhất là giao tiếp với các lập trình viên của con người.