it-swarm-vi.com

Liệu OOP có thực hiện đúng lời hứa sử dụng lại mã không? Có những lựa chọn thay thế nào để đạt được việc sử dụng lại mã?

Có lẽ lời hứa lớn nhất của việc sử dụng mô hình hướng đối tượng là tái sử dụng mã. Một số tranh chấp rằng điều này đã đạt được. Tại sao nó (không) đạt được?

Mã có sử dụng lại như OOP định nghĩa nó, làm cho các dự án hiệu quả hơn không?

Hoặc dễ quản lý hơn? Hoặc dễ bảo trì hơn? Hoặc với chất lượng hơn?

Có lẽ tất cả chúng ta đều đồng ý rằng tái sử dụng mã là một điều tốt, nhưng có một số cách để đạt được mục tiêu này. Câu hỏi là về phương pháp tái sử dụng mã được cung cấp bởi OOP. Đó có phải là một điều tốt? Có phương pháp nào tốt hơn để sử dụng lại mã so với định hướng đối tượng, phân lớp phụ, đa hình, v.v.? Cách nào tốt hơn? Tại sao?

Hãy cho chúng tôi trải nghiệm của bạn với OOP tái sử dụng hoặc tái sử dụng mô hình khác.

56
Maniero

Tái sử dụng mã là một ý tưởng khá tốt. Không phải là một người tuyệt vời .

Tôi có một viễn cảnh được rút ra từ khoảng 30 năm công nghệ phần mềm, cố gắng "tái sử dụng".

Tôi bắt đầu nghiên cứu "tái sử dụng mã" như một chủ đề nghiên cứu từ những năm 80, sau khi phát hiện ra tôi đã sử dụng lại thiết kế của một hệ điều hành tôi xây dựng vào đầu những năm 70, cho một hệ điều hành khác mà tôi đã xây dựng vào cuối những năm 70.

Phần tốt của việc tái sử dụng mã là khả năng đôi khi sử dụng lại mã có từ trước trung thực. Nhưng thế giới là đầy đủ mã; Làm thế nào có thể tìm thấy những gì bạn muốn? Đây là những gì tôi gọi là Lời nguyền tái sử dụng :

Tôi là Santa Claus (nguồn mở ok) và tôi có một túi gồm 1 tỷ thành phần phần mềm. Bạn có thể có bất kỳ một trong số họ.

Chúc may mắn lựa chọn.

Để giải quyết vấn đề tái sử dụng tốt:

  • người tái sử dụng cần xác định bằng cách nào đó những gì anh ta cần (chức năng, hiệu suất, ngôn ngữ đích, giả định môi trường, ...)
  • phải có một thư viện mã "tái sử dụng" được lập chỉ mục theo nhiều cách khác nhau theo các tiêu chí tiềm năng này
  • một số cơ chế phải tồn tại để chọn ra các yếu tố ứng cử viên (ở một tỷ yếu tố, bạn không thể xem xét tất cả các yếu tố cá nhân)
  • cần phải có một cách để mô tả đặc điểm cách xa các đặc điểm kỹ thuật của các ứng cử viên được chọn
  • một số quy trình thông thường nên tồn tại để cho phép người sử dụng sửa đổi mã có thể sử dụng lại được chọn (đây là đóng góp lớn nhất của OOP: bạn có thể chỉnh sửa một thành phần/đối tượng hiện có bằng cách ghi đè các vị trí của nó. OOP không cung cấp bất kỳ giúp đỡ khác).
  • tất cả điều này rõ ràng phải rẻ hơn đơn giản là mã hóa lại nó

Hầu hết những gì đã được phát hiện trong nhiều năm qua là để mã có thể được sử dụng lại, nó phải được thiết kế cho mục đích đó hoặc nó chứa quá nhiều giả định ngầm. Các thư viện tái sử dụng mã thành công nhất thực sự là khá nhỏ. Các thư viện và khung công tác có thể là mã "tái sử dụng" và chúng cực kỳ thành công; Java và C # thành công không phải vì chúng là ngôn ngữ máy tính khá tốt, mà là vì chúng có các thư viện tài liệu được thiết kế tốt, được triển khai và tài liệu sẵn có. Nhưng mọi người không nhìn vào mã nguồn trong các thư viện, họ chỉ đơn giản gọi một API có tài liệu tốt (được thiết kế để có thể sử dụng được).

Việc tái sử dụng mã nào chưa được thực hiện (OOP cũng không) là cung cấp các lệnh cải thiện cường độ trong khả năng của chúng tôi đối với các hệ thống mã.

Tôi nghĩ lỗ hổng quan trọng là bất kỳ loại tái sử dụng mã nào bị hạn chế về cơ bản vì mã có quá nhiều giả định được xây dựng trong . Nếu bạn làm cho mã nhỏ, bạn giảm thiểu các giả định, nhưng sau đó chi phí để xây dựng từ đầu không quá lớn và lợi ích tái sử dụng không hiệu quả. Nếu bạn làm cho các đoạn mã lớn, chúng sẽ trở nên vô dụng trong một bối cảnh mới. Giống như Gulliver, chúng bị buộc vào bãi biển bởi một triệu sợi dây nhỏ và bạn chỉ đơn giản là không đủ khả năng để cắt tất cả.

Những gì chúng ta nên làm việc là sử dụng lại kiến ​​thức để xây dựng mã . Nếu chúng ta có thể làm điều này, thì chúng ta có thể áp dụng kiến ​​thức đó để xây dựng mã mà chúng ta cần, xử lý các giả định hiện tại.

Để làm điều này, người ta vẫn cần khả năng đặc tả tương tự để mô tả các thành phần phần mềm (bạn vẫn phải nói những gì bạn muốn!). Nhưng sau đó, bạn áp dụng kiến ​​thức "xây dựng" này cho các thông số kỹ thuật để tạo mã bạn muốn.

Là một cộng đồng, chúng tôi chưa giỏi về điều này. Nhưng mọi người làm điều đó mọi lúc; Tại sao chúng ta không thể tự động hóa nó? Có rất nhiều nghiên cứu, và điều này cho thấy nó có thể được thực hiện trong nhiều trường hợp.

Một phần chính của máy móc cần thiết cho việc này là các công cụ cơ học để chấp nhận "mô tả thành phần" (đây chỉ là các tài liệu chính thức và có thể được phân tích cú pháp như ngôn ngữ lập trình) và áp dụng các biến đổi chương trình với họ.

Trình biên dịch đã làm điều này: -} Và họ thực sự giỏi trong lớp vấn đề mà họ giải quyết.

Các mô hình UML với việc tạo mã là một nỗ lực để làm điều này. Không phải là một nỗ lực rất tốt; hầu như những gì người ta nói trong hầu hết các mô hình UML là "Tôi có dữ liệu giống như thế này". Khá khó để tạo ra một chương trình thực sự nếu chức năng bị bỏ qua.

Tôi đang cố gắng xây dựng hệ thống chuyển đổi chương trình thực tế, một công cụ gọi là DMS . Đã bị phân tâm khá tốt bằng cách áp dụng các biến đổi chương trình không quá nhiều vào các đặc tả trừu tượng để tạo mã, mà thay vào đó là mã kế thừa để dọn sạch nó. (Đây là cùng một vấn đề trong bản tóm tắt!). (Để xây dựng các công cụ như vậy tốn rất nhiều thời gian; tôi đã làm việc này trong 15 năm và trong thời gian đó bạn phải ăn).

Nhưng DMS có hai thuộc tính chính mà tôi đã mô tả ở trên: khả năng xử lý các thông số kỹ thuật chính thức tùy ý và khả năng nắm bắt "kiến thức tạo mã" dưới dạng biến đổi và áp dụng chúng theo yêu cầu. Và đáng chú ý, chúng tôi tạo ra trong một số trường hợp đặc biệt, một số mã khá thú vị từ thông số kỹ thuật; DMS phần lớn được xây dựng bằng cách sử dụng chính nó để tạo ra việc thực hiện. Điều đó đã đạt được cho chúng tôi ít nhất một số lời hứa về việc tái sử dụng (kiến thức): tăng năng suất cực kỳ đáng kể. Tôi có một đội ngũ khoảng 7 người kỹ thuật; chúng tôi đã viết 1-2 MSLOC về "thông số kỹ thuật" cho DMS, nhưng có một số 10MSLOC mã được tạo.

Tóm tắt: sử dụng lại kiến ​​thức thế hệ là chiến thắng, không phải sử dụng lại mã .

35
Ira Baxter

Việc sử dụng lại mã đạt được trong OOP nhưng cũng đạt được trong lập trình chức năng. Bất cứ khi nào bạn lấy một khối mã và làm cho nó có thể gọi được bằng phần còn lại của mã để bạn có thể sử dụng chức năng này nơi khác là sử dụng lại mã.

Loại mã này sử dụng lại cũng làm cho mã dễ quản lý hơn vì việc thay đổi một khối có thể gọi này sẽ thay đổi tất cả các vị trí mà nó được gọi. Tôi muốn nói rằng kết quả này cũng tăng chất lượng và dễ đọc.

Tôi không chắc chắn OOP chỉ đơn giản là ở đó để cung cấp việc sử dụng lại mã. Tôi xem OOP như một cách để tương tác với các đối tượng và trừu tượng hóa các chi tiết của cấu trúc dữ liệu.

Từ Wikpedia :

Lập trình hướng đối tượng có nguồn gốc có thể bắt nguồn từ những năm 1960. Khi phần cứng và phần mềm ngày càng phức tạp, khả năng quản lý thường trở thành mối quan tâm. Các nhà nghiên cứu đã nghiên cứu các cách để duy trì chất lượng phần mềm và phát triển lập trình hướng đối tượng một phần để giải quyết các vấn đề phổ biến bằng cách nhấn mạnh mạnh vào các đơn vị logic lập trình rời rạc, có thể tái sử dụng [cần dẫn nguồn]. Công nghệ tập trung vào dữ liệu thay vì các quy trình, với các chương trình bao gồm các mô-đun tự cung cấp ("lớp"), mỗi trường hợp trong đó ("đối tượng") chứa tất cả thông tin cần thiết để thao tác cấu trúc dữ liệu của chính nó ("thành viên"). Điều này trái ngược với lập trình mô-đun hiện tại đã chiếm ưu thế trong nhiều năm, tập trung vào chức năng của mô-đun, thay vì cụ thể là dữ liệu, nhưng được cung cấp đồng đều để sử dụng lại mã và các đơn vị logic lập trình có thể tái sử dụng, cho phép cộng tác thông qua việc sử dụng các mô-đun được liên kết (chương trình con). Cách tiếp cận thông thường hơn, vẫn còn tồn tại này, có xu hướng xem xét dữ liệu và hành vi một cách riêng biệt.

36
Chris

Có và Không

Tái sử dụng mã là một thuật ngữ bắt tất cả cho nhiều hoạt động khác nhau.

  1. Tái sử dụng mã trong một dự án. OO hoàn toàn phù hợp cho việc này, một ứng dụng được thiết kế tốt sẽ ánh xạ chặt chẽ các mối quan hệ của thế giới được mô hình hóa, do đó loại bỏ mã trùng lặp Tuy nhiên, bạn có thể lập luận rằng các công nghệ tiền OO có thể đạt được điều tương tự, điều này đúng, nhưng OO theo nhiều cách thuận tiện hơn.
  2. Thư viện của bên thứ ba Điều này dường như hoạt động tốt như nhau có hoặc không có OO.
  3. Tái sử dụng mã đa mục đích Lời hứa tái sử dụng mã lớn nhất của OO là mã đó, một lần được viết cho một ứng dụng sau đó có thể được sử dụng lại cho một ứng dụng khác, mà sau đó nó không được sử dụng cho một ứng dụng khác. được thiết kế dành riêng cho. Đây là tất cả cơn thịnh nộ khi khái niệm OO được lọc qua cửa của các văn phòng quản lý cao hơn và OO hoàn toàn không đạt được. Hóa ra mục đích đó là một khía cạnh quan trọng của OO (và có thể là tất cả các mã thủ tục, nhưng đó chỉ là lý thuyết của tôi) và các nỗ lực trong việc tái sử dụng mã đã kết thúc trong thảm họa bảo trì. một khung cũ không ai dám sửa đổi và bạn của nó, các khung hơi khác nhau cho mọi ứng dụng thường xuất phát từ đây.)
15
biziclop

Tôi đồng ý với Chris, lập trình chức năng là một cách tốt để sử dụng lại mã.

Nhiều chương trình có cấu trúc mã được định kỳ. Đối với điều này, một số mẫu thiết kế được sử dụng trong thế giới OOP, nhưng điều này có thể đạt được bằng các hàm đệ quy khớp mẫu trong các ngôn ngữ lập trình chức năng. Để biết thêm về điều này, hãy xem chương đầu tiên trong Lập trình chức năng trong thế giới thực .

Tôi nghĩ rằng sự kế thừa sâu sắc trong OOP có thể gây hiểu nhầm trong nhiều trường hợp. Bạn có một lớp và nhiều phương thức liên quan chặt chẽ được triển khai trong các tệp khác nhau. As Joe Armstrong đã nói về OOP:

Vấn đề với các ngôn ngữ hướng đối tượng là họ đã có tất cả môi trường ngầm này mà họ mang theo bên mình. Bạn muốn có một quả chuối nhưng những gì bạn nhận được là một con khỉ đột đang giữ quả chuối và toàn bộ khu rừng.

Các hàm bậc cao cũng rất hữu ích khi sử dụng lại mã, ví dụ: mapfoldr là nền tảng cho Google MapReduce .

Truyền tin nhắn không đồng bộ cũng là một cách tốt để tổ chức phần mềm phức tạp và một số nhà khoa học máy tính nói rằng các đối tượng được giả định là giao tiếp với nhau không đồng bộ như trong Nói, đừng hỏi OOP nguyên tắc. Xem thêm về điều này trong Lập trình hướng đối tượng: Đường dẫn sai? were Joe Armstrong được trích dẫn:

Tôi bắt đầu tự hỏi về lập trình hướng đối tượng là gì và tôi nghĩ Erlang không hướng đối tượng, đó là ngôn ngữ lập trình chức năng. Sau đó, người giám sát luận án của tôi nói "Nhưng bạn đã sai, Erlang cực kỳ hướng đối tượng". Ông nói các ngôn ngữ hướng đối tượng không hướng đối tượng. Tôi có thể nghĩ, mặc dù tôi không chắc là mình có tin hay không, nhưng Erlang có thể là ngôn ngữ hướng đối tượng duy nhất bởi vì 3 nguyên lý lập trình hướng đối tượng là dựa trên thông điệp đi qua , mà bạn có cách ly giữa các đối tượng và có đa hình .

Thông báo không đồng bộ truyền như trong các hệ thống hướng sự kiện và trong Erlang cũng là một cách rất tốt để tách rời các hệ thống và khớp nối lỏng lẻo rất quan trọng trong các hệ thống phức tạp. Với một hệ thống tách rời đủ, bạn có thể phát triển hệ thống trong khi nó đang chạy, có thể trên các nút khác nhau. Unibet đã trình bày tuyệt vời về điều này: Kiến trúc hướng sự kiện miền

Tuy nhiên tôi nghĩ rằng hầu hết việc sử dụng lại mã được thực hiện bằng cách sử dụng các thư viện và khung.

13
Jonas

Tôi sẽ đăng một câu trả lời dài nhưng tại sao? Udi Dahan giải thích nó tốt hơn nhiều so với tôi có thể.

http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

Đây là phần đầu của bài viết:

Ngành công nghiệp này được sử dụng trước với tái sử dụng.

Có niềm tin này rằng nếu chúng ta chỉ sử dụng lại nhiều mã hơn, mọi thứ sẽ tốt hơn.

Một số người thậm chí còn đi xa hơn khi nói rằng toàn bộ quan điểm của hướng đối tượng là tái sử dụng - đó không phải là GÓI, đóng gói là điều quan trọng. Sau đó, định hướng thành phần là thứ được cho là sử dụng lại. Rõ ràng điều đó cũng không được như vậy bởi vì ở đây chúng ta hiện đang đặt hy vọng tái định hướng của mình vào định hướng dịch vụ.

Toàn bộ sách về các mẫu đã được viết về cách sử dụng lại với định hướng trong ngày. Các dịch vụ đã được phân loại theo mọi cách để cố gắng đạt được điều này, từ các dịch vụ thực thể và dịch vụ hoạt động, thông qua các dịch vụ quy trình và dịch vụ điều phối. Dịch vụ soạn thảo đã được quảng cáo là chìa khóa để tái sử dụng và tạo ra các dịch vụ có thể sử dụng lại.

Tôi cũng có thể cho bạn biết về bí mật bẩn thỉu:

Tái sử dụng là sai lầm

13
Tony

Ống unix khiêm tốn đã làm nhiều hơn cho việc tái sử dụng mã hơn bất kỳ thứ gì khác đến và đi. Các đối tượng chỉ là một cách trực quan để cấu trúc mã khi chúng xuất hiện và sau đó mọi người bắt đầu giải quyết mọi thứ và mọi thứ trên đó. Trong các đối tượng chung là để đóng gói và không sử dụng lại mã, việc sử dụng lại mã đòi hỏi nhiều thứ hơn và hệ thống phân cấp kế thừa lớp là sự thay thế kém cho cơ chế sử dụng lại mã thực sự.

6
davidk01

OOP không có gì đặc biệt; bạn có thể tạo mã có thể tái sử dụng có hoặc không có OOP. Các hàm thuần túy có thể tái sử dụng đặc biệt: ví dụ: Java.lang.math.sqrt(double) lấy một số trong và đưa ra một số. Không có OOP, nhưng chắc chắn có thể tái sử dụng nhiều hơn hầu hết các mã ngoài kia.

4
Joonas Pulakka

Từ chế độ xem lập trình chức năng OOP chủ yếu là về quản lý trạng thái.

Trong lập trình chức năng, bạn có thể dễ dàng có hàng trăm chức năng hữu ích cho danh sách: http://haskell.org/ghc/docs/6.12.1/html/lologists/base-4.2.0.0/Data-List.html .

Bạn có hàng trăm phương thức trong một lớp List không? Các phương thức công khai được coi là một giao diện cho trạng thái bên trong mà bạn muốn giữ nhỏ.

Đáng buồn thay, thay vì (tái) sử dụng nhiều chức năng nhỏ, một số người lại nhân đôi chức năng. Đối với tôi đó là bởi vì OOP không khuyến khích tái sử dụng mã nhiều như lập trình chức năng.

4
LennyProgrammers

Đối với tôi, có, nhưng không phải tất cả thời gian, và nó có thể đã được thực hiện theo những cách khác.

Hầu hết thời gian bằng cách tạo ra một lớp cơ sở trừu tượng và tạo ra các triển khai cụ thể của lớp đó.

Ngoài ra, nhiều khung công tác sử dụng tính kế thừa để cung cấp việc sử dụng lại mã (Delphi, Java, .Net chỉ là một số mà ngay lập tức nảy ra trong đầu).

Điều đó không có nghĩa là rất nhiều thư viện tiện ích và đoạn mã không thể thực hiện được công việc, nhưng có điều gì đó làm hài lòng về hệ thống phân cấp đối tượng được thiết kế tốt.

3
Chris Buckett

Theo kinh nghiệm của tôi, tôi đã thành công hơn khi tận dụng mã "có thể tái sử dụng" thông qua các phương tiện lập trình chung (như các mẫu C++) so với các nguyên tắc OOP như phân cấp thừa kế.

3
Charles Salvia

OOP quá mở để tái sử dụng hiệu quả.

Có quá nhiều cách để sử dụng lại. Mỗi lớp công khai hỏi: "tạo một thể hiện mới của tôi!", mỗi phương thức công khai nói: "gọi cho tôi!", mỗi phương thức được bảo vệ mang lại: = "ghi đè lên tôi!" - và tất cả các cách sử dụng lại này là khác nhau , chúng có các tham số khác nhau, chúng xuất hiện khác nhau bối cảnh, tất cả đều có các quy tắc khác nhau, cách gọi/mở rộng/ghi đè lên nó.

[~ # ~] api [~ # ~] tốt hơn, đó là một tập hợp con nghiêm ngặt của OOP (hoặc không -oop) điểm, nhưng trong thực tế, các API bị quá tải và phát triển mãi mãi, vẫn còn quá nhiều điểm kết nối. Ngoài ra, một API tốt có thể giúp cuộc sống dễ dàng hơn, đó là cách tốt nhất để cung cấp giao diện cho OOP.


Mô hình dữ liệu cung cấp giao diện nghiêm ngặt cho các thành phần, chúng có các cổng thuộc loại sau:

  • người tiêu dùng (đầu vào), và
  • nhà sản xuất (đầu ra).

Phụ thuộc vào tên miền, có một số loại gói, vì vậy người tiêu dùng và nhà sản xuất có thể được kết nối với họ có cùng cổng (hoặc tương thích). Phần đẹp nhất của nó, nó có thể được thực hiện một cách trực quan, bởi vì không có thông số hoặc chỉnh sửa nào trên các kết nối, chúng thực sự chỉ kết nối người tiêu dùng và nhà sản xuất.

Tôi có một chút không rõ ràng, bạn có thể xem thẻ "dataflow" trên StackOverflow hoặc Wikipedia "lập trình datafow" hoặc Wikipedia "lập trình dựa trên dòng chảy " .

(Ngoài ra, tôi đã viết một hệ thống dataflow, bằng C++. Vì vậy, OOP và DF không phải là kẻ thù, DF là một cách tổ chức cấp cao hơn.)

2
ern0

Trong CommonLisp có rất nhiều phương tiện để đạt được mục đích sử dụng lại:

  • gõ động, có mã của bạn là chung theo mặc định

  • trừu tượng bắt buộc, tức là chương trình con

  • hướng đối tượng, với nhiều kế thừa nhiều công văn

  • trừu tượng cú pháp, khả năng xác định cấu trúc cú pháp mới hoặc viết tắt mã nồi hơi

  • trừu tượng chức năng, đóng cửa và chức năng bậc cao

Nếu bạn cố gắng so sánh trải nghiệm CommonLisp với các ngôn ngữ khác, bạn sẽ thấy rằng tính năng chính giúp giảm bớt việc sử dụng lại mã là sự hiện diện của cả hai trừu tượng hướng đối tượng và chức năng. Chúng bổ sung hơn là thay thế: không có một trong số chúng, bạn buộc phải thực hiện lại các tính năng còn thiếu một cách vụng về. Xem, ví dụ, các lớp functor được sử dụng như các bao đóng và khớp mẫu để có được phương thức không thể mở rộng.

2
Andrea

OOP cung cấp cho bạn thêm cách sử dụng lại mã. Đó là tất cả.

1
Steven A. Lowe

Thực sự không có thứ gọi là "tái sử dụng" theo cách mà mọi người mô tả. Tái sử dụng là một tài sản tình cờ của bất cứ thứ gì. Thật khó để lên kế hoạch cho nó. Điều mà hầu hết mọi người có nghĩa là khi họ nói về "tái sử dụng" là "sử dụng". Đó là một thuật ngữ kém hấp dẫn và thú vị. Khi bạn sử dụng một thư viện, thông thường bạn đang sử dụng nó cho mục đích của nó. Bạn đang không sử dụng lại trừ khi bạn đang làm điều gì đó thực sự điên rồ với nó.

Theo nghĩa đó, tái sử dụng trong thế giới thực là về việc tái sử dụng mọi thứ. Tôi có thể tái sử dụng những chỗ ngồi này ở đây và sắp xếp lại chúng để tạo thành ... một chiếc giường! Không phải là một chiếc giường rất thoải mái, nhưng tôi có thể làm điều đó. Đó không phải là sử dụng chính của họ. Tôi đang tái sử dụng chúng bên ngoài phạm vi ứng dụng ban đầu của chúng. [...] Ngày mai, tôi sẽ bay trở lại Vương quốc Anh. Tôi sẽ không sử dụng lại máy bay. Tôi sẽ chỉ sử dụng nó cho mục đích mà nó đã được dự định, không có gì lạ mắt hay thú vị về điều đó.

- Kevlin Henney

1
fredoverflow

Tái sử dụng theo chiều ngang: các khía cạnh, đặc điểm, ghép

Classic OO đôi khi không sử dụng lại mã, đặc biệt khi bạn phát điên vì thừa kế vì không có cách tốt hơn để chia sẻ chức năng thực tế giữa các lớp. Đối với vấn đề này, các cơ chế tái sử dụng ngang đã được tạo, chẳng hạn như AOP, đặc điểm và ghép.

Lập trình định hướng theo khía cạnh

Tôi coi AOP là nửa cam còn thiếu của OOP. AOP không thực sự được biết đến, nhưng nó đã được đưa vào mã sản xuất.

Tôi sẽ thử giải thích bằng các thuật ngữ đơn giản: hãy tưởng tượng rằng bạn có thể tiêm và lọc chức năng với cấu trúc đặc biệt gọi là một khía cạnh, các khía cạnh này có "phương thức" xác định điều gì và sẽ bị ảnh hưởng như thế nào thông qua phản ánh , nhưng tại thời điểm biên dịch, quá trình này được gọi là dệt .

Một ví dụ sẽ là một khía cạnh cho biết "đối với tất cả các phương thức của một số lớp nhất định bắt đầu bằng get, chương trình của bạn sẽ ghi vào một tệp nhật ký dữ liệu đã nhận và thời gian nhận được".

Xem hai bài nói chuyện này nếu bạn muốn hiểu rõ hơn về AOP:

Đặc điểm & Ghép

Traits là một cấu trúc khác để xác định mã có thể sử dụng lại bổ sung cho OOP, chúng tương tự như mixins , nhưng sạch hơn.

Thay vì giải thích chúng, có một tuyệt vời PHP RFC giải thích cả hai . Các đặc điểm đang đến PHP btw, chúng đã sẵn sàng Cam kết thân cây.

Tóm tắt

OOP là chìa khóa trong mô đun, theo quan điểm của tôi và như chúng ta thường biết ngày nay OOP vẫn chưa hoàn thành .

1
dukeofgaming

Tôi sẽ mạo hiểm chế giễu và thú nhận, tôi chỉ mới sử dụng OOP rất gần đây. Nó không tự động đến với tôi. Hầu hết kinh nghiệm của tôi liên quan đến cơ sở dữ liệu quan hệ, vì vậy tôi nghĩ Có những tuyên bố rằng tốt hơn là nên học nó ngay từ đầu, điều đó tránh việc phải điều chỉnh lại suy nghĩ của bạn khi lập trình. Tôi không có sự xa xỉ đó và từ chối bỏ sự nghiệp của mình qua lý thuyết tháp ngà nào đó. mọi thứ khác, tôi sẽ tìm ra nó.

Lúc đầu, tôi nghĩ rằng toàn bộ khái niệm không có ý nghĩa. Nó chỉ có vẻ không cần thiết và quá nhiều rắc rối. Tôi biết, đây là một cuộc nói chuyện điên rồ. Rõ ràng nó cần một mức độ hiểu biết nhất định trước khi bạn có thể đánh giá cao lợi ích của bất cứ điều gì hoặc loại bỏ nó cho các phương pháp tốt hơn.

Tái sử dụng mã có sẵn sàng không lặp lại mã, sự hiểu biết về cách thực hiện nó, lập kế hoạch trả trước. Bạn có nên tránh sử dụng lại mã khi bạn quyết định rằng bạn có một trường hợp không xứng đáng? Và không có ngôn ngữ nào nghiêm ngặt như vậy OO sẽ gây ra lỗi khi nó nghĩ rằng bạn nên thừa kế mã từ một lớp khác. Tốt nhất là họ cung cấp một môi trường thuận lợi để thực hiện nó.

Tôi nghĩ lợi ích lớn nhất của OOP là sự chấp nhận chung về cách tổ chức mã. Mọi thứ khác đều hấp dẫn. Một nhóm lập trình viên có thể không hoàn toàn đồng ý về cách tất cả các lớp nên được cấu trúc, nhưng họ sẽ có thể tìm thấy mã.

Tôi đã thấy đủ mã thủ tục để biết nó có thể ở bất cứ đâu và đôi khi nó ở mọi nơi.

1
JeffO

Đọc các bài viết trên, một vài nhận xét:

  • Nhiều người nghĩ rằng việc tái sử dụng mã trong OOP ngụ ý sự kế thừa. Tôi không đồng ý. Các giao diện và hợp đồng là cốt lõi để tái sử dụng mã trong các hệ thống OOP. OOP là một nỗ lực hộp màu xám trong việc tạo ra một công nghệ thành phần.
  • Sự khác biệt giữa các "khung" cụ thể và tên miền chung như là chủ đề của việc sử dụng lại cho rằng tôi quá trừu tượng. Theo quan điểm của tôi về mọi thứ, một thành phần (một hợp đồng giao diện ngắn gọn, tối thiểu và có thể sử dụng lại và việc thực hiện phía sau) chỉ có thể được thực hiện, nếu vấn đề mà nó giải quyết được hiểu rõ. Một thành phần cụ thể của miền, cho phép các chuyên gia không thuộc miền thực hiện công việc của họ với ít kiến ​​thức về tên miền là một thành phần hữu ích (lại). Người dùng cần phải hiểu giao diện, vì vậy sự phức tạp của miền vấn đề.
  • Các mức độ sử dụng lại thường bị lãng quên: Tái sử dụng ý tưởng, tái sử dụng Đặc điểm kỹ thuật, Sử dụng lại Kiến trúc/Thiết kế, Tái sử dụng Giao diện, Sử dụng lại trường hợp thử nghiệm. Mã sử ​​dụng lại không phải lúc nào cũng thuận lợi. Nhưng đó là một tiết kiệm thời gian lớn thường bám vào một kiến ​​trúc cụ thể để giải quyết một sản phẩm mới, tương tự.
  • OOP Các mẫu thiết kế (Gamma và cộng sự) trong mắt tôi đã xây dựng các kỹ thuật triển khai chiến thuật thay vì có ý nghĩa trong bối cảnh sử dụng lại mã ở quy mô lớn hơn. Chúng giúp viết một ứng dụng với OOP phần tử, nhưng tôi sẽ không xem chúng là một giải pháp cho câu hỏi "sử dụng lại mã" ngoài một ứng dụng.
  • Có thể nó không công bằng: 20 năm kinh nghiệm C/C++/C # và 6 tháng lập trình chức năng (F #). Một yếu tố chính của việc cho phép sử dụng lại là: Mọi người cần dễ dàng tìm thấy "giao diện", nghiên cứu nó, hiểu nó, sau đó sử dụng nó. Lập trình chức năng thuần túy không giúp tôi dễ dàng nhìn thấy cấu trúc, các ứng cử viên để sử dụng lại hoặc nơi tất cả bắt đầu và nơi tất cả kết thúc. "Đường cú pháp" được ca ngợi thường là muối trong mắt tôi, ngăn tôi dễ dàng nhìn thấy những gì xảy ra. Do đó, tôi ít có khả năng cố gắng sử dụng lại một chức năng (đó là gì - bó chức năng?), Có thể có các tác dụng phụ ẩn mà tôi thậm chí không thể nhìn thấy (đánh giá lười biếng, đơn nguyên, ...). Đừng hiểu sai ý tôi, lập trình chức năng có những mặt rất hay, nhưng tất cả những điểm mạnh được tuyên bố tôi thấy với một biện pháp nghi ngờ tốt. Tôi rất tò mò những gì tương lai hậu chức năng mang lại và hy vọng sẽ thấy nó trước khi tôi nghỉ hưu;)
  • Đặc điểm kỹ thuật, thiết kế, triển khai được kết hợp, nhưng không dễ dàng vượt qua các quan điểm về "điều tương tự". Quan trọng hơn nhiều đối với tăng năng suất trong tương lai so với mô hình lập trình mới là, để thu hẹp khoảng cách, tăng (lý luận tự động, truy xuất nguồn gốc) các lợi ích chung giữa các quan điểm đó. Các ngôn ngữ đặc tả được chính thức hóa, các ký hiệu kiểm tra được tiêu chuẩn hóa (ví dụ: ttcn3) và các ngôn ngữ lập trình hỗ trợ xác minh giao diện và hợp đồng đối với các thông số kỹ thuật mà không cần bình luận có thể là những gì chúng ta cần gấp nhất.
0
BitTickler

Vấn đề là imho tinh tế hơn:

  1. OOP là một phương pháp tuyệt vời để cấu trúc mã với trạng thái có thể thay đổi. Bằng cách đóng gói trạng thái vào các đối tượng, mã trạng thái bắt buộc trở nên dễ hiểu hơn bởi vì, ví dụ, nếu một phần trạng thái được biểu thị dưới dạng các trường riêng của một lớp, bạn biết rằng ít nhất là phần trạng thái cụ thể này có thể chỉ được sửa đổi bằng các phương thức của lớp này. (Và bạn có thể dễ dàng phá vỡ lợi ích này bằng cách lạm dụng quyền thừa kế, btw.) Điều này là đủ, nhưng waaay tốt hơn hơn thậm chí không có điều này.
  2. mã với trạng thái có thể thay đổi vốn đã khó sử dụng lại. Cách khó hơn mã sử dụng cấu trúc dữ liệu bất biến.

Vì vậy Bản thân OOP không tệ khi tạo mã có thể tái sử dụng, nhưng các loại mã được viết bằng cách sử dụng OOP vốn khó sử dụng lại.

Ngoài ra, lập trình chức năng có thể dẫn đến mã có thể sử dụng lại nhiều hơn . Nhưng có được sự trừu tượng ngay để viết mã chức năng lành mạnh trong khi đáp ứng thời hạn có thể không thực hiện được. Và các tóm tắt "nửa bên phải" sẽ dễ dàng diễn đạt hơn OOP. Và nó sẽ không có xu hướng dẫn đến dễ sử dụng lại mã - cao hơn mức độ trừu tượng có nghĩa là sự hiểu biết về mã sẽ đòi hỏi một khoản đầu tư trả trước cao hơn từ năng lực nhận thức hạn chế của lập trình viên.

Như một ví dụ thực tế : Mã trò chơi bao gồm rất nhiều trạng thái có thể thay đổi, bởi vì đây là cách tự nhiên để suy nghĩ về việc mã hóa trò chơi, trừ khi đó là một câu đố/thuật toán rất rõ ràng, vì vậy rõ ràng cuối cùng nó được cấu trúc bằng cách sử dụng Ôi. Và tất nhiên là khó sử dụng lại. Nhưng cùng một mã, chứa cùng một kiến ​​thức, sẽ còn khó sử dụng hơn nếu không có OOP. Và viết lại nó thành kiểu chức năng có thể cần thay đổi hoàn toàn cách bạn nghĩ về mã đó, kiến ​​thức đằng sau nó. Vâng, kết quả kiến ​​thức đằng sau mã sẽ rõ ràng hơn nhiều sau khi OO đến FP viết lại có thể ... nhưng chi phí có thể là rất lớn và nó có thể là loại chi phí cũng sẽ phải trả cho những người muốn sử dụng lại mã cực kỳ thông minh và trừu tượng mà bạn kết thúc bằng , thật nghịch lý, mọi người cuối cùng sẽ không sử dụng lại mã, ngay cả khi về mặt kỹ thuật nó có thể tái sử dụng nhiều hơn.

... dẫn đến sự tinh tế cuối cùng: tái sử dụng mã là về giao diện People | Code, không chỉ về mã. OOP thực hiện tốt công việc phục vụ giao diện này vì nó ánh xạ tốt với số lượng người nghĩ về nhiều loại mã được viết hiện nay. FP có thể tốt hơn cho mã tái sử dụng, nhưng imho không cho dễ dàng sử dụng lại loại mã mà mọi người thực sự cần viết ngày nay. Điều này sẽ thay đổi như loại mã mà chúng ta cần viết thay đổi.

P.S. Và nếu bất cứ ai muốn nói rằng "OO không phải là về trạng thái có thể thay đổi, bạn cũng có thể có OO với trạng thái bất biến" ... Tôi gọi đó là "FP sử dụng các lớp làm không gian tên". nó hoạt động cho bạn và nó tránh được một số thiếu sót của hệ thống mô-đun của một số ngôn ngữ và có thể dẫn đến mã có thể tái sử dụng nhiều hơn. Nhưng đó không phải là OO;)

0
NeuronQ

OOP Cung cấp một bộ các công cụ hữu ích cho phép bạn viết mã có thể được sử dụng ở nhiều nơi hơn bạn có thể có mà không cần các công cụ đó. Nếu bạn viết hàm PrintIt có bất kỳ đối tượng cũ nào và gọi .toString() trên đó, bạn sẽ sử dụng lại mã đó ngay khi bạn gọi nó với nhiều hơn một loại đối tượng. Với các công cụ này, mỗi dòng mã sẽ làm được nhiều hơn.

Lập trình chức năng là rất nóng ngay bây giờ trong số các hipster. Nó cung cấp cho bạn một bộ công cụ toàn bộ để làm cho mỗi dòng mã làm được nhiều hơn. Nó có thể không tốt hơn hoặc hoạt động, nhưng cung cấp một công cụ khác trong hộp công cụ.

(Có một ý tưởng điên rồ cho toàn bộ mức độ sử dụng lại hướng đối tượng: Ý tưởng là chúng ta có thể định nghĩa một lớp Customer và sử dụng nó trong mọi ứng dụng chúng ta đã viết. Sau đó, các ứng dụng sẽ chỉ là một chút keo ở đây và ở đó. Điều này không hoạt động. Nhưng điều đó không có nghĩa là OO Không thành công hoặc thậm chí việc sử dụng lại không thành công. Các loại mã cơ bản sử dụng lại trong các ứng dụng đã có thể để viết các ứng dụng đã làm nhiều hơn và viết chúng nhanh hơn.)

0
Sean McMillan