https://virgool.io/feed/@m_54275199 fa 2026-06-10 12:33:06 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@m_54275199 https://virgool.io/@m_54275199/%DA%AF%D8%B0%D8%B1%DB%8C-%D8%A8%D8%B1-design-pattern-%D9%87%D8%A7-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-b8pip0nwkwfz توی پست قبلی design pattern های creational رو معرفی کردیم. توی این پست یه معرفی از الگو های طراحی structural داریم. همونطور که گفتم مرجع این پست سایت خوب refactoring هست.آداپتور (Adapter)فرض کنید یه سیستم مانیتورینگ بازار سهام دارید. سیستم شما داده هاش رو از چندین منبع با فرمت XMP دریافت میکنه. یه جایی شما تصمیم میگیرید از یه کتابخونه هوشمند تجزیه و تحلیل بازار استفاده کنید. اون کتابخونه دیتاهاش رو با فرمت JSON میده. چیکار میکنیم؟ یه کلاس آداپتور طراحی میکنیم که اطلاعات رو به صورت JSON دریافت کنه و به صورت XML خروجی بده. خیلی خوبه.وقتایی که آبجکت های ما نیاز به استفاده از interface های ناسازگار دارن این دیزاین پترن میاد به کمک ما.پل (Bridge)فرض کنید شما یه کلاس طراحی شکل های هندسی دارید. الان شما دو تا زیر کلاس دایره و مربع دارید. بعدا تصمیم میگیرد دو تا رنگ هم توی کلاستون داشته باشید قرمز و زرد. اگه بخواید همه چیز رو بریزید کف همین کلاستون. باید به جای دو تا زیر کلاس الان چهار تا زیر کلاس داشته باشید. دایره زرد. دایره قرمز. مربع زرد. مربع قرمز. یه جای کار میلنگه. چیکار کنیم؟ میتونیم رنگ ها رو تحت یه interface استخراج کنیم. و کلاس شکلمون رو از اون implement کنیم. در مورد هر کدوم از ابعاد دیگه ای که میخوایم به آبجکت های نهاییمون اضافه کنیم میتونیم همین کارو کنیم.دیزاین پترن پل به شما امکان می دهد یک کلاس بزرگ رو با تقسیم کردن زیرکلاس ها به دسته هاس نزدیک به هم ساده سازی کنید.مرکب (Composite)این الگوی طراحی برای ساختار هایی که به صورت درختی قابل پیاده سازی باشن استفاده میشه. بیایم یه مثال بزنیم. فرض کنید یه سیستم فروش و پست دارید. یسری محصول و یسری جعبه. هر جعبه میتونه توش یسری جعبه و یسری محصول دیگه باشه.. قیمت یه بسته بندی رو چجوری حساب کنیم؟ راه حلی که design pattern مرکب به ما میده اینه:قیمت هر بسته = قیمت محصول (روی هر محصول نوشته شده) + مجموع قیمت محتویات جعبه داخلش. قیمت جعبه ها ی داخلی هم همینطور محاسبه میشه. قیمت محصولات داخل هر جعبه + مجموع قیمت هر جعبه ای که توشه. به تصویر زیر نگاه کنید: زهرا زهرا Wed, 01 Jun 2022 14:31:29 +0430 https://virgool.io/@m_54275199/design-patterns-xflcue7kobph بعضی وقتا برامون پیش میاد که می‌خوایم توی کدمون یه کاری انجام بدیم، اما خبر نداریم از قبل براش الگو هایی طراحی شده که دونستن اونا خیلی کارمون رو جلو میندازه. پس خیلی خوب میشه اگه با تعریف و کاربردهای design pattern هایی که بیشتر استفاده میشه یه آشنایی کلی داشته باشیم. توی این پست میخوایم یه تعریف کلی از کاربردای تعدادی از design pattern ها داشته باشیم.قبل از همه بگم که سایت ریفکتورینگ در زمینه design pattern یا الگوهای طراحی خیلی خوب عمل کرده، من هم برای نگارش این پست ازین سایت استفاده کردم. این سایت design pattern ها رو توی سه تا دسته بدی قرار داده:ایجاد کردنی (Creational)این دسته از design patter ها روش های مختلف ساختن شئ رو بهمون میگن. چند تا الگو هایی که توی این دسته قرار میگیرن:کارخونه (Factory)مثلا شما یه کسب و کار مدیریت حمل و نقل دارید. کسب و کارتون هنوز کوچیکه و فعلا فقط پیک موتوری دارید. دیزاین پترن کارخونه پیشنهاد میکنه به جای اینکه فقط یه کلاس موتور بسازید. بیاید یه اینترفیس بسازید و اسمش رو بزارید حمل و نقل همه متد هایی که یه وسیله ی حمل و نقل باید اونو داشته باشن رو توی این بسازید و حالا کلاس پیک موتوری‌تون رو ازون implement کنید. این خیلی بهتره. چون بعدا خیلی راحت و بدون اینکه نگران باشید ساختار کدتون به هم بخوره میتونید بهش سواری، وانت، یا وسایل دیگه‌ای اضافه کنید. همونطور که میدونید این اصل open/close سالید رو هم فراهم میکنه.کارخونه، یه interface برای ساختن اشیاء فراهم میکنه. یه جوری که به زیرکلاس ها اجازه میده نوع اشيایی که ایجاد میشه رو تغییر بدن.دیزاین پترن کارخونه/ factory design patternکارخونه انتزاعی! (Abstract Factory)این الگوی طراحی مثل الگوی طراحی قبلی هست با این تفاوت که اینجا چند تا interface داریم و آبجکت های ما میتونن یک یا چند تای اونو پیاده سازی کنن. برای این هم یه مثال بزنیم:شما فرض کن یه سیستم فروش سرویس چوب منزل داری. یعنی هم مبلمان هم میز ناهار خوری هم انواع صندلی یا حتی مبل های تک نفره. خب مثلا ما یه interface پدر داریم به اسم «سرویس چوب». این interface خودش سه تا کلاس فرزند داره: «مبل»، «صندلی»، «میز». خیلی عالی. حالا ما مبل های تک نفرمون رو کجا بزاریم؟کارخونه انتزاعی میگه تو الان ۳ تا دسته بندی داری «مبل»، «صندلی» و «میز». هر کدوم ازینا رو یک interface کن. حالا هر کدوم از محصولاتت میتونن کلاس های فرزند باشن که یک یا چند تا از سه تا interface «مبل»، «صندلی» و «میز» رو پیاده سازی میکنن. حالا مبل های تک نفرمون میتونن هم «مبل» رو implement کنن و هم «صندلی» رو.الگوی طراحی کارخانه انتزاعی/ abstract factory design patternسازنده (Builder)فرض کنید شما یه سیستمی طراحی خونه دارید. خونه ها اجزا خیلی زیادی رو میتونن داشته باشن یا نداشته باشن. مثلا در، پنجره، سقف، سیستم گرمایشی، حیاط جلویی، حیاط پشتی، سیم کشی برق، شیر آلات، ایوون و ... اینجا الگوی طراحی سازنده پیشنهاد میکنه که شما برای هر کدوم از اجزا خونه متد سازنده داشته باشید و سازنده خونه بیاد این متد ها رو مرحله به مرحله رو فراخوانی کنه. مطمئنا بعضی از این متدها پیاده سازیشون الزمانی هست و بعضی ها اختیاری.این الگوی طراحی بهمون کمک میکنه که با یه کلاس یکسان شکل ها و نوع های مختلفی از آبجکت ها رو مرحله به مرحله بسازیم. الگوی طراحی سازنده/ builder design patternنمونه اولیه (Prototype)این الگوی طراحی به ما کمک میکنه که از یه آبجکت موجود کپی برداری کنیم، بدون اینکه بخوایم متدها یا پراپرتی های کلاسش رو صدا بزنیم. مثلا چی؟مثلا شما یه آبجکت از کلاس ربات رو با یه فرایند خیلی طولانی و پیچیده ساختید. حالا نیاز دارید یه ربات دیگه داشته باشید دقیقا شبیه ربات قبلی علاوه بر سیبیل. مطمئنا حوصله نداریم بریم از اول یه ربات دیگه بسازیم. اینجا این الگوی طراحی میاد کمکمون. یه کپی از ربات اولیتون برمیدارید. حالا یه آبجکت مستقل داریم. میتونید بهش سیبیل اضافه کنید یا هر تغییر دیگه ای روش انجام بدید.الگوی طراحی نمونه اولیه/ prototype design pattern الگوی یگانه (Singleton)این الگوی طراحی بهمون کمک میکنه که کلاسمون رو جوری بسازیم که ازش فقط و فقط یه آبجکت داشته باشیم و از سراسر برنامه هم بتونیم به اون یدونه آبجکت دسترسی داشته باشیم.مثلا برای اتصال به دیتابیس ما فقط یه بار باید به دیتابیس کانکشن بزنیم و ازون به بعد هر بار کاری با دیتا بیس داشتیم از همون آبجکت قبلی استفاده کنیم. اینجا دیزایت پترن singleton برامون این رو فراهم میکنه زهرا زهرا Mon, 30 May 2022 11:46:23 +0430 https://virgool.io/@m_54275199/dry-wet-kiss-yagni-ep0fg067z6zk DRY“Don’t Repeat Yourself” خودتو تکرار نکنبه طور خلاصه این اصل میگه که: از کد های تکراری پرهیز کن. رفتار یک کد در سیستم باید یکتا باشد.هدف DRY کاهش تکرار الگوریتم ها و الگو ها، برای حفظ یکتایی و دوری از افزونگیه. اما فقط به اینجا ختم نمیشه.. برای DRY عجله نکن برو سمت WET:WET“Write Everything Twice” یا “Write Every Time” هر بار بنویس یا هر چیزی رو دوبار بنویس چیزی که توی ذهن شما در مورد DRY میگذره:ویکی پدیا: DRY مخفف عدم تکرار یک کد دوبار است.شما: آهان، باشه من همه تکرارهام را با abstraction جایگزین می کنم.به نظر راه حل خوبی میاد، اما اینطور نیست. این abstraction معمولا اشتباهه. چرا؟ یه تکرار توی کدت میبینی.شما تکرار را در قالب یه abstraction جدید (method یا class) استخراج و جایگزین میکنیدفکر می کنید کدتون کامله.زمان میگذره.مدیر محصول نیازمندی‌های جدیدی داره. abstraction یا انتزاعی که نوشتید تقریبا کامله. اما نیازمندی‌های جدید ۹۵ درصد با abstraction شما تطابق داره. ۵ درصد باقی‌مونده رو پوشش نمیده. حالا به جای اینکه ۹۵ درصد کد رو برای یه abstraction جدید کپی کنی، ترجیح میدی abstraction ـت رو تغییر بدی. مثلا یک عبارت شرطی if..else اضافه کنی. حالا abstraction شما برای موارد مختلف رفتار متفاوتی داره. همونطور که انتظار داری.یک نیاز جدید دیگر از راه می رسه. یک شرط جدید دیگه. الزامات دیگه و شرط های دیگه.تبریک می‌گم، شما یک abstraction اشتباه ایجاد کرده اید.کد دیگه یک abstraction واحد و مشترک رو نشون نمی‌ده. این یک abstraction پر از شرطه. درکش سخت و پایداریش کم میشه و هر ویژگی جدید کد رو پیچیده تر می کنه.پس چیکار باید کرد؟ “Write Everything Twice” همه چیز را دوبار بنویس.اینو یادت باشه:تکرار به مراتب کم هزینه تر از یک انتزاع اشتباه است.برای هر نیازمندی جدید یه abstraction ایجاد کن. همه قسمت های تکراریش رو کپی کن. عیبی نداره. بعد از مدتی میتونی نیازمندی‌های جدید رو پیش‌بینی کنی، کدت رو تجزیه و تحلیل کنی و abstraction های مناسب رو استخراج کنی.KISS Keep It Simple, Stupid” یا “Keep It Stupid Simple“ اون رو خیلی احمقانه، ساده نگه دار. یا جمله اولی میگه: احمق! اونو ساده نگه دار.این اصل میگه که باید طراحی کد رو تا جایی که ممکنه ساده کرد، تا جایی که حتی احمق ها هم اونو متوجه بشن! رعایت این اصل این مزیت ها رو داره:توسعه الان و آینده کدتون رو توی تیم ساده تر میکنه. چون کدتون برای هر کسی قابل فهمه یا میتونه با کنکاش کمی اون رو بفهمه.با اصل اول SOLID یعنی Single Responsibility همپوشانی داره.مارتین فلور یه حرف جالبی میزنه:هر احمقی می تواند کدی بنویسد که کامپیوتر آن را بفهمد. برنامه نویسان خوب کدی را می نویسند که انسان بتواند آن را بفهمد.YAGNI“You Aren’t Gonna Need It” تو به آن نیاز نخواهی داشتاین هم یه اصل دیگه توی توسعه نرم افزاره که میگه: همیشه چیزها را زمانی که واقعا به آنها نیاز دارید اجرا کنید، نه زمانی که فقط پیش بینی می کنید که به آنها نیاز دارید. شاید شما موقع شروع توسعه نرم افزارتون تصور کنید چیز های زیادی هست که بعدا بهشون نیاز پیدا خواهید کرد. اما نباید تا وقتی که واقعا لازمشون دارید پیاده سازیشون کنی. زهرا زهرا Tue, 10 May 2022 09:30:06 +0430