Factory Method

یک رابط برای ایجاد اشیا در یک ابر کلاس فراهم می کند ، اما به کلاسهای فرعی اجازه می دهد نوع اشیا ایجاد شده را تغییر دهند.

Abstract Factory

به شما اجازه می دهد اشیا  هم خانواده یا مرتبط را بدون تعیین کلاسهای اصلی آنها تولید کنید.

Builder

به شما امکان می دهد اشیا complex پیچیده را گام به گام بسازید. این الگو به شما امکان می دهد انواع مختلفی از نمایش یک شی را با استفاده از کد ساخت یکسان تولید کنید.

Prototype

به شما اجازه می دهد اشیا موجود را بدون اینکه کدتان به کلاس آنها وابسته باشد ، کپی کنید.

Singleton

به شما اجازه می دهد تا از یک شیء فقط یک نمونه در سراسر برنامه بسازید

بازدیدها: 4

نوشته الگوهای طراحی خلاقانه – Creational Design Patterns اولین بار در بازسازی. پدیدار شد.

الگوهای طراحی از نظر پیچیدگی ، سطح جزئیات و مقیاس کاربرد برای کل سیستم در حال طراحی متفاوت هستند. تشبیه به راه سازی را دوست دارم: شما می توانید با نصب برخی از چراغ های راهنمایی و یا ایجاد یک تپل چند سطحی با معابر زیرزمینی برای عابرین پیاده ، یک تقاطع را ایمن تر کنید.

به ابتدایی ترین و سطح پایین ترین الگوها اغلب اصطلاحا منفرد گفته می شود. آنها معمولاً فقط در یک زبان برنامه نویسی کاربرد دارند.

کلی ترین و سطح بالاترین الگوها، الگوهای معماری است. توسعه دهندگان می توانند این الگوها را تقریباً به هر زبانی پیاده سازی کنند. برخلاف الگوهای دیگر ، می توان از آنها برای طراحی معماری کل برنامه استفاده کرد.

علاوه بر این ، همه الگوها را می توان با توجه به هدف آنها طبقه بندی کرد. این مطلب شامل سه گروه اصلی از الگوها است:

• الگوهای خلاقیت مکانیسم های ساخت شی را ایجاد می کنند که انعطاف پذیری و استفاده مجدد از کد موجود را افزایش می دهد.

• الگوهای ساختاری نحوه جمع آوری اشیا و کلاسها را به ساختارهای بزرگتر توضیح می دهد ، در حالی که سازه ها را انعطاف پذیر و کارآمد نگه می دارد.

• الگوهای رفتاری از برقراری ارتباط موثر و تعیین مسئولیت بین اشیا مراقبت می کنند.

بازدیدها: 104

نوشته دسته بندی الگوهای طراحی اولین بار در بازسازی. پدیدار شد.

بازآرایی متد ها (Composing Methods)

بخش اعظمی از refactoring شامل اصلاح و بازآرایی متد ها است. در بیشتر موارد ، متدهای بیش از حد طولانی ریشه همه مشکلات هستند. مبهم بودن کد موجود در این متد ها منطق اجرا را پنهان می کند و درک متد را بسیار دشوار کرده و تغییر آن را سخت تر می کند.

تکنیک های refactoring در این گروه ساده سازی متد ها ، حذف کدهای تکراری و زمینه سازی برای پیشرفت های آینده است.

• Extract Method
• Inline Method
• Extract Variable
• Inline Temp
• Replace Temp with Query
• Split Temporary Variable
• Remove Assignments to Parameters
• Replace Method with Method Object
• Substitute Algorithm

انتقال متد ها و… بین کلاسها

این تکنیک های refactoring نشان می دهد که چگونه می توان با خیال راحت فانکشنالیتی ها را بین کلاس ها را جابجا کرد ، کلاس های جدید ایجاد کرد و جزئیات پیاده سازی را از دسترسی عمومی پنهان کرد

• Move Method
• Move Field
• Extract Class
• Inline Class
• Hide Delegate
• Remove Middle Man
• Introduce Foreign Method
• Introduce Local Extension

سازماندهی داده ها

این تکنیک های refactoring به پردازش داده ها کمک می کنند و داده های اولیه را با فانکشنالایتی کلاس غنی جایگزین می کنند. نتیجه مهم دیگر ، جدا کردن ارتباط بین کلاسها برای اینکه بتوان از آن ها بصورت مستقل استفاده کرد.

• Change Value to Reference
• Change Reference to Value
• Duplicate Observed Data
• Self Encapsulate Field
• Replace Data Value with Object
• Replace Array with Object
• Change Unidirectional Association to Bidirectional
• Change Bidirectional Association to Unidirectional
• Encapsulate Field
• Encapsulate Collection
• Replace Magic Number with Symbolic Constant
• Replace Type Code with Class
• Replace Type Code with Subclasses
• Replace Type Code with State/Strategy
• Replace Subclass with Fields

ساده سازی عبارات شرطی

شرط ها با گذشت زمان در منطق خود پیچیده تر می شوند و تکنیک های بیشتری برای مبارزه با این مسئله نیز وجود دارد.

• Consolidate Conditional Expression
• Consolidate Duplicate Conditional Fragments
• Decompose Conditional
• Replace Conditional with Polymorphism
• Remove Control Flag
• Replace Nested Conditional with Guard Clauses
• Introduce Null Object
• Introduce Assertion

ساده کردن فراخوانی های متد

این تکنیک ها فراخوانی های متد را ساده و قابل فهم تر می کنند. این به نوبه خود ، interface  های بین کلاس ها را ساده می کند

• Add Parameter
• Remove Parameter
• Rename Method
• Separate Query from Modifier
• Parameterize Method
• Introduce Parameter Object
• Preserve Whole Object
• Remove Setting Method
• Replace Parameter with Explicit Methods
• Replace Parameter with Method Call
• Hide Method
• Replace Constructor with Factory Method
• Replace Error Code with Exception
• Replace Exception with Test

پرداختن به تعمیم

انتزاع (Abstraction)گروهی از تکنیک های خود را دارد ، که در درجه اول با قابلیت حرکت در طول سلسله مراتب وراثت کلاس ، ایجاد کلاس ها و رابط های جدید و جایگزینی وراثت با تفویض و برعکس همراه است.

• Pull Up Field
• Pull Up Method
• Pull Up Constructor Body
• Push Down Field
• Push Down Method
• Extract Subclass
• Extract Superclass
• Extract Interface
• Collapse Hierarchy
• Form Template Method
• Replace Inheritance with Delegation
• Replace Delegation with Inheritance

بازدیدها: 91

نوشته تکنیکهای ریفکتور اولین بار در بازسازی. پدیدار شد.

در ادامه مباحث ریفکتورینگ به بوی کدها می پردازیم.

مگر کدها بو می دهند؟ اگر سعی کنید بوی آنها را حس می کنید.نشانه های بوی بد کد ها را بشناسیم تا آنها را پیدا کنیم.

بزرگها!

کلاسها و متدهایی که آنقدر بزرگ می شوند که کار کردن با آنها سخت می شود. البته اوایل بوی بد نمی دهند اما هرچه بگذرد بزرگتر می شوند و بوی بد تری میدهند

متدهای بزرگ (Long Methods)

متدهایی که شامل خطوط زیادی هستند. معمولا متدهایی با بیش از 10 خط را متدهای بزرگ می دانیم

کلاسهای بزرگ  (Larg Classes)

کلاسهایی که تعداد زیادی فیلد و پراپرتی و متد را شامل می شوند

وسواس اولیه(Primitive Obsession)

• استفاده از کلاسها و آبجکتها به جای مقدارهای ساده اولیه (مثل bool  ,int,..)
• استفاده از مقادیر ثابت (const) برای رمز گذاری اطلاعات (مثل USER_ADMIN_ROLE = 1 برای اعطای دسترسی به کاربر ادمین)
• استفاده از مقادیر رشته ای ثابت برای نام فیلدها در آرایه ها

پارامترهای زیاد(Long Parameter List)

بیش از سه یا چهار پارامتر برای یک متد نشانه این اشتباه است

توده داده(Data Clumps)

برخی اوقات قسمتهای مختلفی از کد شامل گروه هایی از گروههای یکسان از متغیرها (مانند پارامترهای اتصال به یک پایگاه داده) هستند. باید هر قطعه به کلاس مربوطه خودش منتقل شود

استفاده بد از شیء گرایی object orientation

سوئیچ ها(Switch Statements)

کد شامل تعداد زیادی switch یا if است

فیلدهای موقت (Temporary Field)

فیلدهای موقتی که فقط در بخش مورد استفاده کارایی دارند و در بقیه کد خالی هستند

ارث بری بدرد نخور (Refused Bequest)

اگر یک کلاس فقط از تعدادی از متد ها و پراپرتی های کلاسی که از آن مشتق شده استفاده می کند، این ارث بری بدرد نخور است.

متدهای نالازم به سادگی به متدهای بدون استفاده تبدیل می شوند یا دوباره تعریف می شوند و خطا ایجاد می کنند

کلاس های جایگزین با رابط های مختلف (Alternative Classes with Different Interfaces)

دو کلاس دارای توابعی هستند که کار یکسانی را انجام می دهند اما نام متدهای متفاوتی دارند.

تغییر ناپذیری

این بو به این معنی است که اگر شما نیاز به تغییر چیزی در یک مکان در کد خود دارید ، باید در مکان های دیگر نیز تغییرات زیادی ایجاد کنید. در نتیجه توسعه برنامه بسیار پیچیده تر و گران تر می شود.

تغییرات واگرا (Divergent Change)

هنگام ایجاد تغییر در یک کلاس ، مجبور می شوید بسیاری از متد های نامربوط را تغییر دهید. به عنوان مثال ، هنگام افزودن یک نوع محصول جدید ، باید متدهای یافتن ، نمایش و سفارش محصولات را تغییر دهید.

تشریح انفجاری (Shotgun Surgery)

ایجاد هرگونه تغییر ، مستلزم ایجاد تغییرات کوچک در بسیاری از کلاسهای مختلف است.

سلسله های وراثت موازی (Parallel Inheritance Hierarchies)

هر وقت یک زیرکلاس (sub class) برای یک کلاس ایجاد می کنید ، میبینید که لازم یک زیر کلاس برای یک کلاس دیگر هم بسازید.

اضافات

به هرچیزی گفته می شود که نبودش بهتر از بودنش است و نبودنش کد را ساده تر می کند

کامنتها(Comments)

متدی که با کامنت ها پر شده است

کد کپی(Duplicate Codes)

دو قطعه کد تقریباً یکسان به نظر می رسند.

کلاس تنبل(Lazy Class)

فهم و حفظ کلاس ها همیشه به وقت و هزینه نیاز دارد. بنابراین اگر یک کلاس به اندازه کافی توجه شما را جلب نکرد ، باید حذف شود.

کلاس داده(Data Class)

کلاس داده به یک کلاس اطلاق می شود که فقط فیلدها ها و متد های خام را برای دسترسی به آنها (getter  و  setter) دارد. این ها به سادگی توسط کلاسهای دیگر استفاده می شوند. این کلاس ها هیچ فانکشن اضافی ندارند و نمی توانند به طور مستقل روی داده هایی که در اختیار دارند کار کنند.

کد مرده(Dead Code)

متغیر ، پارامتر ، فیلد ، متد یا کلاسی که دیگر استفاده نمی شود (معمولاً به دلیل اینکه منسوخ است).

کلیت اضافی(Speculative Generality)

یک کلاس ، متد ، فیلد یا پارامتر استفاده نشده که نیازی به آن وجود ندارد.

ارتباطات (Couplers)

این گروه شامل Coupling های زیادی بین کلاسها و یا استفاده بیش از حد از delegation است

ویژگی حسادت(Feature Envy)

یک متد بیشتر از داده های خود به داده های یک شی دیگر دسترسی پیدا می کند.

صمیمیت نامناسب(Inappropriate Intimacy)

یک کلاس از فیلدها و متدهای داخلی کلاس دیگر استفاده می کند.

زنجیرهای پیامها(Message Chains)

در کد یک سری از فراخوانی ها را مشاهده می کنید که شبیه $a->b()->c()->d()هستند

مردی در میانه(Middle Man)

اگر یک کلاس فقط یک عمل را انجام دهد ، کار را به کلاس دیگری واگذار کند ، چرا اصلاً وجود دارد؟

دیگر بو ها

موارد زیر در هیچ دسته بندی جای نمی گیرند

کلاس کتابخانه ناقص (Incomplete Library Class)

دیر یا زود کتابخانه ها (libraries) دیگر پاسخگوی نیاز کاربر نخواهند بود. راه ایجاد تغییرات در کتابخانه ها است که چون عموما فقط خواندنی (read only) هستند امکانپذیر نیست.

بازدیدها: 156

نوشته بوی بدِ کد – Bad Smells اولین بار در بازسازی. پدیدار شد.

ریفکتور باید شامل یک سری تغییرات کوچک در راستای ساده تر و قابل فهم تر شدن کدها باشد.

چک لیست ریفکتورینگ صحیح

کد باید تمیز تر شود

اگر بعد از ریفکتور باز هم کد کثیف دارید فقط وقتتان را هدر داده اید. باید سعی کنید که بفهمید چرا این اتفاق افتاده است

البته ممکن است این اتفاق در کدهای خیلی کثیف اتفاق بیفتد و می شود در چند  مرحله کم کم بهبود را ایجاد کرد

در این حالت ممکن است مجبور باشید بخشهایی از کد را بازنویسی کنید، اما قبل از آن باید حتما تست نوشته باشید و برای اینار زمان اختصاص داده باشید. در غیر اینصورت با صرف این همه کار هم به نتیجه ای نخواهید رسید

عملکرد جدید نباید در خلال ریفکتور ایجاد شود

هیچوقت ریفکتورینگ را با تولید قابلیت جدید قاطی نکنید. سعی کنید این موارد را حداقل در commit های جداگانه انجام شود

همه تستها باید بعد از ریفکتور پاس شوند

به دو دلیل ممکن است تستها بعد از ریفکتور کار نکنند:

در خلال ریفکتور(بازسازی) کد ها خطا ایجاد کرده باشید» مهم نیست می توانید به پیش بروید و اشکالات را رفع کنید

تستها خیلی سطح پایین باشند» به عنوان مثال شما متدهای کلاسهای private را تست کرده اید

در این حالت خود تستها اشکال دارند. می توانید خود تستها را ریفکتور کنید یا تستهای در سطح بالاتر بنویسید. بهترین راه برای جلوگیری از این مشکل نوشتن تستها به سبک BDD است.

بازدیدها: 130

نوشته چطور ریفکتور کنیم؟ اولین بار در بازسازی. پدیدار شد.

در نوشته های قبلی فهمیدیم که لازم است ریفکتور(بازسازی یا اصلاح کد) داشته باشیم. و اما یک قانون:

قانون 3

1. وقتی کاری برای بار اول انجام می شود، فقط انجام می دهیم
2. وقتی کار مشابهی را برای بار دوم انجام می دهیم، یواشکی! انجام می دهیم
3. اگر برای برای سوم شد حتما باید ریفکتور کنیم و کدها را اصلاح کنیم!

چه زمانی باید ریفکتور کرد؟

• زمانی که یک فیچر جدید تولید می کنیم.

وقتی که فیچر جدیدی اضافه میکینم خیلی وقتها مجبور میشویم اول کدهای کثیف قبلی را تمیز کنیم تا بفهمیم چه کار می کنیم. تمیز کردن کد کار را برای نفرات بعدی هم ساده تر می کند

• زمان رفع باگها

حالا که برای رفع یک باگ تا اینجای کد آمده ایم! حیف نیست که کد آن را تمیز نکنیم و رد شویم. با این کار یک تیر و دو نشان زده ایم. هم باگ رفع شده و هم قسمتی از کد تمیز شده است.

• در زمان Code Review

شاید این مرحله آخرین مرحله از خداحافظی شما با آن کد باشد و به این زودی ها به آن برنگردید. در این زمان هم می شود ریفکتور را در نظر گرفت. در این مرحله اشکالات ساده را برطرف می کنیم و زمان برای رفع اشکالات بزرگتر را برآورد می کنیم.

ریفکتورینگ باعث ساده سازی و قابل فهم شدن کد می شود اما باید تاثیرات پرفورمنسی آن در نظر گرفته شود و ضمنا نباید باعث ایجاد functionality جدید بشود.

نفس ریفکتور در جلسات بازبینی کد نباید باعث جلوگیری از merge یا checkin کد شود.

بازدیدها: 128

نوشته چه زمانی باید ریفکتور کنیم؟ اولین بار در بازسازی. پدیدار شد.

هر کسی تمام تلاش خود را می کند تا بهترین کد را از ابتدا بنویسد. احتمالاً هیچ برنامه نویسی نیست که عمداً کد ناخوشایند و به ضرر پروژه بنویسد. اما در چه مرحله ای کد تمیز، کثیف می شود؟

استعاره “بدهی فنی” در مورد کد بد در ابتدا توسط Ward Cunningham پیشنهاد شده.

اگر از یک بانک وام دریافت کنید، به شما این امکان را می دهد که سریعتر خرید خود را انجام دهید. در این حالت شما باید مبلغ بیشتری را به عنوان سود پرداخت کنید. نیازی به گفتن نیست ، حتی می توانید آنقدر این کار را ادامه دهید که میزان بهره بیش از درآمد کل شما باشد و بازپرداخت کامل را غیرممکن می کند.

همین اتفاق می تواند با کد رخ دهد. شما می توانید به طور موقت بدون نوشتن تست برای ویژگی های جدید، به کار سرعت بخشید ، اما این کار به تدریج هر روز پیشرفت شما را کند می کند تا اینکه در نهایت با نوشتن تست ها بدهی خود را پرداخت کنید.

علل بروز بدهی فنی

  فشار بیزنس

بعضی اوقات شرایط تجاری ممکن است شما را وادار کند فیچر های خود را قبل از اتمام کار ارائه کنید. در این حالت تکه های ناجوری در کد ظاهر می شوند تا اتمام پروژه مخفی می شود.

  عدم درک عواقب بدهی فنی

صرف نظر از درک بدهی فنی، گاهی اوقات کارفرمای شما ممکن است درک نکند که بدهی فنی باعث کاهش بهره وری می شود. این  موضوع می تواند اختصاص دادن زمان تیم را به refactoring بسیار دشوار کند زیرا مدیریت ارزش آن را نمی بیند.

  عدم موفقیت در برابر انسجام دقیق اجزاء

در شرایطی این پروژه به جای ماژولهای انفرادی شبیه به یک تکه سنگ یکپارچه باشد، هرگونه تغییر در یک قسمت از پروژه ، بخش های دیگر را تحت تأثیر قرار می دهد. در این حالت کار بسیار دشوار تر است زیرا جدا کردن این اجزاء از هم خیلی سخت است.

نبود تست

فقدان بازخورد فوری ، پیدا کردن راه حلهای سریع را از بین برده و ایجاد ریسک می کند. در بدترین حالت ، این تغییرات بدون تست های قبلی به مرحله تولید منتقل می شوند و عواقب آن می تواند فاجعه بار باشد. به عنوان مثال ، ممکن است یک حلقه ثابت به دنبال یک ایمیل آزمایشی عجیب به هزاران مشتری ارسال شود یا حتی بدتر از آن ، یک بانک اطلاعاتی کامل را افشاء کند.

نبود مستند سازی

این امر باعث بروز مشکل در معرفی افراد جدید به پروژه می شود و در صورت ترک افراد اصلی پروژه توسعه متوقف خواهد شد.

 عدم تعامل بین اعضای تیم

اگر پایگاه دانش در سراسر شرکت توزیع نشود ، افراد در نهایت با درک قدیمی از روندها و اطلاعات مربوط به پروژه کار می کنند. این وضعیت زمانی می تواند تشدید شود که توسعه دهندگان جدید به طور نادرست توسط مربیان خود آموزش ببینند.

 توسعه همزمان و طولانی مدت در برنچ های(Branches) مختلف

این امر می تواند به انباشت بدهی فنی منجر شود ، که در هنگام ادغام تغییرات(Merge) افزایش می یابد. هرچه تغییرات بیشتر توسط اعضای تیم بصورت منفرد (Isolated) انجام شود کل بدهی فنی بیشتر می شود.

 تأخیر در اصلاح کد(Refactoring ریفکتور)

الزامات پروژه به طور مداوم در حال تغییر است و ممکن است در بعضی مواقع مشخص شود که قسمت هایی از کد منسوخ و دست و پا گیر شده اند و برای برآورده کردن نیازهای جدید باید دوباره طراحی شوند.

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

نبود نظارت بر تطابق

وقتی که هر کسی بر روی پروژه بر طبق روش خودش کد نویسی را ادامه دهد این اتفاق خواهد افتاد و کدها یکدست نخواهند شد.

 بی کفایتی

در شرایطی که توسعه دهنده واقعا نمی داند چگونه کد مناسبی را بنویسد و در واقع توان فنی لازم را ندارد.

بازدیدها: 171

نوشته بدهی فنی – Technical debt اولین بار در بازسازی. پدیدار شد.