Khi nào không dùng nữa và khi nào cần xóa trong Java

Là một phần của nỗ lực tái cấu trúc hoặc chỉ là sự phát triển đang diễn ra, một phương thức cụ thể hoặc có thể là toàn bộ một lớp có thể trở nên lỗi thời theo một nghĩa nào đó. Java hỗ trợ @Deprecatedchú thích để chỉ ra rằng có lẽ có một cách tốt hơn để xử lý các chức năng được đề cập. Tôi tưởng tượng điều này đặc biệt hữu ích trong các API công cộng, nơi mà các tác động của việc loại bỏ các phần của API có thể không được biết đến. Đối với API không công khai và dự án sử dụng các hệ thống kiểm soát sửa đổi (vì vậy việc xóa có thể được hoàn tác theo một nghĩa nào đó), khi nào thì thích hợp để loại bỏ thay vì xóa (các) phần tử lỗi thời?

API của bạn có phải là API công khai không? Điều đó quyết định xem bạn có nên phản đối hay loại bỏ hay không. Nếu API hoàn toàn vì lợi ích của bạn (tức là chỉ được sử dụng trong công ty của bạn), thì tốt nhất bạn chỉ cần xóa mã vi phạm. Nó sạch hơn nhiều và sẽ gây ra ít đau đầu bảo trì hơn trong thời gian dài.

Tuy nhiên, nếu API phải đối mặt công khai, chỉ cần xóa một phương thức có thể khiến mã được sử dụng để làm việc với các phiên bản cũ hơn của thư viện của bạn ngừng hoạt động. Đó là nơi mọi thứ trở nên lộn xộn. Sau đây là một số hướng dẫn:

• API nội bộ: loại bỏ thay vì không dùng nữa. Nếu bất kỳ máy khách nào đang sử dụng một lớp hoặc phương thức nội bộ, đó là lỗi của chúng nếu công cụ bị hỏng.
• API bên ngoài: không dùng trước, xóa sau. Khấu hao là một lá cờ mà một cái gì đó sẽ được gỡ bỏ sau này. Sau này phụ thuộc vào những gì bạn tin là hợp lý. Ít nhất hãy đưa ra 2-3 phiên bản trước khi thực sự loại bỏ mã không dùng nữa.

Có lẽ là một ý tưởng tốt để thiết lập một lời nhắc khi bạn @deprecate một lớp hoặc phương thức. Bạn đang làm điều đó để thúc đẩy sự lỗi thời của nó. Vì vậy, hãy đoán xem sẽ mất bao lâu, như một thời gian rảnh rỗi, khi bạn thực hiện nhiệm vụ, để loại bỏ tất cả các tài liệu tham khảo. Đánh dấu là @deprecated và đặt lời nhắc trong lịch của bạn. Khi bạn nhận được lời nhắc, hãy kiểm tra. Nếu nó không còn được sử dụng, hãy xóa nó. Nếu một vài tài liệu tham khảo vẫn có thể được cập nhật nhanh chóng, hãy làm điều đó và xóa mục đó. Nếu công việc quan trọng hơn vẫn còn, hãy nhắc nhở bạn về phía trước một chút.

Làm điều này đủ lần và bạn sẽ phát triển cảm giác mất bao lâu để thoát khỏi một lớp hoặc phương thức trong các dự án của bạn.

IMHO nếu bạn có thể đảm bảo rằng không ai đang sử dụng nó và sẽ không bao giờ, chỉ cần loại bỏ nó. (Điều này có thể khó khăn khi có sự phản chiếu hoặc các thành phần bên ngoài như macro Velocity - các IDE hiện đại như IntelliJ có thể tìm thấy các tài liệu tham khảo trong ví dụ như JSP nhưng không thông qua phản xạ hoặc trong Velocity.)

Nếu có một giải pháp thay thế tốt hơn nhưng cái cũ vẫn được sử dụng ở nhiều nơi và hiện tại bạn không có thời gian để cấu trúc lại tất cả mã khách hàng, thì điều đó là đủ để @deprecate lớp / phương thức lỗi thời (với một nhận xét thích hợp về sự thay thế ưa thích).