19: Convenience Is not an -ility

Nhiều điều đã được đề cập khi nói về tầm quan trọng và thách thức của việc thiết kế API tốt. Thật khó để thành công ngay từ lần đầu và thậm chí còn khó khăn hơn để thay đổi sau này. Đại khái nó giống như việc nuôi dạy một đứa trẻ. Hầu hết các lập trình viên có kinh nghiệm đã học được rằng một API tốt tuân theo mức độ trừu tượng nhất định, thể hiện tính nhất quán, tính đối xứng và hình thành từ vựng cho một ngôn ngữ. Than ôi, nhận thức được các nguyên tắc hướng dẫn không tự động chuyển thành hành vi thích hợp. Ăn nhiều đồ ngọt không tốt cho bạn.

Thay vì thuyết giảng, tôi muốn chọn một chiến lược thiết kế API cụ thể, một chiến lược mà tôi đã gặp nhiều lần: tranh luận về sự thuận tiện. Nó thường bắt đầu bằng một trong những suy nghĩ sau:

• Tôi không muốn các class khác phải thực hiện hai call riêng biệt chỉ để thực hiện một việc.
• Tại sao tôi phải tạo thêm một phương thức khác nếu nó gần giống với phương thức này? Tôi chỉ cần thêm một lệnh switch đơn giản.
• Nhìn xem, rất dễ: Nếu tham số chuỗi thứ hai kết thúc bằng “.txt”, phương thức sẽ tự động giả định rằng tham số đầu tiên là tên tệp, vì vậy tôi thực sự không cần đến hai phương thức.

Mặc dù có chủ đích tốt, các đối số như vậy có xu hướng làm giảm khả năng đọc code sử dụng API. Một phương thức như parser.processNodes(text, false); hầu như vô nghĩa nếu như không biết cách thực hiện hay tham khảo tài liệu. Phương thức này có thể được thiết kế để thuận tiện cho người triển khai, không phải cho caller. “Tôi không muốn caller phải thực hiện hai call riêng biệt” được dịch thành “Tôi không muốn mã hóa hai phương thức riêng biệt”. Về cơ bản tiện lợi không có gì sai nếu đó là liều thuốc giải cho sự tẻ nhạt, vụng về hoặc phiền phức. Tuy nhiên, nếu chúng ta suy nghĩ kỹ hơn một chút, thuốc giải cho những triệu chứng trên là sự hiệu quả, tính nhất quán và sự thanh lịch, chứ không nhất thiết phải là tiện lợi. Các API được cho là sẽ che giấu sự phức tạp tiềm ẩn, vì vậy thiết kế API tốt sẽ đòi hỏi nhiều cố gắng.

Phép ẩn dụ coi API như một ngôn ngữ có thể hướng chúng ta tới các quyết định tốt hơn trong những tình huống tương tự. Một API nên cung cấp ngôn ngữ, cung cấp cho class tiếp theo lượng từ vựng đủ để hỏi và trả lời những câu hỏi hữu ích. Điều này không có nghĩa là nó sẽ cung cấp câu trả lời chính xác cho mỗi câu hỏi. Vốn từ vựng đa dạng cho phép chúng ta thể hiện sự tinh tế trong ngữ nghĩa. Ví dụ: chúng tôi muốn nói chạy thay vì đi bộ, mặc dù về cơ bản nó giống nhau, chỉ khác ở tốc độ. Vốn từ vựng API nhất quán và được suy nghĩ kỹ sẽ giúp code trở nên cảm tính hơn và dễ hiểu hơn trong layer tiếp theo. Quan trọng hơn, vốn từ tổng hợp cho phép lập trình viên sử dụng API theo những cách mà bạn không hề nghĩ tới- thực sự rất tiện lợi cho người dùng API!

Lần tới khi bạn muốn gộp một vài thứ lại với nhau thành một phương thức API, hãy nhớ rằng tiếng Anh không có một từ mang nghĩa MakeUpYourRoomBeQuietAndDoYourHomeWork, mặc dù nghe có vẻ thuận tiện cho hoạt động thường xuyên được yêu cầu như vậy.