Thực hiện một lớp ẩn phức tạp


8

Là một phần của các phụ thuộc mà dự án tôi đang thực hiện, chúng tôi sử dụng một số dịch vụ cốt lõi. Những dịch vụ này, mà chúng tôi không thể tạo ra những thay đổi lớn, là một mớ hỗn độn lớn. Tùy thuộc vào phương thức chúng ta gọi, chúng ta cần chuyển đổi các tham số (và trả về giá trị) thành các bảng mã, địa phương và múi giờ khác nhau.

Vì chúng tôi tạo các tham số này ở nhiều nơi trong mã riêng của mình, chúng tôi thực hiện các chuyển đổi này ở nhiều nơi. Đôi khi chúng ta tạo ra chúng, trước khi vượt qua chúng ở bên chúng ta; một số lần ngay trước khi gọi phương thức trong dịch vụ cốt lõi. Vì vậy, mớ hỗn độn đang lan rộng khắp mã của chúng tôi và tôi muốn giới thiệu một lớp để cô lập nó.

Câu hỏi của tôi là cách tiếp cận tốt nhất cho điều đó. Ban đầu tôi nghĩ chỉ cần tạo một dịch vụ / phương thức tương ứng với từng dịch vụ / phương thức mà chúng ta cần sử dụng. Các phương thức này chỉ đơn giản là thực hiện chuyển đổi, ủy quyền cho các dịch vụ cốt lõi và thực hiện chuyển đổi giá trị trả về. Nhưng điều này có vẻ khó sử dụng.

Sau đó tôi nghĩ đến việc sử dụng các chú thích, nhưng tôi không hoàn toàn chắc chắn về cách sử dụng chúng. Và theo tôi hiểu, lý tưởng nhất là tôi sẽ cần chú thích phương thức được gọi. Chẳng hạn, tôi có thể chú thích các tham số với @converToUtcvà thực hiện chuyển đổi trong triển khai chú thích. Điều này có đúng không? Tất nhiên, điều này thật khó vì đó không phải là mã của chúng tôi và nó sẽ phá vỡ mã hiện đang sử dụng các phương thức đó trong các dự án khác ngoài chúng tôi.

Cách tiếp cận tốt nhất cho tình huống này là gì?


6
Một thuật ngữ phổ biến cho việc này là lớp chống tham nhũng nếu bạn muốn tìm kiếm nó.
Esben Skov Pedersen

Câu trả lời:


6

Những gì bạn đang cố gắng làm là thực hiện mô hình mặt tiền . Về cơ bản bạn muốn đặt một khuôn mặt đơn giản hơn vào mã lõi. Có lẽ bạn sẽ muốn tạo một tập hợp các lớp cung cấp ánh xạ 1: 1 cho mỗi lớp lõi, sau đó sử dụng các lớp mặt tiền thay cho các lớp lõi. Nếu các dịch vụ cốt lõi chỉ là một loạt các phương thức trong một số lớp nguyên khối lớn, thì bạn có thể xem xét phá vỡ chúng theo miền chức năng (ví dụ: xác thực, truy cập dữ liệu, chức năng kinh doanh, v.v.) và có mặt tiền khác nhau cho mỗi miền. Mặt tiền của bạn phải trình bày một giao diện có ý nghĩa với mã của bạn và xử lý tất cả các ánh xạ và chuyển đổi dữ liệu cần thiết để giao tiếp với các dịch vụ cốt lõi.


6

Vấn đề bạn đang gặp phải là một ví dụ của một vấn đề chung mà chúng ta thường gặp phải trong Kỹ thuật phần mềm: Tạo ra các công cụ để đưa chúng đến miền vấn đề cụ thể của chúng ta bằng các lớp trừu tượng / chuyển đổi.

Bạn có một ứng dụng giải quyết vấn đề. Các thực thể mà nó chứa, quản lý và tương tác với chúng là các thực thể thuộc về miền của vấn đề. Tất cả chúng đều được thể hiện bằng các thuật ngữ hữu ích để giải quyết vấn đề trong tay và chúng "thân thiện" ở chỗ chúng cho phép bạn tập trung giải quyết vấn đề thay vì lãng phí thời gian và làm ô nhiễm mã của bạn bằng các chuyển đổi không liên quan đến vấn đề trong tầm tay.

Miễn là bạn sở hữu tất cả các mã, đó là tất cả tốt và bảnh bao; nhưng khi bạn đưa các công cụ (thư viện) của bên thứ ba vào hình ảnh, các công cụ này hầu như không được viết để hoạt động trong miền vấn đề của bạn, vì vậy chúng yêu cầu các chuyển đổi thường gây mất tập trung, cồng kềnh và dễ bị lỗi.

Điều thường xảy ra là những bất tiện là nhỏ, và chúng tôi chỉ đối phó với các công cụ mà chúng tôi được cung cấp. Nhưng khi sự bất tiện là lớn, đến mức chúng làm cho cuộc sống hàng ngày của chúng ta trở nên khó khăn hơn hoặc kết quả cuối cùng dễ vỡ hơn và dễ bị lỗi hơn, đôi khi chúng tôi đưa ra các lớp trừu tượng / chuyển đổi giữa mã của chúng tôi và các công cụ mà chúng tôi sử dụng .

Các lớp trừu tượng / chuyển đổi này cung cấp dịch vụ cho mã của chúng tôi, được thể hiện theo miền vấn đề của chúng tôi và chúng ủy quyền cho các công cụ của bên thứ ba, thực hiện tất cả các chuyển đổi cần thiết trên đường đi. Khi làm như vậy, các lớp này có xu hướng trừu tượng hóa càng nhiều càng tốt về tính đặc thù của các công cụ mà chúng ta sử dụng, theo lý thuyết, chúng ta có thể thay thế một công cụ bằng một công cụ khác bằng cách sửa đổi chỉ các lớp trừu tượng / chuyển đổi, không có cần phải sửa đổi logic cốt lõi của chúng tôi.

Về chú thích, tôi không thấy làm thế nào họ có thể giúp đỡ ở đây. Trước hết, nếu bạn không sở hữu mã nguồn của các giao diện đích, thì bạn không thể thêm chú thích cho chúng. Nhưng ngay cả khi bạn bằng cách nào đó có thể thêm các chú thích vào các giao diện đích, để các chú thích hoạt động, bạn sẽ phải nhúng một số lớp trung gian giữa mã của bạn và các giao diện đích, để chặn các cuộc gọi, kiểm tra các chú thích của các phương thức đích và thực hiện chuyển đổi cần thiết. Có lẽ, bạn có thể sử dụng Spring Framework hoặc một cái gì đó giống như Thiết bị chặn của Castle Proxy Cơ chế để nhúng lớp trung gian này một cách kỳ diệu giữa mã của bạn và các thư viện, nhưng dường như tôi có thể dễ dàng viết lớp trung gian theo cách truyền thống, có kiến ​​thức sâu sắc về giao diện đích, thực hiện chuyển đổi theo cách mã hóa cứng , thời trang đơn giản, và cũng trừu tượng hóa các giao diện của các thư viện để phù hợp với nhu cầu của bạn.


0

Trước hết, bạn (hoặc nhóm của bạn) cần đồng ý về định dạng "tiêu chuẩn" mà bạn sẽ sử dụng trong mã của riêng mình. Ví dụ:

  • Mã hóa: UTF-8
  • Địa điểm: en_UK
  • Múi giờ: UTC

Chỉ sau đó, bạn mới có thể viết một lớp sẽ điều chỉnh các giá trị theo các định dạng được yêu cầu từ các phần phụ thuộc của bạn (tôi không nghĩ nó khó sử dụng).

Như Mike Nakis đã nói, tôi cũng không thấy bất kỳ lợi ích nào khi sử dụng các chú thích để giải quyết vấn đề này.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.