آشنایی با الگوی Facade Design Pattern

در این بخش قصد داریم الگوی طراحی façade( بخوانید فِساد) را شرح دهیم.

این الگو با معماری برنامه شما در ارتباط است. در طراحی یک برنامه ممکن است بخشهای مختلفی داشته باشید. فرض کنید در حال طراحی نرم افزاری هستید که 6 زیر سیستم دارد. حاال لایه ای  به نام UI دارید که ظاهر نرم افزار را در آن طراحی کرده اید. اگر قرار باشد در UI ارتباط با تمامی این زیرسیستمها را انجام دهید ممکن است توسعه و نگهداری از این سیستم برای شما مشکل شود. در الگوی façade یک لایه واسط طراحی میشود که ارتباط با زیرسیستمها، ابزارها، کتابخانه ها و ... در این لایه انجام میشود

در اینجا façade به عنوان لایه ای میانی و واسط قرار میگیرد.

عموم برنامه نویسان با برنامه نویسی سه لایه  آشنایی دارند. شمای کلی این برنامه ها به این صورت است:

در این معماری :

لایه ی  Interface User یا همان UI، واسط کاربر است. این پروژه عموما از نوع Form Windows یا  Web می باشد

لایه ی  Logic Business یا همان ، قلب برنامه است که منطق عملیات، validation و ... در آن قرار میگیرد.

لایه ی  Access Data یا همان DAL، امکانات دسترسی به پایگاه داده را برای لایه بیزینس فراهم میکند.

مدلها و  کلاس های اشتراکی هم در لایه ی  Models تعریف میشوند.

در سیستمهای ساده )و نه خیلی خیلی ساده!( استفاده از این معماری عموما پیشنهاد میشود.

حاال فرض کنید که سیستم شما کمی پیچیده تر باشد )یا خودتان بخواهید سیستمتان را پیچیده تر کنید!!(. فرض کنید لایه های  زیر را برای برنامه در نظر گرفته باشید )این لایه ها فرضی هستند و لزوما پیشنهاد نمیشود

 UI: ظاهر نرم افزار فرم ها در این لایه طراحی میشود.

 Validation: کلیه ی کارهای مربوط به اعتبارسنجی داده ها و مدل ها را در این لایه  انجام میشود.

 Gateway DataAccess: دسترسی به بانکهای اطالعاتی مختلف (مثال sql، oracle، MongoDb )از طریق این واسط انجام میگیرد.

 Utilities: ابزارهای کمکی )Helpers )که امکاناتی را برای شما فراهم میکنند.

 Services: سرویسهای سیستم در این لایه تعریف میشود.

حاال اگر قرار باشد لایه ی UI با همه ی این لایه ها در ارتباط باشد، کار شما در لایه ی  UI بسیار سخت شده و همچنین هزینهی نگهداری و debug سیستم باال میرود.

همین لایه ها اگر بخواهیم با معماری Facade پیش برویم، خواهیم داشت:

در این معماری لایه ی رابط کاربری (UI) فقط با Facade در ارتباط است و این Facade است که از تمامی ابزارهای موجود خود استفاده میکند. ابزارهایی که اگر قرار بود لایه ی UI به صورت مستقیم با اینها کار کند، پیچیدگی زیادی در سیستم به وجود میآمد.

البته دلیل استفاده از Facade فقط برای داشتن لایه ی UI بهتر نیست. بلکه این معماری عملا کل سیستم را تحت تاثیر قرار داده است. ابزارها به صورت مستقل عمل میکنند و امکاناتی را فراهم میآورند. در لایه ی Facade از این امکانات استفاده میشود. فرض کنید کلاس زیر را در لایه Facade داشته باشیم. به متد BuyCar توجه کنید

در مثال بالا آشنایی با کلیات کار هدف ماست و به جزئیات کاری نداریم. در متد BuyCar ابتدا عملیات Validation انجام شده است. در صورت valid بودن، بررسی شده است که سرویس پرداخت بانک در دسترس باشد. سپس مدلی برای درج در دیتابیس تعریف و استفاده شده است. و پس از یک سری عملیات دیگر، نتیجه ی نهایی در اختیار متد فراخوان قرار میگیرد.

مجتمع بودن کدها هم باعث مدیریت یکپارچه بخشهای مختلف سیستم میشود از برخی پیچیدگی ها (روابط Spaghetti )جلوگیری میکند.