Cùng những quy tắc đó cho thiết kế API.Chúng ta hãy cùng xem xét một giao diện API không có mô hình từ thế giới COM:IOleCommandTarget::Exec. Giao diện này được sử dụng để giúp có thể chức năng một số loại đối tượng,và container,cái nó đang tồn tại phía trong nó,để điều những câu lệnh tới cái đối tuợng khác. Một sự triển khai ví dụ là control COM,cái liên lạc với container của nó để chỉnh sử các menu items và các thanh công cụ.Giao diện này là một phiên bản định kiểu nhẹ của một giao diện câu lệnh ,cái sử dụng một chuỗi chung chỉ ra cái sự triển khai nào phải làm. Đây là một dấu hiêu của nó: HRESULT Exec( const GUID *pgui***dGroup, // Pointer to command group DWORD nCmdID, // Identifier of command to execute DWORD nCmdExecOpt, // Options for executing the command VARIANTARG *pvaIn, // Pointer to input arguments VARIANTARG *pvaOut // Pointer to command output ); Chúng ta hãy cùng phân tích giao diện API theo những nguyên tắc đã đuọc thảo luận. Giao diện API là trực quan và dễ khám phá? Nó có phải là vị trí đầu tiên một nhà phát triẻn muốn chỉnh sửa một thanh công cụ không? Có lẽ là không,nếu như bạn không có kiến thức cơ bản về giao diện đó.Thậm chí một sự tìm kiếm tài liệu của MSDN cũng không thể thỏa mãn lúc này. Nó là đơn giản? Giao diện API này sử dụng 5 tham số cái được đặt tên rất chung chung.Sư ghi tài liệu được yêu cầu hiểu xuyên suốt cách dùng của mỗi tham số.Một API đơn giản phơi bày ý định và sự rõ ràng của nó chỉ bằng tên của đối tựong (cho ngữ cảnh) và tên của phương thức. Giao diện API là được đinh kiểu mạnh mẽ và khó nhầm lẫn? Không,những sự hay thay đổi không phải là những sự định kiểu mạnh mẽ và sự lựa chọn thực thi không phải là những sự liệt kê,mà chỉ là những DWORD chung.Các tham số có định kiểu mạnh mẽ giúp tìm lỗi tại thời điểm biên dịch thay cho lúc chạy. Giao diện API là không có những hiệu ứng bên cạnh? Thật khó để nói,nhưng một sự triên khai của API có thể làm bất kì điều gì thiếu sự kết dính.
Nó là đáng tin cậy? Quy tắc thiết kế nổi tiếng "Thiết kế tới giao diện" giúp bắt ép khả năng kiểm tra trên môt đối tượng.Do vậy,giao diện là có khả năng kiểm tra lỗi,nhưng số trường hợp kiểm tra sẽ rât lớn do thiếu tính kết dinh.Sự tin tưởng là ở mức thấp. Nó có tính nhất quán? Giao diện API này không có tính nhất quán trong đó,vì nó trả lại một HRESULT và sử dụng các GUIDs để nhận diện tập thông tin.Tuy nhiên,thật khó để xét đoán tính nhát quán mà không biét phần còn lai của giao diện của một đối tựong duọc thiêt kế ra sao? Bất kì nguòi nào đang học cách sử dụng IOleCommandTarget::Exec có thể cần những sự hướng dẫn từ một nguời bạn hay từ một cuốn sách.Giao diện API tốt nhất phải là đơn giản và dễ sử dụng mà không cần tài liệu huớng dẫn,mặc dù tài liệu có thể cần để hiểu chi tiết như kiểm soát các lỗi. Nói tóm lại,giao diện API của bạn và các giao diện API bạn đang xem xét nên dễ để sử dụng như một chiếc TIVO.Một giao diện trang nhã,nhất quán,có tính tin cậy,dễ khám phá sẽ làm cho cuộc sống của các nhà phát triển dễ thở hơn vì tăng sự hài lòng và giảm giá chi phí hỗ trợ.Nhiều giao diện trong nền tảng Microsoft .NET Framework là những ví dụ tuyệt vời.Để đạt dựoc tất cả những thiết kế này,hãy nhắm tới sự hoàn hảo khi thiết kế và xem lại bất kì các thiết kế giao diện API nào. James Waletzky là lãnh đạo nhóm phát triển cao cấp ở hãng Windows Mobile.Ngòai việc dẫn dắt một nhóm phát triển sản phẩm,James còn đam mê nâng cao kĩ năng phát triển phần mềm tại Microsoft.
EMAIL: NHABIENDICH@YAHOO.COM | | PHIENDICHVIEN@YAHOO.COM
