نود و هفت چیزی که هر برنامه نویسی باید بداند: قانون طلایی طراحی ای پی آی

[*بانو بهار*]

به طور کلی، طراحی API کار دشواری است مخصوصاً اگر قصد طراحی برای سیستم‌های بزرگی را داشته باشیم؛ اگر شما قصد طراحی API را در سر می پرورانید که در آینده یی نه چندان دور چندین هزار کاربر از API شما استفاده خواهند کرد، حتماً می بایست به این موضوع هم فکر کنید که تغییرات احتمالی در آینده چه اتفاقی برای کاربران رقم خواهد زد و اگر یک تغییر کوچک در API خود دادید، کاربران چگونه می بایست با این تغییر کنار بیایند!

علاوه بر این، توجه به این نکته که کاربران API مثلاً چگونه با Override کردن برخی متدهای کلاس‌های API شما، سرویس تان را تحت تأثیر قرار خواهند داد نیز حائز اهمیت است. یکی از استراتژی هایی که توسعه دهندگان از آن تبعیت می‌کنند، محدود کردن سطح دسترسی کاربران است؛ به طور مثال، در زبان جاوا بسیاری از متدها را می‌توان final کرد و در زبان سی شارپ، می‌توان از کیورد sealed استفاده کرد تا جلوی دستکاری سیستم توسط کاربران را گرفت اما این تمام ماجرا نیست.

ما با نوشتن Unit Testها، تا حدودی می‌توانیم از صحت عملکرد API خود اطمینان حاصل کنیم اما این کافی نیست! قانون طلایی طراحی ای پی آی حاکی از آن است که «علاوه بر نوشتن یونیت تست برای ای پی آی، خود را جای کاربران ای پی آی گذاشته و اقدام به استفاده ی واقعی از ای پی آی کنید!» که در چنین شرایطی، خواهید دید که کاربران با چه مشکلاتی دست و پنجره نرم خواهند کرد، مشکلات احتمالی چیست، راه های در رو کدامند و