جلسه سوم دوره آموزشی domain driven design به تدریس مهندس علیرضا ارومند با موفقیت برگزار شد.
مباحثی که در این جلسه مطرح شد به شرح ذیل است:
1- الگوهای طراحی نرم افزار
در سومین جلسه از دوره DDD مباحث پیاده سازی را شروع کردیم و قبل از شروع مباحث DDDابتدا به معرفی الگوهای طراحی نرم افزار و اصول برنامه نویسی شی گرا پرداختیم. در ادامه مباحثی که در این جلسه مورد بررسی قرار گرفت را مشاهده می‌کنید.
در قسمت ابتدایی اصول SOLID را معفری کردیم. ابتدا بررسی کردیم که اصول SOLID به طور کلی چیست و چه کاربردی دارد؟ در این جلسه توضیح داده شد که اصول SOLID توسط آقای Robert cMartinجمع آوری شده و منتشر شده است و از سر نام موارد زیر تشکیل شده است.
- Single Responsibility: هر واحد برنامه تنها یک دلیل برای تغییر باید داشته باشد.
- Open/Close Principle: واحد های برنامه باید طوری توسعه داده شوند که برای امکان توسعه آن‌ها بدون تغییر آن‌ها وجود داشته باشد.
- Liskov Substitution: کلاس‌های فرزند می بایست قابلیت جایگزینی کلاس‌های والد را داشته باشند
- Interface Segregation: اینترفیس‌های تک منظوره به مراتب بهتر است از یک اینترفیس چند منظوره است
- Dependency Inversion: باید بتوانیم وابستگی بین اشیا را از طریق تزریق وابستگی کاهش دهیم.
بعد از بررسی اصول SOLID نوبت به بررسی الگوهای طراحی نرم افزار رسید. ابتدا منظور از الگو را بیان کردیم و بعد از آن به بررسی دسته بندی‌های مختلف الگوهای توسعه پرداختیم و در نهایت با الگوهای GO4 آشنا شدیم. بعد از آشنایی با تاریخچه نوبت به بررسی چند الگو رسید که در ادامه با این الگو‌ها آشنا می‌شویم.
الگوی Facade
الگوی Facade اولین الگویی بود که در این قسمت با آن آشنا شدیم. صورت مسئله این است که ما برای انجام یک عملیات و دریافت خروجی مراحل مختلفی باید سپری کنیم و در کل شاید مجبور باشیم چندین شی ایجاد کنیم. توابع مختلفی صدا بزنیم و خروجی های مختلفی دریافت کنیم تا در نهایت به خروجی دلخواه برسیم. خوب در چنین شرایطی اگر چندین و چند بار نیاز به انجام این کار باشد کدهای تکراری و سخت برای توسعه زیاد می‌شود و قابلیت تغییر کد سخت می‌شود در صورت تغییر یکی از مراحل کد مورد توسعه دستخوش تغییرات بسیار زیادی می شود. در این شرایط لازم است این پیچیدگی ها را به نحوی از دید برنامه نویس دور کنیم و برنامه نویس تنها یک تابع صدا بزند و نتیجه دلخواه خود را دریافت کند که پاسخ به این مشکل توسط الگوی Facade بیان می‌شود.
الگوی Decorator
الگوی دومی که دراین جلسه بررسی شد الگوی Decorator بود. در روال توسعه زمان‌هایی ایجاد می شود که باید ویژگی به عملکردهای موجود اضافه شود. خوب اگر بخواهیم برای اضافه شدن هر ویژگی کد کامل بنویسیم به طور فاجعه باری حجم کدهای برنامه زیاد می‌شود پس باید به فکر راهکاری باشیم که بتوانیم ویژگی‌های مختلف را جداگانه توسعه دهیم و در زمان اجرا بتوانیم این ویژگی‌ها را با هم ترکیب کنیم که روش انجام این کار در الگوی Decorator ارائه شده است.
الگوی Strategy
سومین الگوی مورد بررسی در این جلسه الگوی Strategyبود. در حین توسعه برنامه با مواردی مواجه می‌شویم که نحوه محاسبه و منطقی بخشی از برنامه با توجه به شرایط متفاوت می‌شود. یکی از راهکارهای معمول برای پیاده سازی این شرایط معمولا از دستوارت کنترلی و شرط ها در برنامه نویسی استفاده می شود. اما با یک نگاه ساده متوجه می‌شویم با این روش توسعه اصول SOLID زیر سوال می‌رود و رعایت نمی شود. پس باید راه حلی داشته باشیم که روش پیاده سازی منطق مورد نظر به صورت جداگانه توسعه داده شود و در زمان توسعه به سادگی مورد استفاده قرار گیرد. الگوی Strategy جوابی به همین سوالات دارد.
الگوی Chain of Responsiblity
چهارمین الگوی مورد بررسی در این جلسه Chain of Responsiblity بود. به این مثال دقت کنید: برای دریافت وام وارد بانک می‌شویم. ابتدا متصدی مدارک را از ما دریافت می‌کند و در صورت کامل بودن مدارک و احراز شرایط پرونده به جریان می‌افتد. حالا اگر مبلغ وام ما از حدی بالاتر باشد متصدی به تنهایی نمی‌تواند در این مورد تصمیم بگیرد و ادامه کار را باید به معاون یا رئیس شعبه واگذار کند. پس بعد از پردازش اولیه درخواست را به مرحله بعد ارسال می‌کند. بعضا اتفاق می‌افتد که حتی معاون شعبه هم اجاز انجام این کار را ندارد و بعد از تکمیل درخواست در سطح خودش کار را به مرحله بعد ارجاع می‌دهد. در این میان مشتری نمیداند کارش چگونه انجام می شود و فقط در نهایت از متصدی جواب میگیرد که آیا کار به درستی انجام شده یا نه. این مثال و موارد بسیاری در برنامه نویسی وجود دارد که پیچیدگی زیادی ممکن است داشته باشد اما به کمک الگوی Chain of Responsiblity می‌توانیم به خوبی پیاده سازی‌های خود را انجام دهیم و این پیچیدگی ها را مدیریت کنیم.
الگوی Template Method
آخرین الگوی مورد بررسی Template Methodبود. هنگام توسعه با شرایطی مواجه می‌شویم که یک کار میخواهیم انجام دهیم ولی این یک کار به حالت های مختلفی قابل پیاده سازی است. به عبارتی مراحل انجام کار ثابت است اما جزئیات پیاده سازی هر مرحله متفاوت است. در این شرایط برای پیاده سازی بهینه کار از الگوی Template Methodاستفاده می‌کنیم.
در این قسمت به پایان این جلسه از دوره DDD رسیدیم.
جهت کسب اطلاعات بیشتر می‌توانید به دوره بسیار کاربردی Domain Driven Design مراجعه کنید.
