برچسب: ریفکتور

الگوهای طراحی خلاقانه – Creational Design Patterns

Factory Method یک رابط برای ایجاد اشیا در یک ابر کلاس فراهم می کند ، اما به کلاسهای فرعی اجازه می دهد نوع اشیا ایجاد شده را تغییر دهند. Abstract Factory به شما اجازه می دهد اشیا  هم خانواده یا مرتبط را بدون تعیین کلاسهای اصلی آنها تولید کنید. Builder به شما امکان می دهد […]

الگوهای رفتاری -Behavioral Design Patterns

Chain of Responsibility به شما امکان می دهد درخواست ها را از طریق زنجیره ای از کلاسها منتقل کنید. با دریافت یک درخواست ، هر یک از کارگزاران (کلاسها) تصمیم می گیرند که درخواست را پردازش کنند یا آن را به مدیر بعدی در زنجیره منتقل کنند. Command یک درخواست را به یک شی مستقل […]

الگوهای طراحی ساختاری – Structural Design Patterns

الگوهای ساختاری چگونگی جمع آوری اشیا و کلاسها را به ساختارهای بزرگتر توضیح می دهد در حالی که این ساختارها را انعطاف پذیر و کارآمد نگه می دارد. Adapter به اشیا دارای رابط کاربری (interface)ناسازگار امکان همکاری می دهد. Bridge به شما امکان می دهد یک کلاس بزرگ یا مجموعه ای از کلاسهای نزدیک را […]

دسته بندی الگوهای طراحی

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

تکنیکهای ریفکتور

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

بوی بدِ کد – Bad Smells

بوی بد کد

در ادامه مباحث ریفکتورینگ به بوی کدها می پردازیم. مگر کدها بو می دهند؟ اگر سعی کنید بوی آنها را حس می کنید.نشانه های بوی بد کد ها را بشناسیم تا آنها را پیدا کنیم. بزرگها! کلاسها و متدهایی که آنقدر بزرگ می شوند که کار کردن با آنها سخت می شود. البته اوایل بوی […]

چطور ریفکتور کنیم؟

refactoring checklist

ریفکتور باید شامل یک سری تغییرات کوچک در راستای ساده تر و قابل فهم تر شدن کدها باشد. چک لیست ریفکتورینگ صحیح کد باید تمیز تر شود اگر بعد از ریفکتور باز هم کد کثیف دارید فقط وقتتان را هدر داده اید. باید سعی کنید که بفهمید چرا این اتفاق افتاده است البته ممکن است […]

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

refactoring

در نوشته های قبلی فهمیدیم که لازم است ریفکتور(بازسازی یا اصلاح کد) داشته باشیم. و اما یک قانون: قانون 3 وقتی کاری برای بار اول انجام می شود، فقط انجام می دهیم وقتی کار مشابهی را برای بار دوم انجام می دهیم، یواشکی! انجام می دهیم اگر برای برای سوم شد حتما باید ریفکتور کنیم […]

بدهی فنی – Technical debt

Technical Debt

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