Là tái sử dụng đại khái đồng nghĩa với thiết kế tốt?

Khả năng sử dụng lại là một tính năng của thiết kế phần mềm tốt .

Khả năng sử dụng lại có phải là một độ bóng chấp nhận được ("ký hiệu ngắn gọn về ý nghĩa") cho thiết kế phần mềm tốt không? Tại sao?

Không.

Tái sử dụng là một chỉ số của thiết kế tốt. Nó chỉ ra rằng khớp nối của hệ thống đủ lỏng và sự gắn kết của một đơn vị cụ thể đủ cao để tạo điều kiện tái sử dụng mà không gặp phải các vấn đề phụ thuộc hoặc phải viết lại hầu hết mã.

Tái sử dụng phần lớn là một ảo ảnh. Không thể kiểm chứng được "khả năng tái sử dụng" của một đơn vị mà không biết trước nó sẽ được sử dụng ở đâu hoặc như thế nào. Nhiều nhà phát triển sẽ cố gắng thiết kế các thành phần "có thể tái sử dụng" và thường phát hiện ra rằng các khía cạnh cụ thể mà họ đã cố gắng tạo ra "linh hoạt" chính xác là những thành phần không cần phải có.

Tôi sẽ sử dụng một "độ bóng" khác: Khả năng kiểm tra.

Bây giờ tôi không phải là người ủng hộ TDD, tôi cũng không cảm thấy cần phải kiểm tra đơn vị bất cứ thứ gì và mọi thứ. Nhưng các bài kiểm tra viết cho một thành phần sẽ cho bạn một ý tưởng rất tốt về các đặc tính khớp nối / kết dính của nó, và rất nhanh chóng. Nếu nó phụ thuộc vào sự trừu tượng, thì đó là khớp nối lỏng lẻo; bạn sẽ thấy dễ dàng để chế nhạo các phụ thuộc và điều đó cho thấy một thiết kế tốt. Nếu nó có mục đích rõ ràng (xem thêm Nguyên tắc Trách nhiệm Đơn lẻ ) thì hành vi của nó sẽ tương đối trực quan, bạn sẽ dễ dàng tìm ra những gì cần kiểm tra, một lần nữa, gợi ý một thiết kế tốt.

Điều đó tất nhiên không đảm bảo một thiết kế tốt; việc thực hiện thực tế hoặc thậm chí toàn bộ kiến ​​trúc có thể hoàn toàn không phù hợp với mục đích đã nêu. Nhưng ít nhất nó cho bạn biết rằng bạn không làm việc với mã spaghetti hoặc God Object.

Xin vui lòng, đừng cố gắng đưa ra những phỏng đoán hoang dã về "khả năng sử dụng lại" của một thành phần, đặc biệt là không sử dụng làm bằng chứng của "thiết kế tốt". Đó là thứ bạn chỉ có thể thiết lập trong nhận thức muộn, một khi nó thực sự được sử dụng lại, và sau đó thiết kế có thể đã thay đổi đáng kể.

Không.

Khả năng sử dụng lại là một tính năng tốt để có, bởi vì nó có thể tăng tốc độ phát triển trong tương lai. (Mặc dù trong thực tế, rất ít tổ chức thấy sự phát triển trong tương lai được tăng tốc gần như họ hy vọng.) Tuy nhiên, bất kỳ phần mềm quan trọng nào cũng có các phần dành riêng cho ứng dụng đó. Và hơn nữa khi những người không có kinh nghiệm về miền cố gắng viết phần mềm có thể sử dụng lại, họ thường làm xáo trộn phần đó và giảm hiệu suất mà không thực sự thành công trong việc làm cho nó có thể sử dụng lại.

Do đó, thiết kế tốt là mô-đun và chỉ có thể tái sử dụng khi bạn có thể thấy rằng phần đó có thể được tái sử dụng và nơi bạn có chuyên môn để thực sự đạt được khả năng sử dụng lại. Ở những nơi khác bạn nên cố gắng làm cho mọi thứ sạch sẽ nhưng đừng lo lắng về việc tái sử dụng. (Ngoại trừ phía sau đầu của bạn, nơi bạn đang ghi chú để trên một số hệ thống trong tương lai, bạn sẽ có ý tưởng làm thế nào để sử dụng lại nó.)

Tôi tin (và đây là niềm tin cá nhân của tôi) rằng mối quan hệ giữa khả năng sử dụng lại và thiết kế tốt không phải là phản xạ, vì vậy câu trả lời cơ bản và đơn giản là không . Nếu bạn đang quan tâm trên một số hướng dẫn thiết kế tốt, kiểm tra này bài viết wikipedia.

Một thiết kế phần mềm tốt phải có thể tái sử dụng, ít nhất là trong một số phần cốt lõi, tôi nghĩ rằng rất ít người thực sự sử dụng lại mã nguồn, do thực tế việc thiết kế lõi của một hệ thống có thể tái sử dụng ở nhiều bối cảnh khác nhau là rất phức tạp. (Và tôi đang nói điều này từ kinh nghiệm)

Hãy xem xét một lớp có số lượng lớn khả năng đáp ứng (còn gọi là Blob) thực hiện tất cả các nhiệm vụ bạn cần nhưng không có bất kỳ cân nhắc thiết kế nào cả, có lẽ bạn đã thấy trường hợp này. Hầu hết những người có một lớp học như vậy sẽ sử dụng nó nhiều lần và tôi nghĩ rằng chúng ta sẽ phải đồng ý rằng đó là tái sử dụng, tái sử dụng vô thiết.

Hy vọng tôi đã không làm hỏng lời giải thích của tôi quá nhiều

Tôi nghĩ rằng một chỉ số tốt hơn của thiết kế tốt là tuân thủ các ý tưởng cơ bản như nguyên tắc trách nhiệm duy nhất và duy trì sự gắn kết của từng thành phần. Bằng cách sử dụng các tóm tắt với giao diện rõ ràng và súc tích và duy trì sự tuân thủ với Hiệu trưởng thay thế Liskov, chúng tôi khuyến khích tái sử dụng trong khi không cố gắng dự đoán những gì sẽ và sẽ không được sử dụng lại.

Bám sát các nguyên tắc thiết kế cơ bản này làm cho mã dễ kiểm tra hơn và dễ sử dụng lại hơn.

Thiết kế tốt == thiết kế tốt, tái sử dụng là sản phẩm phụ.

Tái sử dụng thường là một mục tiêu thiết kế ngầm. Nếu bạn có thể tạo một thành phần, hoặc toàn bộ thiết kế, theo cách mà nó có thể được sử dụng lại sau này, có vẻ như rõ ràng rằng bạn nên làm điều đó. Điều không phải lúc nào cũng rõ ràng là nó có thể mất rất nhiều thời gian và công sức (và tiền bạc) để làm cho một cái gì đó có thể tái sử dụng, và do đó lợi ích của việc tái sử dụng phải được cân nhắc với chi phí của nó.

Một thiết kế có thể tái sử dụng có giá gấp đôi và / hoặc mất gấp đôi thời gian để xây dựng so với những gì khách hàng cần không phải là một thiết kế tốt theo quan điểm của khách hàng, đặc biệt nếu khách hàng không cần tái sử dụng.

Có một số thuộc tính tương tự thường được coi là mục tiêu thiết kế ngầm vì chúng rõ ràng là tốt:

• giảm thiểu chi phí

• giảm thiểu thời gian phát triển

• giảm thiểu độ phức tạp

• tối đa hóa độ tin cậy

Những điều này đều tốt về mặt khách quan, nhưng có thể không phải lúc nào cũng quan trọng đối với một khách hàng cụ thể, vì vậy điều quan trọng là phải hiểu đầy đủ những gì khách hàng của bạn cần (ngay cả khi khách hàng đó chỉ là sếp của bạn). Có một số câu cách ngôn nhằm nhắc nhở chúng ta về thực tế này (ví dụ: "Hoàn thành tốt hơn hoàn hảo" và "Tốt, rẻ, nhanh: chọn bất kỳ hai"), nhưng vẫn dễ rơi vào bẫy khi cố gắng làm cho phần mềm trở nên tuyệt vời ở mọi khía cạnh khi thực tế tuyệt vời ở mọi khía cạnh không phải lúc nào cũng cần thiết.

Để đi đến câu hỏi tiêu đề, sau đó: Không , tái sử dụng không đồng nghĩa với thiết kế tốt. Khả năng sử dụng lại có thể là một thành phần hữu ích của một thiết kế tốt cụ thể, nhưng chỉ khi nó được yêu cầu.

Không cần thiết. Nếu bạn làm một cái gì đó có thể tái sử dụng mà rõ ràng sẽ không bao giờ được sử dụng lại thì đó là thiết kế tồi.

Ví dụ: nếu bạn đang viết một tệp chứa đầy dữ liệu duy nhất cho công ty của bạn và dữ liệu đó sẽ được nhập một lần vào nơi khác, tại sao bạn phải làm cho nó có thể sử dụng lại?

Điều đó nói rằng, nếu khung của bạn chưa có, mã để ghi vào tệp có thể cần được sử dụng lại. Đó sẽ là thiết kế tốt.

Tôi sẽ nói không, chủ yếu là vì nó chỉ mô tả một đoạn mã nhỏ. Tôi đã thấy rằng khả năng sử dụng là quan trọng nhất là ở cốt lõi và ở rìa ngoài của lãnh thổ tiện ích, không có quá nhiều ở giữa. Tôi sẽ đưa ra một vài ví dụ về những điều mà tôi nghĩ rằng khả năng sử dụng lại là một thước đo hữu ích của thiết kế chất lượng.

Công cụ cốt lõi

• Các mẫu biểu mẫu web cho phép một trang được thêm dễ dàng và nhất quán (hoặc cho bất kỳ loại UI nào)
• Trình trợ giúp mẫu thiết kế như lớp cơ sở ViewModel sẽ được bao gồm trong tất cả các ứng dụng MVVM của tôi

Tiện ích

• Lớp email gửi tin nhắn SMTP (sử dụng nó mọi lúc)
• Một lớp máy tính khoảng cách GIS (được sử dụng trong một loạt các ứng dụng của chúng tôi)

Đối với các công cụ CRUD chiếm 70-80% trong hầu hết các ứng dụng, tôi chỉ không nghĩ rằng khả năng sử dụng lại là một số liệu có giá trị.