#Defensive Code in C - قسمت سوم
اندازه‌ی قلم متن
تخمین مدت زمان مطالعه‌ی مطلب: شش دقیقه

رفع مشکلات:  

در قسمت قبل با ذکر یک مثال و بیان مشکلات آن از دیدگاه اصول Defensive Code قصد داشتیم که مساله را روشن‌تر کنیم. مواردی که در قسمت قبل ذکر شدند، به ساده‌ترین شکل ممکن بیان  شدند و شما به راحتی با بررسی این موارد و تفکر در کد‌های خود، می‌توانید این موارد را در کدی که خودتان می‌نویسید رعایت کنید. حل پیچیدگی‌های موجود در کد قبل، با در نظر گرفتن اصول مذکور و اصول‌های طراحی مختلف می‌تواند به روش‌های مختلفی انجام گیرد. برای مثال می‌توان برای هر یک از کارهایی که کد مثال قبل انجام می‌دهد، یک کلاس مجزا ایجاد نمود و اصول مذکور را در آن رعایت کرد. درنهایت این کلاس‌ها را در قالب یک Class Library دسته بندی کرد.

Predictability: 

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

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

بر اساس اصول (GIGO (Garbage in-Garbage out در برنامه نویسی متدی که ورودی‌های نامعتبر به آن پاس داده شوند، خروجی‌های نامعتبری هم پس خواهد داد. بنابراین برای جلوگیری از این مسئله باید از ورود ورودی‌های نامعتبر به متد‌ها جلوگیری کرد. گارد‌ها از ورود مقادیر نامعتبر به متد‌ها جلوگیری خواهند کرد و در نتیجه خروجی مناسب و قابل پیش بینی از متد گرفته خواهد شد.  برای جلوگیری از ورود داده‌های نامعتبر، باید با استفاده از این دستورات که در ابتدای متد قرار داده می‌شوند، از ورود داده‌های نامعتبر جلوگیری کرد. به این دستورات Guard Clauses گفته می‌شود. غیر از این مساله، کاهش دادن تعداد پارامتر‌ها و قراردادن قانونی برای تعیین اولویت پارامتر‌های متدها (برای مثال با توجه به اهمیت) می‌تواند به افزایش Predictability متد‌ها بسیار کمک کند. با پیروی کردن از این اصول ساده شما می‌توانید میزان خطاهایی که از پارامتر‌های ورودی منشاء می‌گیرند را کاهش دهید.

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

با استفاده از این Application می‌خواهیم مفاهیمی را که بیان کردیم، به صورت کاربردی نمایش دهیم. کدی این محاسبه را برای ما انجام می‌دهد، در ذیل نمایش داده شده و در قالب یک متد تعیین شده است. 

private decimal CalculatePercentOfGoalSteps (string goalSteps, string actualSteps)
{
            return (Convert.ToDecimal(actualSteps) / Convert.ToDecimal(goalSteps)) * 100;
}

این متد دارای دو پارامتر از نوع string می باشد و نتیجه هم در قالب یک مقدار decimal بازگشت داده خواهد شد. این جمله کلیتی از متد را بیان خواهد کرد. نحوه‌ی فراخوانی این متد هم در کد ذیل آورده شد است. 

private void Calculate_Click(object sender, EventArgs e)
{
  var result =CalculatePercentOfGoalSteps (stepGoalForTodayTxt.Text, numberOfStepsForToday.Text);
            lblResult.Text = "شما به" + result + "% از هدف تان رسیده اید";
}

حال Application را اجرا کرده و نتیجه کار را مشاهده می‌کنیم. برای مثال شکل ذیل:

   

در این مثال با توجه به مقادیر وارد شده، به 40 درصد از هدف مورد نظر رسیده‌ایم. اما هدف از بیان این مثال، این نیست که مشخص گردد که ما چقدر به هدفمان نزدیک شده‌ایم. بلکه هدف مسایل دیگری است. در نظر بگیرید که بجای 5000، صفر را وارد کنید. در این حالت با یک Exception روبرو می‌شویم:

همانطور که در شکل بالا مشاهده می‌کنید، خطای Divide by zero رخ داده است. برای رفع این خطا و جلوگیری از رخداد این خطا، می‌توان کد ذیل را پیشنهاد داد. 

private decimal CalculatePercentOfGoalSteps(string goalSteps, string actualSteps)
{
            decimal result =0;
            var goalStepsCount = Convert.ToDecimal(goalSteps);
            if (goalStepsCount>0)
            {
                result = (Convert.ToDecimal(actualSteps) / goalStepsCount) * 100;
            }
            return result;
}

با تغییر کد به این صورت مشکل  Exception  بالا حل می‌شود، اما باز هم مشکل دیگری وجود دارد. فرض کنید همانند شکل ذیل textbox اول را خالی کنیم و بعد از آن سعی در محاسبه داشته باشیم،

باز هم یک  Exception دیگر

علت بوجود آمدن این مشکل این است که ما در کد امکان خالی بودن پارامتر‌های متد را در نظر نگرفته‌ایم و پیش بینی‌های لازم صورت نگرفته است بنابراین دستور Convert  .با مشکل مواجه شد. برای حل این مشکل می‌توان به جای Convert از decimal.Tryparse استفاده کرد.

private decimal CalculatePercentOfGoalSteps(string goalSteps, string actualSteps)
        {
            decimal result = 0;
            decimal goalStepsCount = 0;
            decimal.TryParse(goalSteps, out goalStepsCount);
            decimal actualStepsCount = 0;
            decimal.TryParse(actualSteps, out actualStepsCount);
            if (goalStepsCount>0)
            {
                result = (actualStepsCount / goalStepsCount) * 100;
            }
            return result;
        }

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

برای اینکه بتوانیم این کد به راحتی debug کنیم باید از مفهوم Fail Fast استفاده کنیم . این مفهوم قابلیتی را در کد ایجاد می‌کند که در صورتی که کد، داده‌های نامعتبری را دریافت کرد، سریعا اجرای آن متوقف می‌شود و همزمان نیز اطلاعاتی در مورد خطا در اختیار کاربر قرار می‌دهد. برای این منظور با قرار دادن یکسری Guard Clauses، کد بالا را همانند شکل ذیل تغییر خواهیم داد.

private decimal CalculatePercentOfGoalSteps(string goalSteps, string actualSteps)
        {
            decimal goalStepsCount = 0;
            decimal actualStepsCount = 0;
            /// اطمینان حاصل می‌کنند که پارامتر‌های ورودی دارای مقدار هستند 
            if (string.IsNullOrWhiteSpace(goalSteps)) throw new ArgumentException("مقدار هدف باید وارد شود", "goalSteps");
            if (string.IsNullOrWhiteSpace(actualSteps)) throw new ArgumentException("مقدار واقعی باید وارد شود", "goalSteps");

            ///اطمینان حاصل می‌کنند که مقادیر وارد شده حتما عددی هستند
            if (!decimal.TryParse(goalSteps, out goalStepsCount)) throw new ArgumentException("مقدار هدف باید عددی باشد", goalSteps);
            if(!decimal.TryParse(actualSteps, out actualStepsCount)) throw new ArgumentException("مقدار واقعی باید عددی باشد", actualSteps);

            ///اطمینان حاصل می‌کند که مقدار متغیر نباید صفر باشد
            if (goalStepsCount <= 0) throw new ArgumentException("مقدار هدف نباید صفر و یا کمتر از صفر باشد", "goalStepsCount");
            return (actualStepsCount / goalStepsCount) * 100;
        }

ایجاد کردن این تغییرات در متد باعث افزایش خوانایی کد می‌شود و هدف متد را روشن‌تر بیان خواهد کرد. اضافه کردن این کدها به دلیل اینکه تمامی شرایط تست را تعیین خواهیم کرد Test-ability کد را بالا می‌برد. اضافه کردن کد‌های بالا به برنامه کمک خواهد کرد که شرایط خطا در برنامه به درستی هندل شود و به طبع آن تصمیمات مناسبی گرفته شود و در نهایت Predictability متد‌ها و کل برنامه را افزایش می‌هد.

  • #
    ‫۸ سال و ۹ ماه قبل، دوشنبه ۱۴ دی ۱۳۹۴، ساعت ۱۸:۴۹
    ایمن سازی کدها قبول؛
    متد نهایی دو وظیفه رو انجام میدهد. یکی اعتبار سنجی داده‌ها و دومی محاسبه هدف نهایی در صورت ممکن.
    یعنی باید تمام متدها بصورت درونی داده‌ها را خودشون اعتبار سنجی کنند؟
    آیا اصل SRP رو نقض نکردیم؟
    آیا اینچنین کد نوشتن‌ها باعث تکرار کد نمیشوند؟
    نوشتن آزمون واحد برای متدهای چند مسولیتی به چه صورت خواهد بود؟
    در پروژه واقعی با تعداد متدهای زیاد و لایه‌های متعدد به چه صورت باید رفتار کرد؟
    نکته ای که قابل تأمل هست اینه که متد ما دو عدد از نوع رشته ای می‌گیرد و خروجی عددی تولید میکند. شاید با رفع این مشکل بشه کد تمیزتر و ایمن‌تری نوشت. 
    • #
      ‫۸ سال و ۹ ماه قبل، دوشنبه ۱۴ دی ۱۳۹۴، ساعت ۲۱:۰۶
      - دریافتی از کاربر به کمک textbox، یک رشته هست.
      - تمام فریم ورک‌های درست و حسابی مثل EF یک چنین بررسی‌هایی رو در تمام متدهاشون دارند. برای مثال به سورس EF مراجعه کنید. یک کلاس Check دارند که همه‌جا از آن استفاده شده (البته اگر فکر می‌کنید throw new ArgumentNullException  یعنی تکرار کد).
      - یک شیء مسئول اعتبار خودش هم هست و نباید بتوان آن‌را در حالت غیرمعتبر وهله سازی کرد. این مساله ناقض SRP نیست. SRP در مورد دلایل تغییر یک کلاس صحبت می‌کند. آیا کلاسی که بررسی می‌کند ورودی‌های دریافتی آن معتبر هستند یا خیر، چندین دلیل برای تغییر دارد؟ خیر.
      • #
        ‫۸ سال و ۹ ماه قبل، سه‌شنبه ۱۵ دی ۱۳۹۴، ساعت ۰۳:۰۶
        حرف شما درست.
        اما فرض کنید برای تولید خروجی باید بین چندتالایه حرکت کنیم. طبیعتاً باید توی هرمتدی که در هر لایه صدا زده می‌شود این اعتبار سنجی انجام گیرد. من توی ذهنم دنبال راهکاری میگردم که این عملیات را تجمیع و خلاصه کنم. شاید یک خط کد if then throw یه چند کلمه کد کوچک بیشتر نباشند ولی قسمتی از منطق کل رو پیاده سازی میکند. کم یا اضاف شدن همین چند کلمه در یک پروژه بزرگ که اصول رو رعایت نکند فاجعه است بخصوص اگر برنامه عادت به تغییر هم داشته باشد.
        - این متد حداقل دو دلیل برای تغییر دارد. ۱- اگر فاکتور جدیدی به فرمول اضافه شود(فرمول تغییر کند). ۲− محدوده داده هایی ورودی تغییرکند. در مثال بالا تولید درصد بیش از صد ممکن است، این سیاست خیلی تغییر پذیر است.
        میشود قوانین و تبدیل رو در یک متد اعمال کنیم و فرمول را در یک متد دیگر.
        بنظر من میشود با ایجاد کمی اعتماد، سربار این اعتبارسنجی‌ها رو کم کرد. بدین ترتیب که متدهای عمومی رو ایمن کنیم و در صورت تأیید شدن، عملیات را خصوصی انجام داد. دراینحال فقط متدهای عمومی نیاز به اعتبارسنجی خواهند داشت و متدهای خصوصی را میتوان با خیالی راحت‌تر نوشت.
        بنظر چنین کاری شدنی ست؟ 
        • #
          ‫۸ سال و ۹ ماه قبل، سه‌شنبه ۱۵ دی ۱۳۹۴، ساعت ۰۳:۳۳
          - دلایل تغییری که نام بردید به معنای نقض SRP نیست (چون در نهایت به نتیجه‌ی کلاس دقت می‌شود).
          - کل دات نت و تمام کتابخانه‌های معتبر نوشته شده برای آن بر اساس اصل fail fast ایی که اینجا توضیح داده شد کار می‌کنند. حداقل بررسی کدهای ASP.NET MVC و EF موید این مساله هستند.
          - روش‌های زیادی برای انجام اینکار هست. از صدور استثناء تا مباحث AOP تا Code contracts و غیره.
    • #
      ‫۸ سال و ۹ ماه قبل، دوشنبه ۱۴ دی ۱۳۹۴، ساعت ۲۱:۴۹
      -طبق ساده‌ترین اصول برنامه نویسی و طراحی نرم افزار هر متد باید جهت انجام دادن فعالیت‌های خود  قبل از انجام عملیات داده‌های ورودی را Validate کند و در صورتی که دیتای ورودی با دیتای مورد انتظار سنخیتی نداشت خطای لازم را صادرکند.
      -این مسئله باید بر روی متد هایی که بر روی داده‌ها اعمالی را انجام داده یا متد هایی که فرآیندهای بیزینسی را پیگیری می‌کنند انجام شود
      -به نظر شما متدی که داده‌های مربوط به تنها  کاری که انجام می‌دهد را اعتبار سنجی کند، اصل SRP را نقض کرده است!؟
      -شما می‌توانید در پروژه‌های اصلی کد‌های مربوط به اعتبار سنجی(اعتبارسنجی‌های استاندارد) را در قالب یک ساختار کلاس بندی شده یا بصورت Aspect در متد‌های خود استفاده کنید تا از تکرار کدها جلوگیری کنید.
      - در بالا هم ذکر کردم که این متد فقط یک عمکرد بیزینسی را انجام می‌دهد، و قسمت مربوط به اعتبار سنجی داده‌های ورودی یک مسئولیت جدید محسوب نمی‌شود.
      -اینکه پارامتر متد به صورت string در نظر گرفته شده اند به خاطر ذکر مثال می‌باشد، این مسئله هم کاملا بدیهی است که در نظرگرفتن این پارامتر بصورت decimal اعتبار سنجی‌های اضافی را از بین می‌برد.