Mẫu chuyển đổi đối tượng

Question

Tôi có một số lớp khác nhau đến từ các nguồn bên ngoài (không thể sửa đổi) đại diện cho cùng một khái niệm. Ví dụ: Address. Tôi có com.namespace1.Address (với các lĩnh vực houseNum, street, city), com.namespace2.Address (với các lĩnh vực h, s, c), namespace3.com.CoolAddress (với các lĩnh vực house_num, street, city).

Sự cố là một số dịch vụ web nhất định mà tôi sử dụng yêu cầu một số loại đối tượng Địa chỉ nhất định, vì vậy tôi bắt buộc phải tạo một số com.namespace1.Address cho một số namespace3.com.CoolAddress. Các trường này đủ dễ dàng để lập bản đồ nhưng tôi đang tìm kiếm một mẫu về cách thực hiện.

Từ quan điểm của tôi, đối tượng thể hiện AddressConverter không có ý nghĩa vì không có trạng thái (chỉ hành vi) và khi các lớp chỉ có hành vi, nó sẽ chuyển thành các phương thức tĩnh trong lớp tiện ích. Về lâu dài, bất cứ khi nào tôi cần ánh xạ các đối tượng mới với nhau, tôi có một nơi để thêm/sửa đổi/xóa các phương thức. Làm thế nào nó được thực hiện có thể thay đổi, nhưng tôi biết nơi mã ngồi (ở một nơi) và có thể thay đổi ánh xạ khi tôi cần.

Suy nghĩ?

Answer 1

Tôi nghĩ rằng những gì bạn đang tìm kiếm là một lớp nhà máy . Mẫu nhà máy được sử dụng khi bạn cần để có thể khởi tạo một trong một số lớp liên quan, được xác định bởi nhà máy chứ không phải nhà phát triển.

Xem http://en.wikipedia.org/wiki/Factory_method_pattern

Bạn nói đúng để cố gắng giữ tất cả các logic kinh doanh này ở một nơi thay vì làm ClassOne.toClassTwo(), ClassOne.toClassThree(), ...

Các linh hoạt nhất cách mà tôi có thể nghĩ đến việc thực hiện điều này (nhưng không dễ nhất) sẽ có nhà máy bắt đầu với một lớp đơn giản chỉ với các phương thức cơ bản chung và thêm các trình xử lý vào một thùng chứa Hashtable hoặc container khác. Bằng cách đó bạn không cần triển khai cụ thể về mọi kết hợp các tính năng có thể có. Tất nhiên nó sẽ nhanh hơn để có một thực hiện cụ thể cho mỗi biến thể địa chỉ có thể, nhưng sẽ có một số tiền hợp lý của mã trùng lặp, và nó sẽ là một chút khó khăn hơn để thêm các loại lớp địa chỉ mới.

Answer 2

Vì bạn không thể tự sửa đổi các lớp, tôi khuyên bạn nên triển khai mẫu Adapter cho mỗi hướng. Như bạn đã nói, các phương thức của bộ điều hợp có thể là tĩnh, nhưng bạn có thể nhóm cả hai hướng trong một lớp đơn lẻ để tất cả các logic ở một nơi.

Vào cuối ngày, bạn sẽ thực hiện tác vụ tương tự bất kể bạn gọi nó là gì, hoặc nơi bạn đặt mã. Tôi muốn đề xuất rằng cả hai hướng đều sống trong cùng một tệp, vì chúng thường cần cập nhật khi cả hai hướng thay đổi.

Answer 3

Nếu bạn luôn chuyển sang cùng một Lớp, tôi sẽ giữ nó đơn giản và đặt tất cả mã chuyển đổi vào Lớp đó và không lo lắng về các nhà máy và loại tương tự, đặc biệt là nếu bạn chỉ giao dịch với một vài lớp khác nhau. Tại sao luôn luôn có một mô hình phức tạp cho những điều này ?!

public class A { 

    ... 

    public static A convertB(B b) { 

    ... 

    } 
} 

Answer 4

Các lớp học bạn cần xuất ra final? Nếu không, bạn có thể phân lớp chúng để tạo ra Adapters thích hợp. Nếu không tôi sẽ đi với đề nghị của dj_segfault về một nhà máy với một bảng xử lý.

Hoặc, đợi - đó chỉ là dịch vụ web bạn cần nói chuyện? Nếu vậy, sẽ không có lý do gì mà việc triển khai các kiểu dữ liệu của nó không thể là các bộ điều hợp gói các kiểu dữ liệu đầu vào, hoặc một số đối tượng trung gian của riêng bạn.