معرفی دیزاین پترن facade چیست؟
دیزاین پترن‌ها یا الگوهای طراحی، مجموعه‌ای از راه‌حل‌ها برای مشکلات متداول و پیش‌بینی‌شده است که افراد حرفه‌ای در برنامه‌نویسی از آنها استفاده می‌کنند.
ما 23 الگو طراحی داریم که هرکدام راه حلی برای مشکلی هستند این 23 الگو توسط 4 نفر معروف به gang of four جمع‌آوری شده‌اند.
در این مقاله با الگوی Facade آشنا می‌شویم البته شما می‌توانید با مراجعه به دوره آموزش دیزاین پترن‌ها در وبسایت باگتو این 23 الگو را بصورت کامل و کاربردی و همراه با مثال یاد بگیرید چرا که یادگیری دیزاین پترن ها باعث متمایز شدن برنامه نویس با هم تیمی های خود در هر شرکتی است.
الگوی فساد یا نمای بیرونی چیست و چه کاربردی دارد؟
دیزاین پترن facade جز الگوهای Structural است و در شرایطی از آن استفاده می کنیم که کدی پیچیده داشته باشیم که با چندین کلاس مختلف پیاده‌سازی شده استیا زمانی که یک کد قدیمی داریم که بازسازی کردن آن بسیار زمان‌بر می‌باشد که در چنین شرایطی با استفاده از دیزاین پترن facade یک کلاسی می‌سازیم که امکان ارجاع به تمامی کلاس‌های اپلیکیشن را داشته و در نهایت میتوانیم متدهای مد نظر خود را از طریق تنها یک متد فراخوانی کنیم که این امر منجر به کاهش پیچیدگی ساختار سیستم می‌شود.
بعنوان مثال قصد خرید داریم اما هیچ فروشگاهی در سطح شهر وجود ندارد.مثلا میخواهیم پنیر بخریم مجبوریم که به کارخانه کاله یا پگاه برویم و پنیر را خریداری کنیم و یا میوه نیاز داریم و برای تهیه آن مجبوریم به باغ های اطراف شهر برویم، درکل به هرچیزی که نیاز داریم مجبوریم از مبدا ان انرا تهیه کنیم.برای هر خرید باید کلی انرژی و زمان هدر دهیم ولی امروزه میتوانیم با چند کلیک درون یک اپلیکیشن این کار را به سادگی انجام دهیم.
ولی یک سری فروشگاه‌ها یا مغازه‌ها و یا سوپرمارکت‌ها در سطح شهر وجود دارد که این کار را برای ما انجام می‌دهند در واقع می‌روند از مبدأ هر چیزی آن محصول را تهیه می‌کنند و ما میتوانیم از آنها این محصول را خریداری کنیم برای مثال آنها می‌روند پنیر را از کارخانه میاورند و ما می‌رویم پنیر را از آنها تهیه می‌کنیم و زمان و انرژی خود را هدر نمی‌دهیم.
خب در اصل این فروشگاه‌ها و سوپرمارکت‌ها دقیقاً نقش و کار الگوی façade را برای ما انجام می‌دهند و در اصل ما را از ساب سیستم‌ها جدا می‌کنند برای مثال شما کارخانه کاله را در نظر بگیرید که یک ساب سیستم است و لبنیات تولید می‌کند و سوپرمارکت‌ها ما را از این ساب سیستم‌ها جدا می‌کنند،
در واقع فروشگاه‌ها همان الگوی فساد هستند که بین ما و ساب سیستم‌ها قرار می‌گیرند و ما به‌عنوان کلاینت زمانی که به هر کالا یا محصول یا سرویسی نیاز داریم آن را از فساد دریافت می‌کنیم.
از الگوی فساد در موارد بسیاری استفاده می‌کنیم و این الگو برای ما پرکاربرد است تصور کنید که مجبور بودید برای تهیه مواد غذایی و مصرفی از کارخانه‌ها و باغ‌ها محصولات موردنیاز خود را تهیه می‌کردیم خیلی زندگی سخت می‌شد و تمام زمان ما در رفت‌وآمد بین این مسیرها هدر می‌رفت
در برنامه‌نویسی نیز اهمیت الگوی فساد به همین شکل است اگر بروی برنامه‌های بزرگ که هزاران سرویس و کلاس دارند کار کنید به اهمیت الگوی فساد پی می‌برید و می‌بینید که می‌تواند کار ما را بسیار راحت کند.
زمانی که یک برنامه بزرگ داریم و آن را به چند ساب سیستم تقسیم می‌کنیم که باید باهم در ارتباط باشند و برای انجام یک کار خاص این ساب سیستم‌ها باید از هم کمک بگیرند.
فرض کنید میخواهیم فرایند ثبت‌نام یک کاربر را انجام دهیم و برای اینکه فرایند ثبت‌نام کاربر انجام شود باید چند subsystem باهم کار کنند و کارهای مختلفی را انجام دهند مثلاً باید از ثبت‌احوال یک سری دیتا بگیریم و سپس از بانک هم دیتا دریافت کنیم و غیره ... که این فرایند ثبت‌نام انجام شود.
اگر الگوی فساد وجود نداشت ما مجبور بودیم تک‌تک این ساب سیستم‌ها را در کنترلر خود صدا بزنیم و تک‌تک از آنها استفاده کنیم که یک فرایند خیلی پیچیده می‌شد اما اگر از فساد استفاده کنیم یک کلاس فساد بین کلاینت و ساب سیستم قرار می‌دهیم و درون آن کلاس فساد کار ثبت‌نام را انجام می‌دهیم درواقع کار نمونه‌سازی از ساب سیستم‌ها دیتا دادن و صدا زدن متدها و غیره ... را انجام می‌دهیم و کلاینت از این کلاس واسط استفاده می‌کند و می‌تواند فرایند را به‌راحتی انجام دهد که البته مزایا و معایبی دارد که در ادامه آنها را توضیح خواهیم داد.
بررسی UML الگوی Facade
اگر در گوگل umlالگوی façade را جستجو کنید نمونه‌های مختلفی را می‌بینید که در ظاهر باهم تفاوت دارند اما همه آنها یک کار را انجام می‌دهند.
همان‌طور که در uml مشاهده می‌کنید ما دو client داریم که استفاده‌کننده‌های سیستم هستند و در پایین سه تا package داریم که همان subsystemهای ما هستند که هرکدام کاری را انجام می‌دهند و هرکدام از کلاینت‌ها برای انجام یک فرایند خاص باید از این سه تا ساب سیستم به ترتیب استفاده کنند فرض کنید که برای انجام یک فرایند نیاز داریم کارهای مختلفی را انجام دهیم
حال یک کلاس به اسم Facade داریم که تمامی این پکیج‌ها درون این کلاس نمونه‌سازی شده‌اند و متدهای آنها صدا زده شده و مقداردهی شده‌اند و حالا کلاینت‌ها دیگر از این پکیج‌ها خبر ندارند و همه فرایندهای موردنیاز خود را از این کلاس فساد می‌گیرند
به مثال زیر توجه کنید میخواهیم uml بالا را به زبان سی شارپ پیاده‌سازی کنیم
تصور کنید که میخواهیم یک فرایند انجام دهیم که در آن نیاز به چند پکیج داریم
public class Class1
{
public void Action1()
{
Console.WriteLine("run ... SubSystem1.Class1.Action1");
}
public void Finish()
{
Console.WriteLine("run ... SubSystem1.Class1.Finish");
}
}
public class Class2
{
public void Action2()
{
Console.WriteLine("run ... SubSystem2.Class2.Action2");
}
}
public class Class3
{
public void Action3()
{
Console.WriteLine("run ... SubSystem3.Class3.Action3");
}
}
همان‌طور که مشاهده می‌کنید ما سه تا کلاس داریم و هرکدام از این‌ها را می‌توان یک package در نظر گرفت که هرکدام درون خود متدهایی دارند
public class Facade
{
public void doSomething()
{
Class1 c1 = new Class1();
Class2 c2 = new Class2();
Class3 c3 = new Class3();
c1.Action1();
c2.Action2();
c3.Action3();
c1.Finish();
}
}
حال یک کلاس فساد داریم که درون این کلاس از پکیج‌های خود نمونه‌گیری کرده‌ایم و متدهای درون آنها را صدا زدیم
class Program
{
static void Main(string[] args)
{
Facade facade = new Facade();
facade.doSomething();
Console.ReadLine();
}
}
در این قسمت در کلاس برنامه از کلاس فساد خود استفاده می‌کنیم که خودش الگو تمامی ساب سیستم‌ها و یا پکیج‌ها را اجرا می‌کند.
و خروجی کار به شکل بالا در میاید
البته این مثال یک مثال ساده بود که شما بتوانید به‌صورت ساده الگوی فساد را پیاده‌سازی کنید و ممکن است در پروژه‌های بزرگ‌تر پیاده‌سازی به شکل دیگری باشد
نکاتی درباره الگوی Facade
-
پیاده‌سازی ساده
-
عدم محدودیت در تعداد فساد
-
واسط فساد به واسط زیرسیستم‌ها وابستگی ندارد
-
استفاده از singleton و یا کلاس استاتیک برای فساد
-
استفاده از abstract برای facadeها برای چندید پیاده‌سازی
-
ایجاد لایه‌بندی برای facade یعنی مثلاً برای هر ساب سیستم یک کلاس فساد داریم که تعداد این کلاس‌های فساد زیاد شده‌اند و استفاده از آنها سخت است. ما میتوانیم این کلاس‌های فساد را درون یک کلاس فساد دیگر قرار دهیم و فسادها را لایه‌بندی کنیم
-
ساده سازی کار با سیستم شلوغ
مزایا و معایب الگوی Facade
-
برقراری اتصال سست در برنامه
-
لایه بندی سیستم
-
کلاینت ها از جرییات سطح پایین زیر سیستم ها خبر ندارند
-
کاهش وابستگی‌ها
-
کاهش وابستگی بین زیرسیستم‌ها
-
اجبار استفاده از facade برای کلاینت‌ها وجود ندارد
-
راهنمای جامعی برای پیاده‌سازی این الگو وجود ندارد و در شرایط مختلف پیاده‌سازی‌های مختلفی برای آن وجود دارد