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

کنترل تغییر مقدار ویژگی[توسعه نرم‏افزار , ]

در هنگام تعریف متغییرهای داخلی برای ذخیره کردن مقدار ویژگیها(Property) معمولاً دچار یک مشکل هستیم و آن این است که هدف ما از تعیین ویژگی(Property) کنترل کردن تعیین مقدار یک ویژگی است، پس باید این قید را ایجاد کنیم که فقط از طریق setter آن ویژگی مقدار برایش قرار داده شود.


// variable to store value of property Name
private string name;
public string Name
{
  get
  {
     return name;
  }
  set
  {
     if ( name != value )
       OnNameChanged(this,EventArgs.Empty);
     name = value;
  }
}

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

نکته خیلی مهم اینست که مقدار متغییر میتواند توسط خود کلاس تغییر کند(پائینتر از private در سطوح دسترسی نداریم)، در اینصورت event صدا زده نخواهد شد...

به نظرتون چطور میتوان جلوی تغییر مقدار یک ویژگی از راههای ناخواسته را گرفت؟ و طوری کد نوشت که مطمئنا مقدار ویژگی توسط قسمت set ان تغییر کند؟

تاریخ فرستادن:دوشنبه 30 آبان 1384، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

منطق فازی در جهان اسلام[عمومی , ]

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

ششمین کنفرانس سیستمهای فازی در ایران

و اولین کنفرانس سیستمهای فازی در جهان اسلام

که حدوداً اردیبهشت سال دیگر برگزار خواهد شد.

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

توضیح اینکه منطق فازی توسط یک پروفسور مشکوک به ایرانی بودن به نام "لطفی زاده
مطرح شد و ابتدا توسط ژاپنی مورد استفاده گسترده قرار گرفت(قطارهای تندرو مغنتاطیسی) و امروزه در تمام جهان مورد توجه قرار گرفته است.

تاریخ فرستادن:چهارشنبه 25 آبان 1384، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

عاقبت اندیشی[عمومی , ]

یه حدیث از حضرت علی هستش که میگه :

عاقلترین آدمها کسی است که به عاقبت امور می اندیشد.

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

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

شیطان سعی میکنه که آدمها، یا عبادتشون بدون تفکر باشد و یا تفکرشون بدون عبودیت.

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

بعضیها تنبلی رو به راحتی ترجیح میدهند.

و واقعاً خیلی جالبه که آدمهایی چنین وجود دارد و البته باز هم خیلی زیاد هستند.

 

در ضمن قالب جدید وبلاگ کار خودمه و کلی (۳ ساعت) وقت روش گذاشتم و چون بلد نبودم کیفیت عکس خراب شد، به هرحال من خودم خیلی از طرحم خوشم اومده، نظر شما چیه؟

تاریخ فرستادن:چهارشنبه 18 آبان 1384، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

روش Design By Code (قسمت دو)[توسعه نرم‏افزار , ]

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

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

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

  • هر متود باید فقط یک کار انجام دهد و نه بیشتر.
  • هر کار باید فقط توسط یک متود صورت گیرد.
  • نام هر متود(پیام) باید دقیقاً منطبق با رفتاری باشد که توسط آن متود سر میزند.
  • هر متود باید فقط یک کار انجام دهد و نه بیشتر. البته متودهایی را میتوان متصور شده که هیچ کاری انجام نمیدهند و راجع به آنها بحثی ندارم، اما در مورد متودهایی که بیش از یک کار انجام میدهند و جلب توجه شما به این نکته که "جز معیارهای طراحی بد نرم افزار سخت بودن تغییر دادن سیستم است و علاوه بر آن در طراحی با کد حجم تغییرات زیاد است"، میتوان ایراد متودهایی که بیش از یک رفتار را ارائه میکنند را عنوان کرد و آن اینست که مسلماً به زودی برای یک تغییر خاص به یکی از رفتارها به طور جداگانه احتیاج پیدا خواهید کرد و مجبور میشوید که متود پُرکار را در قالب دو و یا چند متود تقسیم کنید.

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

    هر کار باید فقط توسط یک متود صورت گیرد. اگر دو متود داشته باشید که دقیقاً یک کار انجام میدهند را انجام میدهند و یا اینکه هنوز پایبند اصل قبلی(هر متود فقط یک کار انجام دهد) نیستید دو تکه کد که یک کار را انجام میدهند مثالهایی از نقض این اصل است. در مورد داشتن دو متود که دقیقاً یک کار را انجام میدهند باید از تعریف چنین متودهایی اجتناب کرد و دوم اینکه در صورت داشتن چنین متودهایی باید همه را حذف کنید و فقط یکی را نگه دارید.

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

  • تعداد خطوط کد هر متود به حدی باشد که تمام خطوط کد در یک صفحه نمایش بدون اسکرول کردن خواندنی باشند.
  • اگر دو تکه کد دارید که یک رفتار انجام میدهند باید آنها را جدا کرده و به صورت یک متود در آورید و در جای هر کدام یک فراخوانی به متود جدید را جایگزین کنید(به اصطلاح refactor کنید.)

    برای پرهیز از داشتن تکه کدهایی که در متودهای مختلف تکرار شده اند و بطور کلی متودهای تکراری و کدهای تکراری نداشته باشید باید یک عادت بد را ترک کنید و آن Copy-Paste کردن کد است و به جای آن به refacoring روی بیاورید و حتی برای ساده شدن کار از ابزارهای refactoring استفاده کنید(در Visual Studio .Net 2005 امکانات refactoring اضافه شده است.) ؛ بطور خلاصه

  • هرگز کد را Copy-Paste نکنید.
  • در عوض از Cut-Paste و تعریف یک متود جدید و فراخوانی متود در محل کد حذف شده استفاده کنید.
  • یک نکته مهم: ملاک تشخیص دادن اینکه دو تکه کد یکی هستند، رفتاری است که توسط آن کد ارائه میشود و همچنین هدفی است که صدا زننده متود از متود و یا کد توقع دارد(نقش متود و یا کد). در نظر بگیرید دو متود دقیقاً یکی هستند(کاراکتر به کاراکتر مشابه هستند) اما اگر هدف صدا زننده آنها متفاوت باشد این دو یکی نیستند و نباید یکی را حذف کنید چون ممکن است برمبنای هدفی که هر کدام دارند لازم شود کد یکی را تغییر دهید، بطور خلاصه

  • هر متود(ویا تکه کد) شامل یک رفتار و یک نقش است. پس متود تکراری متودی است که رفتار مشابه و نقش مشابه داشته باشد.
  • تاریخ فرستادن:دوشنبه 2 آبان 1384، نویسنده: فرشید کزازی (همیشه همینه)
    تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

     

    درباره فرشیدکزازی

     
     

    هیچ چیز قابل گفتنی درباره خودم وجود نداره.
    کاری داشتید به farshidkazazi@gmail.com پیام بفرستید.

     

     

    درباره آکنده

     
     

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

    ** اسم وبنوشت هیچ معنای خاصی ندارد، اولین کلمه ای بود که موقع ثبت نام به ذهنم رسید.

    دسته بندی نگاره ها:
    عمومی (7)
    توسعه نرم‏افزار (13)

     

     

    وبنوشتهای دیگر

     
      زیر چتر باران
    واژگان مدیریت دانش
     

     

    ابزارها

     
     
    جستجو در بلاگ


    برای دریافت نگاره ها از طریق email با وارد کردن آدرس email نام‏ نویسی کنید:
    بایگانی گذشته
    مرداد 1385 (2)
    تیر 1385 (3)
    اردیبهشت 1385 (1)
    بهمن 1384 (4)
    آذر 1384 (1)
    آبان 1384 (4)
    مهر 1384 (5)