الگو طراحی سازنده چیه؟ 🧐
الگو طراحی سازنده یا به عبارت دیگه Builder Design pattern یک الگو Creational و همچنین جزو 23 الگو مهم GoF هست.
به صورت کلی یک الگو طراحی نرم افزاره که برای ساخت اشیاء پیچیده به صورت گام به گام استفاده میشه. همین امر باعثه ترویج سازماندهی بهتر کد، بهبود خوانایی و افزایش انعطاف پذیری در ساخت شئ میشه.
بیاید یک مثال بزنیم!
فکر کنید قرار یک کلاس House بسازیم که این کلاس، یک شبیه ساز از فرایند ساخت خونه هست و قراره در بیشتر موارد ازش استفاده کنیم.
به صورت بیسیک و پایه باید خونه چهاردیوار، یک دَر، یک جفت پنجره و یک سقف داشته باشه. اما اگه یکی مثلا بخواد برای خونه خودش حیاط خلوت، بالکن یا یک طبقه جدید اضافه کنه چی؟
احتملا ساده ترین راه حل گسترش کلاس با پارامتر های زیاده، مثلا :
اما در بیشتر موارد پارامتر ها استفاده نمیشن و هر زمان از کلاس House استفاده کنیم کد رو کثیف میکنه.
اینجاست که الگو Builder به کمکمون میاد!
الگو بیلدر میگه فراخوانی متد هارو از constructor به متد build منتقل کنیم، به این صورت :
اینجوری دیگ لازم نیست از پارامتر های زیادی
استفاده کنیم. برای هر خونه متد هارو صدا میزنیم و در آخر با صدا زدن متد Build، خونه ساخته میشه
چه زمانی از این الگو استفاده کنیم؟
🔢 ساخت یک شی پیچیده با تعداد پارامتر های بالا.
🔢 هر زمان نیاز به ساخت یک شئ به صورت گام به گام داشتیم.
چه زمانی از این الگو استفاده نکنیم؟
🔵 برای اشیایی با تنها چند پارامتر و فرایند ساخت ساده، استفاده از الگو سازنده توصیه نمیشه.
🔵 اگه برای شما سرعت در اولویت قرار داره، مراحل اضافی مثل (فراخوانی متد ها) میتونه بر عملکرد تاثیر بزاره و در صورت وجود پترن یا کد بهتر، باید از اون استفاده کنیم.
🔵 اگه کلاس Builder با constructor ارتباط داشته باشه، میتونه انعطاف پذیری و نگهداری کد رو کاهش بده که برای نگهداری بهتر از loser coupling استفاد میکنیم.
به عنوان مثال در جاوا اسکریپت میشه به این شکل این الگو رو پیاده سازی کرد.
به صورت کلی استفاده از الگو سازنده بستگی به شرایط پروژه داره، و ممکنه در یک پروژه حتی چندین بار ازش استفاده بشه. برای اطلاعات و مثال های بیشتر، میتونید این مقاله رو مطالعه کنید.
#design_pattern #builder
@CodeModule
الگو طراحی سازنده یا به عبارت دیگه Builder Design pattern یک الگو Creational و همچنین جزو 23 الگو مهم GoF هست.
به صورت کلی یک الگو طراحی نرم افزاره که برای ساخت اشیاء پیچیده به صورت گام به گام استفاده میشه. همین امر باعثه ترویج سازماندهی بهتر کد، بهبود خوانایی و افزایش انعطاف پذیری در ساخت شئ میشه.
بیاید یک مثال بزنیم!
فکر کنید قرار یک کلاس House بسازیم که این کلاس، یک شبیه ساز از فرایند ساخت خونه هست و قراره در بیشتر موارد ازش استفاده کنیم.
به صورت بیسیک و پایه باید خونه چهاردیوار، یک دَر، یک جفت پنجره و یک سقف داشته باشه. اما اگه یکی مثلا بخواد برای خونه خودش حیاط خلوت، بالکن یا یک طبقه جدید اضافه کنه چی؟
احتملا ساده ترین راه حل گسترش کلاس با پارامتر های زیاده، مثلا :
new House(4،1،true، false......)
اما در بیشتر موارد پارامتر ها استفاده نمیشن و هر زمان از کلاس House استفاده کنیم کد رو کثیف میکنه.
اینجاست که الگو Builder به کمکمون میاد!
الگو بیلدر میگه فراخوانی متد هارو از constructor به متد build منتقل کنیم، به این صورت :
House builder :
BuildWalls()
BuildDoors()
And....
Build() : House
اینجوری دیگ لازم نیست از پارامتر های زیادی
استفاده کنیم. برای هر خونه متد هارو صدا میزنیم و در آخر با صدا زدن متد Build، خونه ساخته میشه
چه زمانی از این الگو استفاده کنیم؟
چه زمانی از این الگو استفاده نکنیم؟
به عنوان مثال در جاوا اسکریپت میشه به این شکل این الگو رو پیاده سازی کرد.
به صورت کلی استفاده از الگو سازنده بستگی به شرایط پروژه داره، و ممکنه در یک پروژه حتی چندین بار ازش استفاده بشه. برای اطلاعات و مثال های بیشتر، میتونید این مقاله رو مطالعه کنید.
#design_pattern #builder
@CodeModule
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6⚡2
الگو طراحی سینگلتون چیه؟ 🤔
در مهندسی نرم افزار، الگوی singleton یک الگوی طراحیه که نمونه سازی یک کلاس رو به یک نمونه منحصر به فرد، محدود میکنه. همچنین یک الگو Creational و یکی از الگو های معروفه "Gang of Four" نیز هست.
این الگو زمانی مفیده که دقیقاً یک شیء برای هماهنگ کردن اقدامات در یک سیستم، مورد نیازه.
به طور خاص، الگوی سینگلتون به اشیاء اجازه میده:
♨️ فقط یک نمونه داشته باشن
♨️ دسترسی آسان به نمونه رو فراهم میکنه
♨️ نمونه سازی اون رو کنترل میکنه (مثلاً سازنده های یک کلاس رو مخفی میکنه)
چرا اسم این پترن سینگلتون هست؟
این اصطلاح برگرفته از یک مفهوم ریاضیه و به مجموعه ای که دقیقاً یک عنصر داره، سینگلتون میگن. برای مثال مجموعه‌ای مثل {{1،2،3}} یک سینگلتونه، چون حاوی یک عنصر واحده (که خود یک مجموعه هست، اما سینگلتون نیست).
ویژگی های پترن سینگلتون چیه؟
- اگر از الگوی طراحی سینگلتون برای ساخت یک نمونه از کلاس استفاده بشه، این الگو مطمئن میشه که واقعا فقط یک نمونه از کلاس وجود داره.
- سینگلتون کلاس رو در سطح گلوبال در دسترس قرار میده.
درحالی که singleton میتونه مفید باشه اما باید دربرخی موارد احتیاط کنیم⬇️
چالش های تست: تست کدی که به سینگلتون وابسته هست میتونه مشکل باشه.
کوپلینگ محکم: استفاده زیاد از سینگلتون میتونه کوپلینگ محکم رو افزایش بده.
🔵 میتونیم از الگوی تزریق وابستگی (dependency injection) به عنوان جایگزین، برای looser coupling استفاده کنیم.
در نهایت پیاده سازی الگوی سینگلتون باید با دقت انجام بشه، تا از پایداری کد اطمینان حاصل شه. این الگو میتونه در مواردی مفید باشه و در مواردی نه، بستگی به شما و پروژتون داره.
یک نمونه از پیاده سازی الگو سینگلتون رو با زبان جاوا اسکریپت، میتونید در این ریپازیتوری مشاهده کنید.
#design_pattern #singleton
@CodeModule
در مهندسی نرم افزار، الگوی singleton یک الگوی طراحیه که نمونه سازی یک کلاس رو به یک نمونه منحصر به فرد، محدود میکنه. همچنین یک الگو Creational و یکی از الگو های معروفه "Gang of Four" نیز هست.
این الگو زمانی مفیده که دقیقاً یک شیء برای هماهنگ کردن اقدامات در یک سیستم، مورد نیازه.
به طور خاص، الگوی سینگلتون به اشیاء اجازه میده:
چرا اسم این پترن سینگلتون هست؟
این اصطلاح برگرفته از یک مفهوم ریاضیه و به مجموعه ای که دقیقاً یک عنصر داره، سینگلتون میگن. برای مثال مجموعه‌ای مثل {{1،2،3}} یک سینگلتونه، چون حاوی یک عنصر واحده (که خود یک مجموعه هست، اما سینگلتون نیست).
ویژگی های پترن سینگلتون چیه؟
- اگر از الگوی طراحی سینگلتون برای ساخت یک نمونه از کلاس استفاده بشه، این الگو مطمئن میشه که واقعا فقط یک نمونه از کلاس وجود داره.
- سینگلتون کلاس رو در سطح گلوبال در دسترس قرار میده.
درحالی که singleton میتونه مفید باشه اما باید دربرخی موارد احتیاط کنیم
چالش های تست: تست کدی که به سینگلتون وابسته هست میتونه مشکل باشه.
کوپلینگ محکم: استفاده زیاد از سینگلتون میتونه کوپلینگ محکم رو افزایش بده.
در نهایت پیاده سازی الگوی سینگلتون باید با دقت انجام بشه، تا از پایداری کد اطمینان حاصل شه. این الگو میتونه در مواردی مفید باشه و در مواردی نه، بستگی به شما و پروژتون داره.
یک نمونه از پیاده سازی الگو سینگلتون رو با زبان جاوا اسکریپت، میتونید در این ریپازیتوری مشاهده کنید.
#design_pattern #singleton
@CodeModule
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7⚡4
با این تکنیک کدت رو انعطاف پذیر کن 🦦
Dependency Injection (DI) یک تکنیک و یک دیزاین پترن مهم و اساسی در برنامه نویسی شی گرا (OOP) هست، و به مدیریت وابستگی بین اجزای مختلف نرم افزار کمک می کنه. این پترن یک سری مزایا و معایب به همراه داره و یک سری مشکلات رو حل میکنه.
به عنوان مثال اگر ما کدی با کوپلینگ محکم داشته باشیم، این شرایط به وجود میاد:
🔵 تغییر: تغییر یک قسمت از کد میتونه باعث خرابی سیستم بشه.
🔵 آزمایش: تست اجزای جدا شده سخت هست.
🔵 قابلیت استفاده مجدد: کد به پیاده سازی های خاص، گره خورده و استفاده مجدد رو محدود میکنه.
اما چجوری تزریق وابستگی این مشکل رو حل میکنه؟🤔
- جداسازی: DI ساخت و استفاده از وابستگی ها رو جدا میکنه و باعث تقویت loose coupling میشه.
- مدیریت خارجی: یک چارچوب یا کانتینر خارجی ساخت وابستگی و چرخه حیات رو مدیریت میکنه و در صورت نیاز اون هارو تزریق میکنه.
- رابط ها: اجزا از طریق رابط ها با هم تعامل دارن و تعویض پیاده سازی ها رو آسان میکنه.
برخی از مزایا قابل توجه DI⬇️
1. Modularization: کامپوننت ها مستقل از نمونه سازی وابستگی های خود هستن.
2. سهولت تعویض: به راحتی میشه وابستگی های واقعی رو با ماک ه، برای تست، جایگزین کرد.
3. تست پذیری: تست رو با جداسازی اجزا افزایش میده.
4. قابلیت نگهداری: اتصال محکم رو کاهش میده، استفاده مجدد رو ترویج میکنه، تعمیر و نگهداری رو آسون تر می کنه.
روش های تزریق وابستگی
🔢 Constructor Injection: وابستگی ها از Constructor عبور میکنن، و اینکار وابستگی های واضح و به خوبی تعریف شده رو مشخص میکنه.
برای این که پست زیاد طولانی نشه، ادامه محتوا رو داخل این تلگراف قرار دادیم.
پیشنهاد میکنم از دستش ندید💀
#design_pattern
@CodeModule
Dependency Injection (DI) یک تکنیک و یک دیزاین پترن مهم و اساسی در برنامه نویسی شی گرا (OOP) هست، و به مدیریت وابستگی بین اجزای مختلف نرم افزار کمک می کنه. این پترن یک سری مزایا و معایب به همراه داره و یک سری مشکلات رو حل میکنه.
به عنوان مثال اگر ما کدی با کوپلینگ محکم داشته باشیم، این شرایط به وجود میاد:
اما چجوری تزریق وابستگی این مشکل رو حل میکنه؟
- جداسازی: DI ساخت و استفاده از وابستگی ها رو جدا میکنه و باعث تقویت loose coupling میشه.
- مدیریت خارجی: یک چارچوب یا کانتینر خارجی ساخت وابستگی و چرخه حیات رو مدیریت میکنه و در صورت نیاز اون هارو تزریق میکنه.
- رابط ها: اجزا از طریق رابط ها با هم تعامل دارن و تعویض پیاده سازی ها رو آسان میکنه.
برخی از مزایا قابل توجه DI
1. Modularization: کامپوننت ها مستقل از نمونه سازی وابستگی های خود هستن.
2. سهولت تعویض: به راحتی میشه وابستگی های واقعی رو با ماک ه، برای تست، جایگزین کرد.
3. تست پذیری: تست رو با جداسازی اجزا افزایش میده.
4. قابلیت نگهداری: اتصال محکم رو کاهش میده، استفاده مجدد رو ترویج میکنه، تعمیر و نگهداری رو آسون تر می کنه.
روش های تزریق وابستگی
برای این که پست زیاد طولانی نشه، ادامه محتوا رو داخل این تلگراف قرار دادیم.
پیشنهاد میکنم از دستش ندید
#design_pattern
@CodeModule
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡5🔥3
الگو دکوراتور چیه؟ 🤔
در برنامه‌نویسی شی‌گرا، الگوی دکوراتور یک الگوی طراحی(design pattern) هست که اجازه میده رفتار جدیدی به یک شیء خاص به صورت پویا اضافه بشه، بدون اینکه بر رفتار سایر اشیاء از همان کلاس تأثیر بزاره. این الگو به اصل مسئولیت تک (Single Responsibility Principle) پایبنده، چون امکان تقسیم وظایف بین کلاس‌های مختلف رو فراهم میکنه و همچنین به اصل باز-بسته (Open-Closed Principle) کمک میکنه، چون میتونه کارکرد کلاس‌ها رو بدون تغییرشون افزایش بده.
توجه داشته باشید این الگو با دکوراتور ها در پایتون یکی نیست ‼️
برای درک بهتر با هم یک مثال میزنیم. فرض کنید که در یک کافی‌شاپ قهوه سفارش میدید. حالا چطور الگوی دکوراتور رو میتونیم ببینیم؟
* هسته: درواقع قهوه شما جزء اصلی هست و فرقی نداره چه قهوه ای باشه.
* دکوراتورها: ممکنه بخوایید به قهوه خودتون اجزای مختلفی اضافه کنید، که به عنوان دکوراتور عمل میکنن. به عنوان مثال این دکوراتور:
حالا شما به عنوان مشتری، با انتخاب و ترکیب دکوراتورها تصمیم میگیرید قهوه خودتون رو چجوری درست کنید. مثلا شما ممکنه کمی نیاز به شیر داشته باشید، پس از MilkDecorator استفاده می‌کنید.
برخی از ویژگی های این الگو⬇️
🔵 نگهداری آسون‌تر: هسته اصلی برنامه بدون تغییر باقی میمونه، که نگهداری و درک کد رو آسون‌تر میکنه.
🔵 پایبندی به اصل باز-بسته: میتونید عملکردهای جدیدی به برنامه اضافه کنید بدون اینکه کدهای موجود رو تغییر بدین.
🔵 پایبندی به اصل مسئولیت تک: با تقسیم وظایف به کلاس‌های کوچک‌تر و مستقل، کد رو قابل فهم‌تر و قابل مدیریت‌تر میکنه.
به صورت کلی الگوی دکوراتور، یکی از الگوهای مهم و معروف در زمینهٔ طراحی نرم‌افزاره که به عنوان یک الگوی ساختاری (Structural Pattern) در الگوهای طراحی GoF شناخته میشه. این الگو اهمیت زیادی در توسعه‌ی نرم‌افزار داره، پس پیشنهاد میکنم برای درک بهترش مقالات زیر رو بخونید.
- Article
- Article
- Article
#design_pattern
@CodeModule
در برنامه‌نویسی شی‌گرا، الگوی دکوراتور یک الگوی طراحی(design pattern) هست که اجازه میده رفتار جدیدی به یک شیء خاص به صورت پویا اضافه بشه، بدون اینکه بر رفتار سایر اشیاء از همان کلاس تأثیر بزاره. این الگو به اصل مسئولیت تک (Single Responsibility Principle) پایبنده، چون امکان تقسیم وظایف بین کلاس‌های مختلف رو فراهم میکنه و همچنین به اصل باز-بسته (Open-Closed Principle) کمک میکنه، چون میتونه کارکرد کلاس‌ها رو بدون تغییرشون افزایش بده.
برای درک بهتر با هم یک مثال میزنیم. فرض کنید که در یک کافی‌شاپ قهوه سفارش میدید. حالا چطور الگوی دکوراتور رو میتونیم ببینیم؟
* هسته: درواقع قهوه شما جزء اصلی هست و فرقی نداره چه قهوه ای باشه.
* دکوراتورها: ممکنه بخوایید به قهوه خودتون اجزای مختلفی اضافه کنید، که به عنوان دکوراتور عمل میکنن. به عنوان مثال این دکوراتور:
* MilkDecorator: شیر رو به قهوه شما اضافه میکنه.
* SugarDecorator: شکر رو به قهوه شما اضافه میکنه.
* SyrupDecorator: شربت های طعم دار رو اضافه میکنه.
حالا شما به عنوان مشتری، با انتخاب و ترکیب دکوراتورها تصمیم میگیرید قهوه خودتون رو چجوری درست کنید. مثلا شما ممکنه کمی نیاز به شیر داشته باشید، پس از MilkDecorator استفاده می‌کنید.
برخی از ویژگی های این الگو
به صورت کلی الگوی دکوراتور، یکی از الگوهای مهم و معروف در زمینهٔ طراحی نرم‌افزاره که به عنوان یک الگوی ساختاری (Structural Pattern) در الگوهای طراحی GoF شناخته میشه. این الگو اهمیت زیادی در توسعه‌ی نرم‌افزار داره، پس پیشنهاد میکنم برای درک بهترش مقالات زیر رو بخونید.
- Article
- Article
- Article
#design_pattern
@CodeModule
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7⚡3
دیزاین پترن ها در فرانت‌اند 👨🚀
بدون شک دیزاین پترن ها باعث بهود سطح و کیفیت کد ما میشن و یادگیریشون، برای هر برنامه نویسی واجبه. سایت patterns.dev یک منبع آموزشی برای یادگیری این الگوهای طراحی هست.
این سایت کلی مثال و نمونه کد برای زبان جاوااسکریپت و تکنولوژی هایی مثل ریکت و ویو داره و مثل آب خوردن، دیزاین پترن هارو میتونید یاد بگیرید.
#design_pattern
@CodeModule
بدون شک دیزاین پترن ها باعث بهود سطح و کیفیت کد ما میشن و یادگیریشون، برای هر برنامه نویسی واجبه. سایت patterns.dev یک منبع آموزشی برای یادگیری این الگوهای طراحی هست.
این سایت کلی مثال و نمونه کد برای زبان جاوااسکریپت و تکنولوژی هایی مثل ریکت و ویو داره و مثل آب خوردن، دیزاین پترن هارو میتونید یاد بگیرید.
فعلا اینو داشته باشید تا تک تک بیایم شرحشون بدیم :))
#design_pattern
@CodeModule
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15⚡3
با پترن Prototype آشنا بشید! 👽
دیزاین پترن پروتوتایپ، یک پترن creational هست که اشیاء جدید رو با کپی کردن یک شی موجود مشخص میکنه، بنابراین نیازی به ایجاد کلاس‌های جدید نیست. این الگو به ما اجازه میده تا اشیاء موجود رو شبیه سازی کنیم و نمونه های جدیدی رو با همون داده ها ایجاد کنیم. هر تغییری که در شیء شبیه سازی شده ایجاد میشه، بر روی شی اصلی تأثیری نداره. به خصوص زمانی که هزینه ساخت یک شی گرانتر یا پیچیده تر از کپی کردن یک شیء موجود باشد، مفیده.
شیء تازه کپی شده فقط در صورت نیاز ممکنه همون خصوصیات رو تغییر بده. این رویکرد باعث صرفه جویی در منابع و زمان پرهزینه میشه، به خصوص زمانی که ساخت شی یک فرآیند سنگینه.
یکی از بهترین راه های موجود برای ساخت یک شی از اشیاء موجود، متد ()clone هست. Clone ساده ترین روش برای اجرای یک الگوی نمونه اولیه هست.
با این مثال میتونید کامل این الگو رو درک کنید. تصور کنید شما یک طراح هستید که مبلمان میسازید.
🔵 Prototype (صندلی نمونه): شما با دقت یک صندلی تکی رو با طراحی، مواد و پایان عالی میسازید. این صندلی به "prototype" شما تبدیل میشه - طرحی برای همه صندلی های مبلمان شما.
🔵 Cloning (تولید انبوه): به جای اینکه هر صندلی رو کاملاً از ابتدا بسازید، از prototype استفاده می کنین. یک تیم کارگاه نمونه اولیه رو میگیره و با استفاده از همون مواد و تکنیک های ساخت، کپی های دقیقی رو میسازه. این فرآیند شبیه سازی به طور موثر صندلی های جدیدی رو بر اساس نمونه اولیه ساخته شده تولید میکنه.
🔵 Customization (تغییرها): در حالی که طراحی اصلی از prototype میاد، فضایی برای سفارشی سازی وجود داره. ممکنه نسخه‌های رنگی متفاوتی از صندلی ها بسازین، از پارچه‌های مختلف برای لوازم داخلی استفاده کنین یا حتی اندازه اون رو کمی تنظیم کنید. این تغییرات نشان دهنده مد هست.
به صورت کلی بخوام این پترن رو در یک جمله تعریف کنم، "راهی برای ساخت اشیاء جدید با کپی کردن موارد موجود" میشه. برای کسب اطلاعات بیشتر و مشاهده نمونه کد ها، مقالات زیر رو مطالعه کنید.
- Article
- Article
- Article
#design_pattern
@CodeModule
دیزاین پترن پروتوتایپ، یک پترن creational هست که اشیاء جدید رو با کپی کردن یک شی موجود مشخص میکنه، بنابراین نیازی به ایجاد کلاس‌های جدید نیست. این الگو به ما اجازه میده تا اشیاء موجود رو شبیه سازی کنیم و نمونه های جدیدی رو با همون داده ها ایجاد کنیم. هر تغییری که در شیء شبیه سازی شده ایجاد میشه، بر روی شی اصلی تأثیری نداره. به خصوص زمانی که هزینه ساخت یک شی گرانتر یا پیچیده تر از کپی کردن یک شیء موجود باشد، مفیده.
شیء تازه کپی شده فقط در صورت نیاز ممکنه همون خصوصیات رو تغییر بده. این رویکرد باعث صرفه جویی در منابع و زمان پرهزینه میشه، به خصوص زمانی که ساخت شی یک فرآیند سنگینه.
یکی از بهترین راه های موجود برای ساخت یک شی از اشیاء موجود، متد ()clone هست. Clone ساده ترین روش برای اجرای یک الگوی نمونه اولیه هست.
با این مثال میتونید کامل این الگو رو درک کنید. تصور کنید شما یک طراح هستید که مبلمان میسازید.
به صورت کلی بخوام این پترن رو در یک جمله تعریف کنم، "راهی برای ساخت اشیاء جدید با کپی کردن موارد موجود" میشه. برای کسب اطلاعات بیشتر و مشاهده نمونه کد ها، مقالات زیر رو مطالعه کنید.
- Article
- Article
- Article
#design_pattern
@CodeModule
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡5🔥3👌3
با این پترن پل درست کنید! 🦦
پترن Bridge یک دیزاین پترن Structural و جزو 23 الگو GoF هست، که در مهندسی نرم‌افزار استفاده میشه و به معنای جدا کردن یک انتزاع از اجرای اون می‌باشد به طوری که این دو میتونن به طور مستقل، متفاوت باشن. به عبارت دیگه الگوی Bridge یک انتزاع (what) را از اجرای اون (how) جدا میکنه.
این جدا سازی باعث ترویج:
🟠 انعطاف پذیری: به راحتی با افزودن پیاده سازی های جدید سازگار میشه.
🟠 قابلیت نگهداری: انتزاع یا پیاده سازی ها رو به طور مستقل تغییر میده.
🟠 قابلیت استفاده مجدد: انتزاعات به خوبی تعریف شده استفاده مجدد از کد رو ترویج میکنن.
🟠 تست پذیری: تمرکز بر رفتار انتزاعی، تست رو ساده میکنه.
برای اینکه بهتر این پترن رو درک کنید، مثال زیر رو بخونید:
به کلید و پریز تو اتاقتون نگاه کنید. خود کلید (انتزاع) یک راه استاندارد برای روشن یا خاموش کردن لامپ (operations) ارائه میده. با این حال، سیم کشی برق و نوع لامپ (implementation) میتونه بسته به محل (location) و محل نصب متفاوت باشه. شما میتونید یک لامپ (implementation) رو بدون تأثیر بر نحوه استفاده از کلید (انتزاع) تعویض کنید. به طور مشابه، انواع مختلف کلید ها (اجرا با مکانیزم های مختلف) رو میشه با یک لامپ ثابت (انتزاعی) استفاده کرد.
این پترن چه مشکلاتی رو حل کنه؟ منبع
فرض کنید یک کلاس Shape با دو کلاسی که از اون ارث میبرن به اسم های Circle و Square دارید. شما میخواید این سلسله مراتب کلاس رو برای ترکیب رنگ ها گسترش بدین، بنابراین قصد دارید ساب کلاس های شکل قرمز و آبی بسازین. با این حال، از اونجایی که شما در حال حاضر دو کلاس فرعی دارید، باید چند کلاس مانند BlueCircle و RedSquare نیز بسازید.(خسته کننده هست😶🌫️)
افزودن انواع شکل ها و رنگ های جدید سلسله مراتب اون رو به صورت تصاعدی رشد میده. به عنوان مثال، برای اضافه کردن یک شکل مثلث، باید دو زیر کلاس جدید معرفی کنین، و هر چه جلوتر میریم بدتر میشه. اینجا هست که پترن Bridge به کمکون میاد.
پترن Bridge چجوری کمک میکنه؟
الگوی Bridge سعی میکنه این مشکل رو با تغییر از وراثت به composition حل کنه. به این معنی هست که به جای اینکه تمامی ابعاد و رفتارها در یک سلسله مراتب کلاس واحد نگهداری بشن، این الگو میاد یکی از ابعاد رو به صورت جداگانه در یک سلسله مراتب کلاس مستقل استخراج میکنه. به این ترتیب، کلاس‌های اصلی به جای اینکه تمام وضعیت‌ها و رفتارها رو در خود داشته باشن، به یک شی از سلسله مراتب جدید ارجاع میدن.
به صورت کلی پترن Bridge به شما این امکان رو میده که بتونید تغییرات رو به راحتی مدیریت کرده و از کد خود به طور مؤثری استفاده مجدد کنید. برای کسب اطلاعات بیشتر در مورد این پترن، به مقالات زیر مراجعه کنید.
- Article
- Article
- Article
#design_pattern
@CodeModule
پترن Bridge یک دیزاین پترن Structural و جزو 23 الگو GoF هست، که در مهندسی نرم‌افزار استفاده میشه و به معنای جدا کردن یک انتزاع از اجرای اون می‌باشد به طوری که این دو میتونن به طور مستقل، متفاوت باشن. به عبارت دیگه الگوی Bridge یک انتزاع (what) را از اجرای اون (how) جدا میکنه.
این جدا سازی باعث ترویج:
برای اینکه بهتر این پترن رو درک کنید، مثال زیر رو بخونید:
به کلید و پریز تو اتاقتون نگاه کنید. خود کلید (انتزاع) یک راه استاندارد برای روشن یا خاموش کردن لامپ (operations) ارائه میده. با این حال، سیم کشی برق و نوع لامپ (implementation) میتونه بسته به محل (location) و محل نصب متفاوت باشه. شما میتونید یک لامپ (implementation) رو بدون تأثیر بر نحوه استفاده از کلید (انتزاع) تعویض کنید. به طور مشابه، انواع مختلف کلید ها (اجرا با مکانیزم های مختلف) رو میشه با یک لامپ ثابت (انتزاعی) استفاده کرد.
این پترن چه مشکلاتی رو حل کنه؟ منبع
فرض کنید یک کلاس Shape با دو کلاسی که از اون ارث میبرن به اسم های Circle و Square دارید. شما میخواید این سلسله مراتب کلاس رو برای ترکیب رنگ ها گسترش بدین، بنابراین قصد دارید ساب کلاس های شکل قرمز و آبی بسازین. با این حال، از اونجایی که شما در حال حاضر دو کلاس فرعی دارید، باید چند کلاس مانند BlueCircle و RedSquare نیز بسازید.
افزودن انواع شکل ها و رنگ های جدید سلسله مراتب اون رو به صورت تصاعدی رشد میده. به عنوان مثال، برای اضافه کردن یک شکل مثلث، باید دو زیر کلاس جدید معرفی کنین، و هر چه جلوتر میریم بدتر میشه. اینجا هست که پترن Bridge به کمکون میاد.
پترن Bridge چجوری کمک میکنه؟
الگوی Bridge سعی میکنه این مشکل رو با تغییر از وراثت به composition حل کنه. به این معنی هست که به جای اینکه تمامی ابعاد و رفتارها در یک سلسله مراتب کلاس واحد نگهداری بشن، این الگو میاد یکی از ابعاد رو به صورت جداگانه در یک سلسله مراتب کلاس مستقل استخراج میکنه. به این ترتیب، کلاس‌های اصلی به جای اینکه تمام وضعیت‌ها و رفتارها رو در خود داشته باشن، به یک شی از سلسله مراتب جدید ارجاع میدن.
به صورت کلی پترن Bridge به شما این امکان رو میده که بتونید تغییرات رو به راحتی مدیریت کرده و از کد خود به طور مؤثری استفاده مجدد کنید. برای کسب اطلاعات بیشتر در مورد این پترن، به مقالات زیر مراجعه کنید.
- Article
- Article
- Article
#design_pattern
@CodeModule
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡6🔥3
با پترن Proxy آشنا بشید! 🪻
الگوی پروکسی یک الگوی طراحی نرم افزار هست. یک پروکسی در کلی ترین شکل خود، کلاسی هست که به عنوان رابطی برای چیز دیگری عمل میکنه. پروکسی میتونه با هر چیزی ارتباط برقرار کنه، به عنوان مثال: یک اتصال شبکه، یک شی بزرگ در حافظه، یک فایل یا منابع دیگری که کپی کردن اون گرون هست یا غیرممکن. درواقع الگوی پروکسی یک راه غیرمستقیم برای دسترسی به یک شی فراهم میکنه و کنترل اضافی، انعطاف‌پذیری و بهبود عملکرد رو برای کد شما ارائه میده.
پترن پروکسی یک رویکرد همه کاره برای تعامل با شی رو ارائه میده. این یک لایه از کنترل رو فراهم و فرآیندها رو ساده میکنه. حتی میتونه با افزودن قابلیت هایی مثل ذخیره سازی، عملکرد رو بهبود ببخشه. این امر اون رو به ابزاری ارزشمند برای ساختن سیستم های نرم افزاری انعطاف پذیر و امن تبدیل میکنه.
چه زمانی از الگوی طراحی پروکسی استفاده کنیم؟
مثلا فکر کنید در حال ساختن یک نرم افزار پیچیده هستید که به یک موتور رندر سه بعدی قدرتمند نیاز داره. با این حال، این موتور منابع فشرده هست و ممکنه برای همه عملکردها مورد نیاز نباشه. حالا اینجا پروکسی چه کمکی میتونه کنه؟ یک پروکسی برای موتور رندر اجرا میکنیم. در ابتدا، پروکسی یک مکان نگه می داره یا خالی میمونه. زمانی که رندر سه بعدی واقعاً مورد نیاز هست، پروکسی موتور واقعی رو ایجاد میکنه و اطمینان حاصل میکنه که منابع فقط در صورت لزوم تخصیص داده میشن. این رویکرد به طور قابل توجهی زمان راه اندازی برنامه و استفاده از حافظه رو با به تأخیر انداختن ساخت اشیاء با منابع فشرده بهبود می بخشه.
یک زمان دیگه ای که میتونیم از این پترن استفاده کنیم، موقعی هست که شما در حال توسعه یک سیستم مدیریت مالی با اطلاعات حساس حساب هستید. برخی از نقش‌های کاربر فقط باید دسترسی به مشاهده داشته باشن، در حالی که برخی دیگر ممکن هست به مجوز تراکنش نیاز داشته باشن. اینجا یک پروکسی برای دسترسی به حساب میسازیم. پروکسی به عنوان دروازه‌بان عمل میکنه، درخواست‌های دسترسی رو رهگیری میکنه و مجوزهای کاربر رو قبل از اعطای تعامل با شی حساب واقعی تأیید میکنه. این اقدامات امنیتی رو اعمال میکنه و تغییرات غیرمجاز رو محدود میکنه و از داده های مالی حساس محافظت میکنه.
حالا سوالی که پیش میاد اینه. چه زمانی استفاده نکنیم؟؟
به این سناریو دقت کنید: شما در حال توسعه یک برنامه پردازش داده هستید که وظایف ساده دستکاری داده ها رو انجام میده. کنترل دسترسی یا بارگذاری تنبل مورد نیاز نیست.
و اگر برنامه شما از ویژگی هایی مثل بارگذاری تنبل(lazy loading) یا کنترل دسترسی استفاده نمیکنه، پروکسی ها ممکن هست انتزاعات غیر ضروری رو معرفی کنن. این لایه اضافی می تونه رفتار شی واقعی رو پنهان کنه و دیباگ کردن رو چالش برانگیزتر کنه. در این شرایط، یک رویکرد ساده تر بدون پروکسی ممکنه قابل نگهداری تر باشه.
به صورت کلی همه دیزاین پترن ها بنظر من برای شرایط خاصی میتونن کمک کننده باشن(البته اگر حواسمون بهشون باشه). این پترن هم میتونه در شرایط خاصی کمک کننده و بهترین راه حل باشه. برای کسب اطلاعات بیشتر، شما میتونید مقالات زیر رو مطالعه کنید.
- Article
- Article
- Article
#design_pattern #proxy
@CodeModule
الگوی پروکسی یک الگوی طراحی نرم افزار هست. یک پروکسی در کلی ترین شکل خود، کلاسی هست که به عنوان رابطی برای چیز دیگری عمل میکنه. پروکسی میتونه با هر چیزی ارتباط برقرار کنه، به عنوان مثال: یک اتصال شبکه، یک شی بزرگ در حافظه، یک فایل یا منابع دیگری که کپی کردن اون گرون هست یا غیرممکن. درواقع الگوی پروکسی یک راه غیرمستقیم برای دسترسی به یک شی فراهم میکنه و کنترل اضافی، انعطاف‌پذیری و بهبود عملکرد رو برای کد شما ارائه میده.
پترن پروکسی یک رویکرد همه کاره برای تعامل با شی رو ارائه میده. این یک لایه از کنترل رو فراهم و فرآیندها رو ساده میکنه. حتی میتونه با افزودن قابلیت هایی مثل ذخیره سازی، عملکرد رو بهبود ببخشه. این امر اون رو به ابزاری ارزشمند برای ساختن سیستم های نرم افزاری انعطاف پذیر و امن تبدیل میکنه.
چه زمانی از الگوی طراحی پروکسی استفاده کنیم؟
مثلا فکر کنید در حال ساختن یک نرم افزار پیچیده هستید که به یک موتور رندر سه بعدی قدرتمند نیاز داره. با این حال، این موتور منابع فشرده هست و ممکنه برای همه عملکردها مورد نیاز نباشه. حالا اینجا پروکسی چه کمکی میتونه کنه؟ یک پروکسی برای موتور رندر اجرا میکنیم. در ابتدا، پروکسی یک مکان نگه می داره یا خالی میمونه. زمانی که رندر سه بعدی واقعاً مورد نیاز هست، پروکسی موتور واقعی رو ایجاد میکنه و اطمینان حاصل میکنه که منابع فقط در صورت لزوم تخصیص داده میشن. این رویکرد به طور قابل توجهی زمان راه اندازی برنامه و استفاده از حافظه رو با به تأخیر انداختن ساخت اشیاء با منابع فشرده بهبود می بخشه.
یک زمان دیگه ای که میتونیم از این پترن استفاده کنیم، موقعی هست که شما در حال توسعه یک سیستم مدیریت مالی با اطلاعات حساس حساب هستید. برخی از نقش‌های کاربر فقط باید دسترسی به مشاهده داشته باشن، در حالی که برخی دیگر ممکن هست به مجوز تراکنش نیاز داشته باشن. اینجا یک پروکسی برای دسترسی به حساب میسازیم. پروکسی به عنوان دروازه‌بان عمل میکنه، درخواست‌های دسترسی رو رهگیری میکنه و مجوزهای کاربر رو قبل از اعطای تعامل با شی حساب واقعی تأیید میکنه. این اقدامات امنیتی رو اعمال میکنه و تغییرات غیرمجاز رو محدود میکنه و از داده های مالی حساس محافظت میکنه.
حالا سوالی که پیش میاد اینه. چه زمانی استفاده نکنیم؟؟
به این سناریو دقت کنید: شما در حال توسعه یک برنامه پردازش داده هستید که وظایف ساده دستکاری داده ها رو انجام میده. کنترل دسترسی یا بارگذاری تنبل مورد نیاز نیست.
و اگر برنامه شما از ویژگی هایی مثل بارگذاری تنبل(lazy loading) یا کنترل دسترسی استفاده نمیکنه، پروکسی ها ممکن هست انتزاعات غیر ضروری رو معرفی کنن. این لایه اضافی می تونه رفتار شی واقعی رو پنهان کنه و دیباگ کردن رو چالش برانگیزتر کنه. در این شرایط، یک رویکرد ساده تر بدون پروکسی ممکنه قابل نگهداری تر باشه.
به صورت کلی همه دیزاین پترن ها بنظر من برای شرایط خاصی میتونن کمک کننده باشن(البته اگر حواسمون بهشون باشه). این پترن هم میتونه در شرایط خاصی کمک کننده و بهترین راه حل باشه. برای کسب اطلاعات بیشتر، شما میتونید مقالات زیر رو مطالعه کنید.
- Article
- Article
- Article
#design_pattern #proxy
@CodeModule
⚡11🔥2
دیزاین پترن Composite چیست؟ 🫵
الگوی طراحی Composite، یک الگوی طراحی structural هست که به شما امکان میده اشیاء رو در ساختارهای درخت مانند بنویسید تا سلسله مراتب بخشی از کل رو نشون بده. این به کلاینت(مشتری ها) اجازه میده تا با اشیاء و ترکیبات اشیا به طور یکنواخت رفتار کنن. به عبارت دیگه چه با یک شی منفرد و چه با گروهی از اشیا (کامپوزیت)، مشتریان میتونن به جای یکدیگر از اون ها استفاده کنن.
الگوی طراحی کامپوزیت چه مشکلاتی رو میتونه حل کنه؟ 🧸
* یک سلسله مراتب بخشی از کل باید نشان داده بشه تا کلاینت ها بتونن با اشیاء جزئی و کل به طور یکنواخت رفتار کنن.
* سلسله مراتب بخشی از کل، باید به عنوان ساختار درختی نشان داده بشه.
الگوی طراحی کامپوزیت چه راه حلی را توصیف می کند؟
* یک رابط کامپوننت یکپارچه برای اشیاء قسمت (برگ) و اشیاء کل (کامپوزیت) تعریف میکنین.
* اشیاء Leaf منفرد رابط Component رو مستقیماً پیاده سازی میکنن و اشیاء Composite درخواست ها رو به مؤلفه های فرزندشون ارسال میکنن.
شاید درکش در نگاه اول سخت باشه برای همین یک منوی رستوران رو تصور کنید، که با استفاده از الگوی طراحی کامپوزیت ارائه شده.
1. MenuItem (Interface): این رابط پایه هست که عملیات مشترک رو برای همه آیتم های منو تعریف میکنه. میتونه شامل متدهایی مثل «getName()»، «getPrice()» و «getDescription()» باشه.
2. Leaf (Concrete Class): این یک آیتم منوی واحد مثل "برگر" یا "سالاد" رو نشون میده. «MenuItem» رو پیاده‌سازی میکنه و پیاده‌سازی‌های مشخصی رو برای متد های خود فراهم میکنه و جزئیات خاص اون آیتم رو برمی‌گردونه.
3. Composite (Concrete Class): این نشون دهنده یک دسته در منو مثل پیش غذاها هست. "MenuItem" رو پیاده سازی میکنه اما جزئیات خاص خود رو نداره. درعوض، فهرستی از مؤلفه‌های فرزند (سایر موارد «MenuItems» که میتونه هم «برگ» و هم دیگر اشیاء «کامپوزیت» باشن رو در خود داره. متد های رابط رو با تکرار از طریق مؤلفه‌های فرزند خود و تفویض تماس به روش‌های مربوطه اجرا میکنه. برای مثال، «getPrice()» قیمت کل رو با جمع کردن قیمت‌های همه اقلام فرزند خود محاسبه میکنه.
به صورت کلی این پترن هم مثل پترن های دیگه در شرایط خاص ممکنه کاربردی باشه. برای اطلاعات بیشتر به این مقالات مراجعه کنید:
- Article
- Article
- Article
#design_pattern
@CodeModule
الگوی طراحی Composite، یک الگوی طراحی structural هست که به شما امکان میده اشیاء رو در ساختارهای درخت مانند بنویسید تا سلسله مراتب بخشی از کل رو نشون بده. این به کلاینت(مشتری ها) اجازه میده تا با اشیاء و ترکیبات اشیا به طور یکنواخت رفتار کنن. به عبارت دیگه چه با یک شی منفرد و چه با گروهی از اشیا (کامپوزیت)، مشتریان میتونن به جای یکدیگر از اون ها استفاده کنن.
الگوی طراحی کامپوزیت چه مشکلاتی رو میتونه حل کنه؟ 🧸
* یک سلسله مراتب بخشی از کل باید نشان داده بشه تا کلاینت ها بتونن با اشیاء جزئی و کل به طور یکنواخت رفتار کنن.
* سلسله مراتب بخشی از کل، باید به عنوان ساختار درختی نشان داده بشه.
الگوی طراحی کامپوزیت چه راه حلی را توصیف می کند؟
* یک رابط کامپوننت یکپارچه برای اشیاء قسمت (برگ) و اشیاء کل (کامپوزیت) تعریف میکنین.
* اشیاء Leaf منفرد رابط Component رو مستقیماً پیاده سازی میکنن و اشیاء Composite درخواست ها رو به مؤلفه های فرزندشون ارسال میکنن.
شاید درکش در نگاه اول سخت باشه برای همین یک منوی رستوران رو تصور کنید، که با استفاده از الگوی طراحی کامپوزیت ارائه شده.
1. MenuItem (Interface): این رابط پایه هست که عملیات مشترک رو برای همه آیتم های منو تعریف میکنه. میتونه شامل متدهایی مثل «getName()»، «getPrice()» و «getDescription()» باشه.
2. Leaf (Concrete Class): این یک آیتم منوی واحد مثل "برگر" یا "سالاد" رو نشون میده. «MenuItem» رو پیاده‌سازی میکنه و پیاده‌سازی‌های مشخصی رو برای متد های خود فراهم میکنه و جزئیات خاص اون آیتم رو برمی‌گردونه.
3. Composite (Concrete Class): این نشون دهنده یک دسته در منو مثل پیش غذاها هست. "MenuItem" رو پیاده سازی میکنه اما جزئیات خاص خود رو نداره. درعوض، فهرستی از مؤلفه‌های فرزند (سایر موارد «MenuItems» که میتونه هم «برگ» و هم دیگر اشیاء «کامپوزیت» باشن رو در خود داره. متد های رابط رو با تکرار از طریق مؤلفه‌های فرزند خود و تفویض تماس به روش‌های مربوطه اجرا میکنه. برای مثال، «getPrice()» قیمت کل رو با جمع کردن قیمت‌های همه اقلام فرزند خود محاسبه میکنه.
به صورت کلی این پترن هم مثل پترن های دیگه در شرایط خاص ممکنه کاربردی باشه. برای اطلاعات بیشتر به این مقالات مراجعه کنید:
- Article
- Article
- Article
#design_pattern
@CodeModule
⚡9🔥4
با پترن Facade پیچیدگی رو ساده کن! 🪼
الگوی Facade (یا façade) یک الگوی طراحی نرم افزاری هست که معمولاً در برنامه نویسی شی گرا استفاده میشه. این الگو مشابه نما در معماری هست که به عنوان یک رابط رو به جلو عمل میکنه که کدهای زیرین ساختاری پیچیده تری رو پوشش میدن. یک Facade میتونه:
- بهبود خوانایی و قابلیت استفاده یک کتابخانه با پوشاندن تعامل با اجزای پیچیده تر در پشت یک API واحد (و اغلب ساده شده) ارائه میده. همچنین یک رابط کاربری خاص برای عملکردهای عمومی تر ارائه میده.
دولوپر ها اغلب زمانی از الگوی طراحی نما استفاده میکنن که درک یک سیستم بسیار پیچیده یا دشوار هست، چرا که سیستم دارای کلاس های وابسته به یکدیگر هست یا کد سورس کد در دسترس نیست. این الگو پیچیدگی های سیستم بزرگتر رو پنهان میکنه و رابط کاربری ساده تری رو برای مشتری فراهم میکنه. این معمولا شامل یک کلاس wrapper هست که شامل مجموعه ای از اعضای مورد نیاز کلاینت هست. این اعضا از طرف کلاینت(مشتری) به سیستم دسترسی پیدا کرده و جزئیات پیاده سازی رو مخفی میکنه.
به عنوان مثال برنامه صبحگاهی خود رو تصور کنید. احتمالاً شامل چندین مرحله هست: دم کردن قهوه( یا چای)، روشن کردن چراغ ها، پخش موسیقی. هر یک از این اقدامات ممکنه شامل تعامل با دستگاه ها یا برنامه های جداگانه باشه.
الگوی طراحی نما مثل داشتن یک دکمه دستی "Morning Magic" روی میز خواب شما هست:
- سیستم پیچیده: وسایل مختلف، چراغ ها، بلندگوها نشان دهنده زیرسیستم پیچیده هستن. تعامل با هر یک به صورت جداگانه میتونه دست و پا گیر باشه.
- Facade (دکمه جادویی صبح): این دکمه به عنوان Facade عمل میکنه. این یک رابط واحد - یک دکمه ساده - برای فعال کردن کل برنامه صبحگاهی فراهم میکنه.
به صورت کلی الگوی نما، در برنامه نویسی شی گرا، مانند نمای ساختمان در معماری عمل میکنه. جلوی ساده‌ای رو ارائه میکنه که عملکرد پیچیده درونی رو پنهان میکنه. در اصطلاح نرم افزاری، کلاسی هست که رابط کارآمد (streamlined interface) رو برای یک زیرسیستم یا کتابخانه پیچیده فراهم میکنه. برای اطلاعات بیشتر این مقالات ممکنه کمک کننده باشه:
- Article
- Article
- Article
#design_pattern
@CodeModule
الگوی Facade (یا façade) یک الگوی طراحی نرم افزاری هست که معمولاً در برنامه نویسی شی گرا استفاده میشه. این الگو مشابه نما در معماری هست که به عنوان یک رابط رو به جلو عمل میکنه که کدهای زیرین ساختاری پیچیده تری رو پوشش میدن. یک Facade میتونه:
- بهبود خوانایی و قابلیت استفاده یک کتابخانه با پوشاندن تعامل با اجزای پیچیده تر در پشت یک API واحد (و اغلب ساده شده) ارائه میده. همچنین یک رابط کاربری خاص برای عملکردهای عمومی تر ارائه میده.
دولوپر ها اغلب زمانی از الگوی طراحی نما استفاده میکنن که درک یک سیستم بسیار پیچیده یا دشوار هست، چرا که سیستم دارای کلاس های وابسته به یکدیگر هست یا کد سورس کد در دسترس نیست. این الگو پیچیدگی های سیستم بزرگتر رو پنهان میکنه و رابط کاربری ساده تری رو برای مشتری فراهم میکنه. این معمولا شامل یک کلاس wrapper هست که شامل مجموعه ای از اعضای مورد نیاز کلاینت هست. این اعضا از طرف کلاینت(مشتری) به سیستم دسترسی پیدا کرده و جزئیات پیاده سازی رو مخفی میکنه.
به عنوان مثال برنامه صبحگاهی خود رو تصور کنید. احتمالاً شامل چندین مرحله هست: دم کردن قهوه( یا چای)، روشن کردن چراغ ها، پخش موسیقی. هر یک از این اقدامات ممکنه شامل تعامل با دستگاه ها یا برنامه های جداگانه باشه.
الگوی طراحی نما مثل داشتن یک دکمه دستی "Morning Magic" روی میز خواب شما هست:
- سیستم پیچیده: وسایل مختلف، چراغ ها، بلندگوها نشان دهنده زیرسیستم پیچیده هستن. تعامل با هر یک به صورت جداگانه میتونه دست و پا گیر باشه.
- Facade (دکمه جادویی صبح): این دکمه به عنوان Facade عمل میکنه. این یک رابط واحد - یک دکمه ساده - برای فعال کردن کل برنامه صبحگاهی فراهم میکنه.
به صورت کلی الگوی نما، در برنامه نویسی شی گرا، مانند نمای ساختمان در معماری عمل میکنه. جلوی ساده‌ای رو ارائه میکنه که عملکرد پیچیده درونی رو پنهان میکنه. در اصطلاح نرم افزاری، کلاسی هست که رابط کارآمد (streamlined interface) رو برای یک زیرسیستم یا کتابخانه پیچیده فراهم میکنه. برای اطلاعات بیشتر این مقالات ممکنه کمک کننده باشه:
- Article
- Article
- Article
#design_pattern
@CodeModule
refactoring.guru
Facade
Facade is a structural design pattern that provides a simplified interface to a library, a framework, or any other complex set of classes.
🔥10⚡3👌3
5 تا از بهترین دیزاین پترن های GoF که پیشنهاد میدم از دست ندید.
- دیزاین پترن Bridge
- دیزاین پترن Singletoon
- دیزاین پترن Builder
- دیزاین پترن Proxy
- دیزاین پترن Decorator
#design_pattern
@CodeModule
- دیزاین پترن Bridge
- دیزاین پترن Singletoon
- دیزاین پترن Builder
- دیزاین پترن Proxy
- دیزاین پترن Decorator
#design_pattern
@CodeModule
Telegram
Code Module | کد ماژول
با این پترن پل درست کنید! 🦦
پترن Bridge یک دیزاین پترن Structural و جزو 23 الگو GoF هست، که در مهندسی نرم‌افزار استفاده میشه و به معنای جدا کردن یک انتزاع از اجرای اون می‌باشد به طوری که این دو میتونن به طور مستقل، متفاوت باشن. به عبارت دیگه الگوی Bridge…
پترن Bridge یک دیزاین پترن Structural و جزو 23 الگو GoF هست، که در مهندسی نرم‌افزار استفاده میشه و به معنای جدا کردن یک انتزاع از اجرای اون می‌باشد به طوری که این دو میتونن به طور مستقل، متفاوت باشن. به عبارت دیگه الگوی Bridge…
👌12