اصل استحکام

June 2020

ویدیویی وجود ندارد

 

در حین توسعه اولیه اینترنت ، واضح بود كه بسیاری از پروتكلی كه طراحی می شوند باید با برنامه های مختلف بی شماری پیاده سازی شوند و همه آنها برای یک وظیفه واحد باید با هم كار كنند. به دست آوردن مشخصات مناسب مهم بود ، اما گرفتن مردم برای اجرای آنها به صورت متقابل از اهمیت بیشتری برخوردار بود.

 

در 1980 ، پروتکل کنترل انتقال (TCP) با RFC 761 ، 3 به روز شد که شامل یکی از مهمترین رهنمودها در طراحی پروتکل بود: در آنچه انجام می دهید محافظه کار باشید, در آنچه دیگران قبول می کنید آزاد باشید. این "یک اصل کلی استحکام" نامیده شد ، اما پس از نویسنده آن ، جان پستل ، به عنوان قانون پستل نیز گفته می شود.

 

به راحتی می توان فهمید که این راهنما در هنگام هدایت پیاده سازی پروتکل های طراحی شده برای اینترنت مفید است. در اصل ، برنامه هایی که از این اصل پیروی می کنند، نسبت به برنامه‌هایی که از این اصل پیروی نمیکنند، با اطمینان بیشتری کار کنند. با رعایت قوانین هنگام تولید خروجی ، این خروجی توسط نرم افزاری قابل درک نیست که لزوماً مشخصات را به طور کامل دنبال نمی کند. به همین ترتیب ، اگر شما اجازه تغییر در داده های ورودی را بدهید ، اجرای نادرست هنوز می تواند داده هایی را برای شما ارسال کند که می توانید درک کنید.

 

با فراتر از طراحی پروتکل ، کاربرد واضح این اصل در توابع است. اگر می توانید کمی در ارزشهایی که به عنوان آرگومان قبول می کنید کمی آزاد باشید ، می توانید در کنار کدی دیگر که انواع مختلفی از مقادیر را ارائه می دهد ، استفاده را در اختیار داشته باشید. یک مثال معمولی تابعی است که اعداد نقط شناور را می پذیرد ، درصورتیکه عدد صحیح یا اعشاری داده شود می توانند درست کار کنند ، زیرا هر دو قابل تبدیل به شناور هستند.

 

مقدار بازده همچنین برای ادغام یک عملکرد با کدی که آن را صدا می کند از اهمیت بالایی برخوردار است. یکی از روش های متداول این بازی این است که وقتی یک عملکرد نمی تواند آنچه را که می توان انجام دهد را انجام دهد و بنابراین نمی تواند یک مقدار بازده مفید را تولید کند. در این موارد برخی از برنامه نویسان تصمیم به بازگشت هیچکدام نخواهند گرفت ، اما پس از آن کدی را که وظیفه نامیده می شود شناسایی کرده و آن را جداگانه اداره می کند. اصل سامورایی توصیه می کند که در این موارد، کد باید یک استثناء را جمع کند تا یک مقدار غیرقابل استفاده را برگرداند. از آنجا که پایتون به طور پیش فرض None را برگردانده ، اگر هیچ مقدار دیگری بازگردانده نشده باشد ، مهم است که به طور صریح مقدار بازده را در نظر بگیرید.

 

هرچند همیشه تلاش برای یافتن مقدار بازده ای که هنوز هم نیازها را برآورده می کند ، مفید است. به عنوان مثال ، برای تابعی که برای یافتن تمام موارد a طراحی شده است کلمه خاص در متن ، چه اتفاقی می افتد که کلمه داده شده به هیچ وجه یافت نمی شود؟ یکی از گزینه های بازگشت None است, گزینه دیگر صدا زدن یک استثنا است. اگر قرار باشد این تابع همه موارد را برگرداند ، باید یک لیست یا یک تکرار کننده را برگرداند ، بنابراین یافتن هیچ کلمه ای یک راه حل آسان را ارائه نمی دهد: یک لیست خالی یا یک تکرار کننده را برگردانید که هیچ چیزی تولید نمی کند. نکته اصلی اینجاست که کد فراخوانی همیشه می تواند از نوع خاصی از مقدار انتظار داشته باشد و تا زمانی که عملکرد از اصل استحکام پیروی کند ، همه چیز درست کار خواهد کرد.

 

اگر مطمئن نیستید که کدام روش بهتر است ، می توانید دو روش مختلف ارائه دهید ، هرکدام مجموعه ای از اهداف متفاوت را ارائه می دهند. علاوه بر تعامل با کد ، استحکام در هنگام برخورد با افرادی که از این نرم افزار استفاده می کنند نیز اعمال می شود. اگر برنامه ای را می نویسید که ورودی از سوی انسان را بپذیرد ، خواه متن باشد و هم موس مبتنی بر ماوس ، همیشه حسن وفادار بودن به آنچه به شما داده می شود مفید است.  شما می توانید اجازه دهید آرگومان های خط فرمان به طور غیرقابل تنظیم مشخص شود ، دکمه ها را بزرگتر کنید ، اجازه دهید پرونده های ورودی کمی ناقص باشند یا هر چیز دیگری که به افراد کمک می کند از نرم افزار استفاده کنند بدون اینکه قربانی بودن آن صریح باشد.

ارسال نظر

اگر قراره سوالی بپرسید که داخلش کد هست، بهتره از کدتون عکس بگیرید و به ایمیلی که پایین نوشتم بفرستید