حسام حداد تکنولوژی، برنامه‌نویسی، هوش مصنوعی

مقدمه

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

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

مقدمه

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

نحوه تشخیص و معرفی راه حل کلاس تنبل
هر کلاسی که میسازید هزینه ای برای استفاده و درک دارد یک کلاس که به اندازه لازم کاری انجام نمیدهد که این هزینه را بپردازید میبایست حذف شود ممکن است این کلاس با refactoring ایجاد شده باشد یا برای تغییرات برنامه ریزی شده ایجاد شده باشد که صورت نگرفته است در هر صورت شما باید این کلاس را از بین ببرید اگر زیرکلاس هایی دارید که به اندازه مفید نیستند از روش فروپاشی سلسله[1] استفاده کنید. برای کلاس هایی که فایده اندک دارند از روش کلاس های درخط استفاده کنید.
[1] Collapse Hierarchy

مقدمه

پیش از این راجع به 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 میباشد.

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