Phá vỡ các thay đổi API: làm cách nào tôi có thể thực hiện chuyển đổi dễ dàng cho người dùng thư viện?

Trước đây, tôi đã sử dụng cách tiêu chuẩn để thêm @Deprecatedchú thích vào các phương thức API sẽ bị xóa trong phiên bản mới hơn.

Bây giờ tôi đang chuẩn bị một phiên bản chính cho một thư viện, với nhiều phần API được gỡ bỏ và đổi tên.

Để giúp việc chuyển đổi dễ dàng hơn cho người dùng hiện tại, có thể hữu ích nếu phiên bản thư viện mới có thể được sử dụng song song với phiên bản cũ.

Ưu điểm

• chuyển đổi động giữa các phiên bản có thể được thực hiện
• các ứng dụng có thể quay lại phiên bản trước nếu lỗi được tìm thấy trong phiên bản mới (hữu ích trong giai đoạn beta)

Để làm điều này, tôi chỉ đơn giản là có thể di chuyển phiên bản thư viện mới cho một gói mới từ com.mycompany.libraryđếncom.mycompany.library.v2

Đây có phải là một thực tiễn phổ biến hoặc có các khuyến nghị khác cho việc sử dụng các thư viện Java song song như vậy không?

Lý lịch:

thư viện là một công cụ chuyển đổi tài liệu đơn giản. Vì vậy, bên cạnh một mehtod chuyển đổi (vào, ra), nó có nhiều thuộc tính cấu hình và một số trình xử lý sự kiện. Nếu tôi cung cấp việc sử dụng song song, người tiêu dùng có thể tự động khởi tạo và định cấu hình chúng:

if (useVersion2) {
  com.mycompany.library.v2.Converter c = new com.mycompany.library.v2.Converter();
  // configure and run
  c.setOption(...);
  c.convert(in, out); 
} else {
  com.mycompany.library.Converter c = new com.mycompany.library.Converter();
  // configure and run
  c.setOption(...);
  c.convert(in, out);
}

(câu hỏi được chuyển từ /programming/37192945/ )

Cách tiếp cận này khá phổ biến. Nó cho phép chuyển đổi suôn sẻ sang API mới và tiến hóa an toàn theo hướng triển khai mới.

Tất nhiên, cách tiếp cận if / then, như Laiv đã nêu trong câu trả lời của ông, có một số nhược điểm. Thật tẻ nhạt. Thật dễ dàng để quên hoặc trộn lẫn mọi thứ. Lý tưởng nhất, việc sử dụng giấy gói, nhà máy hoặc bộ điều hợp có thể cung cấp một số lựa chọn thay thế đẹp hơn. Nhưng thông thường, đơn giản là tốt hơn.

Martin Fowler và Pete Hogdson gần đây đã đưa ra giả thuyết về chủ đề này trong một bài viết xuất sắc trong đó họ mô tả cái mà họ gọi là "mô hình chuyển đổi tính năng". Nó có thể khiến bạn quan tâm vì các chiến lược triển khai khác nhau - chẳng hạn như việc sử dụng "bộ định tuyến chuyển đổi" - và các kịch bản sử dụng được mô tả chi tiết đầy đủ.

Lưu ý: cá nhân tôi không tìm thấy tính năng bật tắt. Đến từ thế giới C ++, tôi thích cách thay thế dễ dàng và mạnh mẽ bằng cách sử dụng các bí danh không gian tên và sử dụng các mệnh đề để chọn tại thời điểm biên dịch phiên bản sẽ sử dụng. Nhưng đó là ngôn ngữ cụ thể và hơn nữa, nó không cho phép cấu hình động như tính năng bật. Vì vậy, như đã nói, đôi khi, đơn giản là tốt hơn ;-)

Thư viện trang bị thêm là một ví dụ tuyệt vời cho việc này. Chưa được bao lâu kể từ khi họ giới thiệu phiên bản 2 ổn định, điều này thực sự tốt ngay cả khi nó mang lại một số sự cố.

Một số điều đáng chú ý mà họ đã làm là:

1. API mới có rất nhiều giá trị và giải quyết được nhiều thiếu sót của phiên bản cũ. Điều này có nghĩa là API mới của bạn phải rất tốt. Không chỉ về cách thức hoạt động, mà còn làm cho nó trông đẹp và dễ dàng, nếu đó là một vấn đề.

2. Phiên bản Beta cho API mới đã được phát hành cho phép người dùng tìm hiểu sớm các thay đổi và thậm chí cung cấp phản hồi tốt.

3. Quá trình chuyển đổi cũng không đau đớn. Họ đã giới thiệu số phiên bản trong chính tên gói, có nghĩa là một số thay đổi chỉ yêu cầu sửa đổi các báo cáo nhập khẩu. Vâng, một số lớp đã bị xóa và một số được giới thiệu, nhưng nó không cảm thấy quá quyết liệt. Điều này cũng phụ thuộc vào cách người dùng đã tổ chức cơ sở mã của họ, một phần nằm ngoài phạm vi của nhà phát triển API.

Ngoài ra, hướng dẫn di chuyển được ưa thích. Trang bị thêm, là một thư viện phổ biến, nhiều bài viết liên quan đến điều này có sẵn trực tuyến.

Tôi không nghĩ rằng chia tách mã với if/elselà một cách tiếp cận tốt.

Hãy suy nghĩ một thời gian dài. Bạn sẽ làm gì với các phiên bản tiếp theo?. )

Làm thế nào mã người dùng có thể kết thúc cùng thời gian?

Đối với các phiên bản nhỏ hoặc đánh giá, để giữ tính tương thích được mong đợi. @Deprecated đi kèm với nhận xét yêu cầu nhà phát triển không sử dụng mã đó. Nó cũng đề xuất thành phần / phương thức / lớp nào nên được sử dụng thay thế. Cuối cùng, nhiều người trong số họ thông báo rằng mã không dùng nữa sẽ không được hỗ trợ trong các phiên bản tiếp theo. Hoặc có thể không được hỗ trợ (họ chưa biết).

Tuy nhiên, trên các phiên bản mới (thiết kế lại thay đổi lớn) không có ý nghĩa quá nhiều để giữ mã không dùng nữa vì nó làm cho việc bảo trì khó khăn hơn. Mã kế thừa cũng có thể được tránh khỏi bởi những thay đổi được thực hiện. Trực tiếp hay không.

Nó cũng làm cho việc sử dụng không rõ ràng. Ngay cả khi mã không dùng nữa được chú thích.

Nếu trường hợp của bạn là một thay đổi lớn hoặc cải tổ thực sự, tôi muốn khuyến khích / buộc người dùng chuyển sang tính năng mới.

Nếu lib mới trông không thể sử dụng được, người dùng có thể hạ cấp phụ thuộc và tiếp tục sử dụng cho đến khi các lỗi lib mới được giải quyết.

Là nhà phát triển, tôi mong đợi những thay đổi từ phiên bản này sang phiên bản khác. Nếu tôi quyết định sử dụng cái mới, tôi chấp nhận để đối phó với những thay đổi đó.

Ở kịch bản tồi tệ hơn, tôi có thể chuyển về trước.

Tôi sẽ không nằm trên các biểu thức như "là tạm thời". Bởi vì tất cả chúng ta đều biết làm thế nào nó kết thúc ...

Thay vào đó để ngăn chặn người dùng rơi vào những xác nhận như vậy mà kết thúc bằng mã khó đọc và khó duy trì