Thật khó chịu khi phải xử lý các mảng liên kết lúc đang viết client code. Vấn đề gặp phải ở mảng đó chính là chúng không có bối cảnh, không có hiểu biết gì đặc biệt. Mảng thường chỉ là dữ liệu được đóng gói theo một định dạng bất tiện, và tệ hơn hơn là chúng sẽ ràng buộc bạn vào một triển khai cụ thể.
Trả về các mảng có dữ liệu đồng nhất không phải là một ý tồi, nhất là khi trả lại một mảng của một số loại đối tượng (objects). Dù ngay cả khi bạn không chắc rằng nó chỉ chứa một số loại dữ liệu nhất định qua API.
Mảng có thể hoạt động như một đại diện nội bộ của dữ liệu ở vài lớp và nhấn mạnh là chỉ trong nội bộ.
Nhưng vấn đề ở đây đó là những mảng đa chiều (multidimensional array) khó chịu với các chuỗi được mã hóa cứng (hardcoded) làm khóa.
Nó sẽ như thế này:
Ở đây chỉ có ba giá trị được khóa trong một mảng kết hợp.
Thử thách trong trường hợp này là ta không thể biết được cấu trúc chính xác của mảng này. Khi ta viết code phía khách, ta thường phụ thuộc vào việc triển khai sendFiles (). Ta phải biết chính xác các khóa (key) là gì và loại dữ liệu nào đằng sau các khóa đó.
Trong OOP, chúng ta không nên quan tâm đến chi tiết triển khai của các lớp (class) khác, mà chỉ nên quan tâm đến các giao diện.
Nhiều khi bạn còn va phải một vài lỗi nghiêm trọng:
Bây giờ, trả lại đống này từ các phương thức riêng tư là một chuyện rất khác. Khi bạn bắt đầu thiết kế API công khai của mình như thế này, bạn đã đặt dấu chấm hết cho tất cả hi vọng. Hiển nhiên, bạn đang xử lý một cơ sở code thủ tục (procedural codebase). Trong cơ sở code thủ tục, mọi thứ đều là dữ liệu và có thể (và sẽ) bị chi phối.
Vấn đề của trường hợp trên chính là thiếu bối cảnh. Sẽ ra sao khi bạn nhận someArray và someObject cùng nhau? Tại sao chúng lại trả về cùng nhau? Rõ ràng là việc triển khai processStuff () sẽ biết được cách nó được sử dụng. Vì vậy, nó không được thiết kế để phù hợp với một số code phía khách. Code phía khách được kết hợp chặt chẽ với việc triển khai processStuff ().
Trong nhiều trường hợp, có một số nhầm lẫn về cách xác định trách nhiệm. Code thực hiện điều gì đó và trả lại một số dấu hiệu cho thấy nó đã thành công với khách hàng. Không có nhiều sự tin tưởng giữa máy khách và máy chủ. Khách hàng đang hoang tưởng về chất lượng công việc của máy chủ.
Chúng ta có thể làm gì cho ví dụ đầu tiên tốt hơn? Các đối tượng giá trị. sendFiles () sẽ mang tính biểu đạt hơn rất nhiều bằng cách sử dụng các đối tượng giá trị.
Chúng ta sẽ cập nhật FileSender và những triển khai của nó.
Bây giờ chúng ta có thể dựa vào interface của SenderReport thay vì triển khai FileSender::sendFiles (). Bây giờ chúng ta đã có bối cảnh. Ngoài ra, chúng ta có thể thực hiện thay đổi việc triển khai FileSender một cách tự do.
--
Cuối cùng, đừng trả về mảng kết hợp từ API công khai. Hãy đánh giá lại kể cả khi phải trả về giá trị. Và nếu bắt buộc thì cũng trả về cái khác có giao diện mà bạn và người dùng có thể tin tưởng được.
Tổng hợp việc làm IT - Software trên VietnamWorks
VietnamWorks InTECH
Theo dev.to
TẠO TÀI KHOẢN MỚI: XEM FULL “1 TÁCH CODEFEE” - NHẬN SLOT TƯ VẤN CV TỪ CHUYÊN GIA - CƠ HỘI RINH VỀ VOUCHER 200K