SonaOps

در سري پست هاي تعريف اصول SOLID  با اصل Single Responsibility اصل Open Closed اصل Liskov Substitution اصل Interface segregation آشنا شديم در اين پست پنجمین اصل يعني Dependency inversion رو برسي ميكنيم. هدف Dependency inversion اینه که کلاس های سطح بالا نبایستی به صورت مستقیم وابسته به کلاس های سطح پایین باشن بلکه رابطه ی بین کلاس ها بایستی براساس Abstract ها یا Interface ها باشه. بعنوان مثال اگه کلاس سطح بالای سیستم رو business logic بدونیم و این سطح وابسته به جزئیات سطح پایین مثلا ذخیره در بانک اطلاعاتی باشه استفاده مجدد از کلاس های business logic مارو کم میکنه انجام تست روی کلاس های business logic ما سخت میشه عکس زیر برگرفته از کتاب Dependency Injection in .NET هست که Dependency Injection (الگويي براي رعايت اين اصل) رو بخوبی توضیح داده مدير يك هتل ارزان قيمت براي اينكه سشوار دزيده نشه اونو به پريز بسته و اين يعني وابستگي بين سشوار و پريز تغيير در هركدوم ;ديگري رو تحت تاثير قرار ميده. و اما براي مثال عملي فرض كنيد کلاسی بنام GetMessag...

در سري پست هاي تعريف اصول SOLID  با اصل Single Responsibility اصل Open Closed اصل Liskov Substitution آشنا شديم در اين پست چهارمین اصل يعني Interface Segregation رو برسي ميكنيم. همنطور که قبلا اشاره کردم هدف این اصل اینه که اینترفیس بزرگ رو براساس استفاده کننده های اون اینترفیس و اهداف مختلف به اینترفیس های کوچکتر تبدیل کنیم و در نتیجه یک استفاده کننده از اون اینترفیس (مثلا یک کلاس) رو مجبور به پیاده سازی متدهای که بهشون نیاز نداره نکنیم و کلاس های پیچیده هم بجای استفاده از یک اینترفیس بزرگ از چندین اینترفیس استفاده کنن. توجه کنید که اگه ما کلاسی رو مجبور کنیم مثلا یک متد رو که اصلا بهش نیاز نداره پیاده سازی کنه و برای مثال بیاد تو اون متد NULL برگردونه یا مثلا Exception صادر کنه علاوه بر نقض اصل  Interface Segregation ;در ارث بری ما اصل Liskov Substitution رو هم نقض کردیم. به عکس زیر توجه کنید فرض کنید تو یک پروژه Web بخواهید ASP.NET Membership رو شخصی سازی کنید و مثلا قسمت بازیابی با ایمیل رو تغییر بدید تقریبا میشه گفت بیخیال این کار میشید ...

در سري پست هاي تعريف اصول SOLID  با اصل Single Responsibility اصل Open Closed آشنا شديم در اين پست سومين اصل يعني Liskov substitution رو برسي ميكنيم. هدف اين اصل اينه كه در ارث بري كلاس مشتق شده بايد به گونه اي طراحي بشه كه در صورت نياز با كلاس پايه ي خودش قابل تعويض باشه. مثال ي كه تو تعاريف اين اصل معمولا مطرح ميشه آيا مربع يك مستطيل هست؟ در منطق هندسه یک مربع نوع خاصی از مستطیل هست که دارای چهار ضلع مساوی میباشد ولي در شي گرائي داستان چيز ديگس… در واقع ما با ارث بردن كلاس مربع از كلاس مستطيل اصل Liskov substitution رو نقض ميكنيم چون با فرض وجود متد هاي setWidth و setHeight در كلاس مستطيل ما مجبوريم اين متد ها رو به گونه ي در كلاس مربع تغيير بديم كه طول و عرض يكي بشه و از اين رو كلاس مشتق شده يعني مربع قابل تعويض با كلاس پايه يعني مستطيل نيست و… اين اصل با اصل Open Closed ارتباط داره توجه كنيد اگه شما نتونيد از كلاس مشتق شدتون بجاي كلاس پايه استفاده كنيد در واقع و بنوعي اصل Open Closed رو رعايت نكرديد. و اما براي مثال عملي فرض كنيد كلا...

در سري پست هاي تعريف اصول SOLID  با اصل Single Responsibility آشنا شديم در اين پست دومين اصل يعني Open Closed رو برسي ميكنيم. اين اصل ميگه يك كلاس بايد براي توسعه باز و براي تغيير بسته باشه بنابراين طراحي شما بايد به گونه ي باشه كه براي اضافه كردن يك قابليت جديد به كلاستون حداقل تغيير ممكن رو تو كلاستون داشته باشيد.در واقع بايد براي اضافه كردن قابليت جديد از كلاس جديد استفاده كنيم چون فرض شده تغيير تو كلاسي كه قبلا ساخته شده و داره ازش استفاده ميشه منجر به نتايج ناخواسته (باگ و…) در استفاده كننده هاي اين كلاس (مثلا يك كلاس ديگر) ميشه. ابهامات احتمالي كلاسي كه نبايد تغيير كنه پس نياز به تست واحد هم نداره؟ اگه كلاس باگ داشت چي(نياز به تغيير)؟ جواب بعضي از اين ابهامات + و + (شايد نادرست) حتي اگه شما اصل Open Closed رو رعايت كرده باشيد امكانش هست سهوا يك كلاس رو تغيير بديد پس تست واحد رو داشته باشد! كلاسي كه براي اولين بار طراحي شده براي صحت عملكرد بايد تست بشه پس شما تست واحد رو از قبل داريد(توجيه خوبي براي اولين ابهام) مورد استفاده اين اصل ب...

تو دنیای برنامه نویسی و البته شیء گرایی SOLID مجموعه ی از 5 قاعده (اصل) ابتدایی شامل Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion هست و توسط رابرت مارتین در اوایل سال 2000 معرفی شده و … شاید اکثرا با تعاریف این اصول آشنا باشین (درست یا غلط)  ولی بشخصه زیاد با مثال های که تو تاپیک های از این دست زده میشه مشکل دارم(انواع و اقسام اشکال هندسی)  قصد دارم این اصول رو با مثال های نزدیکتر با دنیای واقعی شرح بدم منظور مثال های از برنامه های تجاری(البته اگه پیدا کنم) قبل از شروع از اساتید و دوستانی که (شاید) این پست رو میبینن درخواست میکنم در صورت خطا (برداشت غلط و…) تو مطالب و مثال های ارائه شده منو راهنمایی کنن. اصل Single responsibility تعریف کردن این اصل خیلی راحته ولی انجامش در عمل سخته و تقریبا میشه گفت مثل امنیت همیشه %100 نیست. این اصل میگه هر کلاس فقط باید یک مسئوليت داشته و همچنیا میگه هر کلاس باید یک دلیل برای تغییر داشته باشه همونطور که گفتم راحت ت...