مقدمه

پیش از این راجع به Bad Smell و کاربرد آن در مهندسی نرم افزار صحبت کردیم "سلسله های وراثت موازی" یکی از 22 نوع Bad Smell میباشد.

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

مقدمه

پیش از این راجع به Bad Smell و کاربرد آن در مهندسی نرم افزار صحبت کردیم "دستور سوییچ" یکی از 22 نوع Bad Smell میباشد.

نحوه تشخیص و معرفی راه حل دستور سوییچ
بیشتر مواقع که یک دستور switch می بینید باید به حساب چند ریختی یا Poly-Morphism بگزارید این مشکل وقتی که باید چند ریختی رخ دهد به وجود می آید. معمولا switch برای یک کد نوع استفاده می شود شما یک متد میخواهید که کد نوع را برگرداند. میتوانید از استخراج متد برای استخراج switch استفاده کنید و با انتقال متد تابع را به کلاس ای که پولی مورفیسم در آن نیاز است منتقل کنید. در آن زمان نیاز به انتخاب بین روش جایگزینی نوع کد با کلاس زیر[1] یا از روش جایگزینی نوع کد با حالت[2] دارید. وقتی که ساختار وراثت را مشخص کردید میتوانید از جایگزینی عبارت شرطی با پولی مورفیسم[3] استفاده کنید.

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

[1] Replace Type Code with Subclass
[2] Replace Type Code with State/Strategy
[3] Replace Conditional with Polymorphism

مقدمه

پیش از این راجع به Bad Smell و کاربرد آن در مهندسی نرم افزار صحبت کردیم "وسواس اولیه" یکی از 22 نوع Bad Smell میباشد.

نحوه تشخیص و معرفی راه حل وسواس اولیه
اکثر زبان های برنامه نویسی دارای انواع رکورد و اولیه هستند انواع اولیه ( مانند int و byte و char و ...( در ساخت بلوک ها بکار میروند و با انواع رکورد میتوان اطلاعات را در گروه های معنا دار ساختار بندی کرد. یک چیز ارزشمند در مورد اشیا این است که آنها مرز بین انواع اولیه و کلاس های بزرگ تر را محو کردند.

افرادی که به تازگی با اشیا آشنا شده اند از استفاده از اشیا کوچک برای کارهای کوچک اجتناب میکنند مثلا کلاسی پول که عدد و نوع پول را ترکیب میکند یا کلاس بازه که از دو عدد شروع و پایان تشکیل شده است شما میتوانید انواع مستقل را با روش جایگزینی مقدار داده با شی[1] به یک شی تبدیل کنید اگر مقدار داده یک از نوع کد بود از روش جایگزینی نوع کد با کلاس[2] استفاده کنید اگر مقدار در رفتار تاثیر گذار نیست به خودتان بستگی دارد که از روش جایگزینی نوع کد با کلاس زیر[3] یا از روش جایگزینی نوع کد با حالت[4] استفاده کنید.

[1] Replace Data Value with Object
[2] Replace Type Code with Class
[3] Replace Type Code with Subclass
[4] Replace Type Code with State/Strategy

مقدمه

پیش از این راجع به Bad Smell و کاربرد آن در مهندسی نرم افزار صحبت کردیم "توده داده" یکی از 22 نوع Bad Smell میباشد.

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

مقدمه

پیش از این راجع به Bad Smell و کاربرد آن در مهندسی نرم افزار صحبت کردیم "خصیصه حسادت" یکی از 22 نوع Bad Smell میباشد.


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

مقدمه

پیش از این راجع به Bad Smell و کاربرد آن در مهندسی نرم افزار صحبت کردیم "تشریح انفجاری" یکی از 22 نوع Bad Smell میباشد.

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

مقدمه

پیش از این راجع به Bad Smell و کاربرد آن در مهندسی نرم افزار صحبت کردیم "تغییرات واگرا" یکی از 22 نوع Bad Smell میباشد.

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

مقدمه

پیش از این راجع به Bad Smell صحبت کردیم "لیست پارامتر طولانی" یکی از 22 نوع Bad Smell میباشد.

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

مقدمه

پیش از این راجع به Bad Smell صحبت کردیم "کلاس بزرگ" یکی از 22 نوع Bad Smell میباشد.

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

شما میتوانید از روش استخراج کلاس[1] برای کم کردن تعداد متغیر استفاده کنید. متغیر ها را طوری انتخاب کنید که در کنار هم معنا دار باشند. برای مثال depositAmount و depositCurrency احتمالا باید در یک کلاس باشند. در حالت کلی پیشوند یا میانوند اسم متغیر ها در یک کلاس نشانه یک فرصت برای ساخت کلاس جدید است. اگر این متغیر ها در کنار هم به شکل یک زیرکلاس معنا دار تر میشوند میتوانید از روش استخراج زیرکلاس[2] نیز استفاده کنید.

ادامه مطلب

مقدمه
پیش از این راجع به Bad Smell صحبت کردیم "تابع طولانی" یکی از 22 نوع Bad Smell میباشد.

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