حسام حداد

در مورد برنامه نویسی ، الگوریتم نویسی ، نکات ترفند ها

حسام حداد

در مورد برنامه نویسی ، الگوریتم نویسی ، نکات ترفند ها

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

آخرین نظرات
  • ۱۸ آبان ۹۵، ۱۲:۵۱ - سامان
    ای ول

۶ مطلب در بهمن ۱۳۹۴ ثبت شده است

مقدمه
یکی از الگوریتم های ساده که معمولا در درس ساختمان گسسته، طراحی الگوریتم و ساختمان داده به صورت پایه مطرح می شود الگوریتم فلوید وارشال می باشد. این الگوریتم با مرتبه O(N3) شاید یکی از بدترین انتخاب ها برای حل مسئله به علت کندی بیش از حد باشد. اما وقتی تعداد نود به اندازه کوچکتر از 200 باشد تفاوت قابل توجه ای با الگوریتم های خوب جایگزین ندارد و به علت پیاده سازی ساده و سریع این الگوریتم همیشه اگر در محدودیت های مساله قابل استفاده باشد جایگزین بقیه کاندید ها می شود.
رابرت فلوید و استفان وارشال همزمان باهم در مقالات مختلف در سال 1962 این الگوریتم را منتشر کردند، و به افتخارشان الگوریتم فلوید-وارشال نام گرفت که به اختصار به آن فلوید نیز گفته می شود، رابرت فلوید دارای یک الگوریتم خوب دیگر برای پیدا کردن دور در لیست پیوندی یا روابط بازگشتی بر اساس مقدار قبلی می باشد که باز با اسم الگوریتم فلوید مشهور است اما به اندازه این الگوریتم اعمال تعدی معروف نیست.
دلیل من برای انتخاب این الگوریتم برای بخش درسنامه الگوریتم ها، روزمره و ساده بودن الگوریتم فلوید بود که با توجه به بازدید های وبلاگ بنظر می رسد دانشجو های زیادی در طول ترم نیاز به مطالعه و استفاده از این الگوریتم دارند.

  • حسام حداد

مقدمه

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

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

توضیحات مارا به کد بدی منتهی میکند که میتواند تمامی بو های بد قبلی را داشته باشد در اولین حرکت ما بایست بوی بد را با refactor از بین ببریم سپس وقتی اینکار تمام شد معمولا به نقطه ای میرسیم که توضیحات بی فایده میشوند.

اگر شما نیاز دارید یک توضیح برای تشریح هدف یک تکه کد بنویسید. روش استخراج متد را استفاده کند اگر متد وجود دارد اما باز نیاز به توضیح دارد روش نامگذاری دوباره متد[1] را امتحان کنید. اگر نیاز دارید قوانینی برای سیستم تعریف کنید از معرفی تاکید[2] استفاده کنید.

[1] Rename Method
[2] Introduce Assertion

  • حسام حداد

مقدمه

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

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

تفکر سنتی میگوید  که این به معنی اشتباه بودن سلسله مراتب است شما باید یک کلاس مجاور دیگر درست کنید و با روش های پایین آوردن متد[1] و پایین آوردن فیلد[2] تمامی متد های استفاده نشده را به کلاس مجاور منتقل کنید  و به این طریق کلاس پدر تنها بخش مشترک را نگه میدارد معمولا این طور می شنوید که superclass ها باید abstract باشند.

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

بوی میراث بدرد نخور وقتی شدید میشود که کلاس زیر در حال استفاده از برخی قابلیت هاست اما نمیخواهد interface کلاس پدر را پشتیبانی کند. ما راجع به رد پیاده سازی بی تفاوت بودیم اما در مورد رد interface قضیه جدی تر میشود. در این حال به سلسله مراتب نچسبید و با روش جایگزینی همراهی با وراثت[3] مشکل را برطرف کنید.

[1] Push Down Method
[2] Push Down Field
[3] Replace Inheritance with Delegation

  • حسام حداد

مقدمه

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

نحوه تشخیص و معرفی راه حل کلاس داده
این کلاس ها متغیر دارند متد های get و set برای آن فیلد ها دارند و هیچ چیز دیگری ندارند. این کلاس ها نگه دارنده های احمق اطلاعات هستند و معمولا زیادی توسط کلاس های دیگر دستکاری می شوند. اوایل ممکن است این کلاس ها فیلد های public داشته باشند اگر چنین است شما باید سریعا روش کپسول سازی فیلد[1] را به کار ببرید، اگر فیلد های مجموعه ( مثل آرایه ، لیست پیوندی و ...) دارید مطمئن شوید که روش کپسوله سازی مجموعه را به کار بردید. روش حذف متد های تنظیم[2] را برای هر فیلدی که نیاز نیست تغییر کند اعمال کنید.

[1] Encapsulate Field
[2] Remove Setting Method

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

کلاس های جایگزین با interface متفاوت

روش تغییر نام متد را بر روی هر تعداد متد ی که کار یکسان را با امضای متد مختلف انجام میدهند اعمال کنید. معمولا این کافی نیست و در بعضی حالات کلاس ها به اندازه کافی کار انجام نمیدهد از روش انتقال متد به قدری استفاده کنید که پروتکل ها یکسان شود. ممکن است نیاز شود به شکل اضافه کد ها را انتقال دهید تا به این هدف برسید و بعد شما میتوانید از روش استخراج کلاس پدر[1] استفاده کنید.

کلاس کتابخانه ناتمام Incomplete Library Class

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

اما ابزار هایی نیز داریم که در این موقعیت مطرح میشوند، اگر یک تعداد تابع است که آرزو می کنید کلاس کتابخانه ای شما آنها را داشت میتوانید از معرفی متد خارجی[2] استفاده کنید اگر به قابلیت های خیلی بیشتر نیاز دارید روش معرفی کنش محلی[3] را به کار ببندید.

[1] Extract Superclass
[2] Introduce Foreign Method
[3] Introduce Local Extension

  • حسام حداد

مقدمه

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

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

  • حسام حداد