# 35: Nguyên tắc vàng trong thiết kế API
Thiết kế API không bao giờ dễ dàng, đặc biệt là những API lớn. Nếu bạn đang thiết kế một API mà có hàng trăm ngàn người dùng, bạn phải nghĩ về vấn đề làm thế nào để bạn có thể thay đổi nó trong tương lai và liệu việc đó có thể làm hỏng đến phần nào của client hay không? Hơn nữa, bạn phải nghĩ về sự ảnh hưởng đến từ người dùng của bạn lên bản thân. Nếu một trong những lớp của API bạn tạo ra dùng chính phương thức nội bộ, bạn phải nhớ rằng một người dùng có thể tạo lớp con từ lớp của bạn và ghi đè nó, và điều đó chính là một thảm hoạ. Bạn sẽ không còn có thể thay đổi phương thức đó nữa bởi vì một vài người dùng của bạn đã thay đổi bản chất của nó, khiến nó mang một ý nghĩa khác. Sự lựa chọn cài đặt tính năng của bạn phụ thuộc vào người dùng.
Những nhà phát triển API giải quyết vấn đề này bằng nhiều cách khác nhau, nhưng cách đơn giản nhất là khoá API(lockdown API). Nếu bạn đang làm việc với Java bạn có thể cố gắng áp dụng từ khóa final cho hầu hết các lớp và phương ử dụng là gì, bạn có thể thử thể hiện API của bạn bằng phương thức Singleton(đơn điệu) hay Static factory (dùng từ khóa static) nhờ đó bạn có thể ngừa nó khỏi bị ghi đè và sử dụng code của bạn theo cách về sau có thể giới hạn những lựa chọn của bạn. Tất cả điều này nghe có vẻ hợp lý đấy, nhưng có thật sự như thế ?
Trong thập kỷ qua, chúng ta đã dần dần nhận ra rằng tạo testing là một phần vô cùng quan trọng trong luyện tập, nhưng bài học ấy vẫn chưa thật sự tác động tích cực đến mọi ngóc ngách của ngành. Và bằng chứng cho việc ấy có ở khắp mọi nơi. Hãy chọn tuỳ ý bất kỳ một lớp nào chưa được kiểm tra và thử tạo bộ thử cho nó. Và hầu hết mọi trường hợp, bạn đều gặp rắc rối. Bạn sẽ hiểu được rằng đoạn code đó dính chặt với API như thể thống nhất không thể tách rời. Và không có một cách nào có thể sao chép những lớp của API đó để bạn có thể nhận thấy code của bạn đang tương tác với nó hay hỗ trợ giá trị trả về cho việc testing.
Theo thời gian, việc này sẽ ngày càng phát triển hơn, nhưng chỉ khi chúng ta bắt đầu nhìn nhận testing như là một trường hợp thực tế khi thiết kế APIs. Không may thay điều đó chỉ tiến bộ hơn việc testing cho code của chúng ta một chút thôi. Và đó chính là nơi để chúng ta áp dụng Nguyên tắc vàng trong thiết kế API:
Chúng ta không thể tạo ra đủ bộ thử cho API của chúng ta phát triển; chúng ta phải tạo bộ thử cho chính đoạn code dùng API của chúng ta.Và khi bạn làm điều đó, bạn sẽ biết được những trở ngại đầu tiên mà người dùng của bạn phải vượt qua khi họ muốn kiểm tra code của họ một cách độc lập.
Không có cách nào có thể giúp những nhà phát triển có thể kiểm tra đoạn code mà chúng sử dụng API của họ. “static”, “final”, và “sealed” đều không phải là cấu trúc xấu. Chúng có thể hữu dụng trong thời gian nào đó. Nhưng điều quan trọng là chúng ta phải luôn cẩn trọng đối với những vấn đề đối với testing, và để làm điều đó, bạn phải tự trải nghiệm lấy. Một khi bạn đã trải nghiệm, bạn có thể tiếp cận nó bằng cách mà bạn muốn với bất kỳ thử thách thiết kế nào khác.