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

[توسعه نرم‏افزار , ]

چند تا نکته کوچک در مورد performance :

قبل از cast کردن از is استفاده نکنید.

احتمالاً گاهی اوقات برای cast یک شی به یک نوع دیگر از is استفاده کرده باشید و بعد از اینکه مطمئن شدید که قابل cast است شی را cast کرده باشید.

مثال فرض کنید یک شی به نام myObject دارید و میخواهید در صورتی که از نوع AClass باشد با آن کار کنید، معمولاً چنین مینویسیم:

if ( myObject is AClass)

{

    AClass aObject = (AClass)myObject;

    // using aObject

}

اما روشی که توصیه میشود اینگونه است:

AClass aObject = myObject as AClass;

if ( aObject != null )

{

   // using aObject

}

مزیت روش دوم در اینست که فقط یکبار شی cast میشود، اما در اولی عملگر is نیز به طور ضمنی(ناآشکار) عمل cast را انجام میدهد، یعنی در تکه کد اولی دوبار عمل cast صورت میگیرد.

البته همانطور که میدانید عمل cast در performance تاثیر منفی میگذارد، پس بطور کلی باید از اضافه cast کردن یک شی صرف نظر کرد. برای مثال بعضیها به جای تعریف یک متغییر جدید برای نسخه cast شده شی، هر بار که نیاز به شی دارند آن را مجدداً cast میکنند:

غلط:

((RequiredType)object).Method1();

((RequiredType)object).Method2();

((RequiredType)object).Method3();

درست:

RequiredType objectAsRequiredType = objectAsRequiredType;

objectAsRequiredType.Method1();

objectAsRequiredType.Method2();

objectAsRequiredType.Method3();

در تکه کد غلط شی چندین بار cast شده است، اما در تکه کد درست، فقط یکبار cast شده است.

همچنین یک اشتباه متداول دیگر:

غلط:

for(int i=0;i<sourceDataList.Count;i++)

{

    ((RequiredType)object).DoJob(sourceDataList[i]);

}

درست:

RequiredType objectAsRequiredType = objectAsRequiredType;

for(int i=0;i<sourceDataList.Count;i++)

{

    objectAsRequiredType.DoJob(sourceDataList[i]);

}

در تکه کد غلط در هر بار اجرای حلقه شی شما cast میشود ولی در تکه کد درست cast کردن شی قبل از ورود به حلقه انجام میشود.

در مورد عملگر as نیز گفتنی است که برای cast کردن بکار میرود منتها با عملگر () این فرق را میکند که در صورتی که شی شما قابل cast نباشد مقدار null را برمیگرداند، اما عملگر () در صورتی که شی شما قابل cast نباشد و بخواهید با آن شی را cast کنید exception در میکند. همچنین as در صورتی که متغییر شما حاوی شی ای نباشد(مقدارش null باشد) باز هم خروجی null است.

 

برای ساختن متن از + استفاده نکنید، StringBuilder اکیداً توصیه میشود.

اگر دو متن را با + به هم متصل کنید در مقایسه با اینکه از StringBuilder استفاده کنید و همچنین عملیات با متن در برنامه شما متدوال باشد، به شدت سرعت برنامه پائین خواهد آمد. برای مثال اگر یک عملیات ساخت متن با StringBuilder به طور مثال 4 ثانیه طول بکشد معادل آن با استفاده از + و String.Concat چندین روز طول خواهد کشید.

 

در مورد اشیا IDisposable حتماً از using استفاده کنید. یک نکته مهم که در مورد using وجود دارد اینست که using یک بلاک try/catch به کد اضافه میکند و حتی در صورتی که در بلاک using شما یک exception رخ دهد، باز هم شی شما Dispose خواهد شد. اما اگر اصرار دارید که متود Dispose را خودتان مستقیم صدا کنید حتماً صدا زدن متود Dispose را در قسمت finally یک بلاک try/catch/finally قرار دهید تا حتماً صدا زده شود.

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

[عمومی , ]

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

شی گرایی :‌ رفتارها[توسعه نرم‏افزار , ]

در ادامه بحث شی گرایی، و اینکه نوشتم هر شی دارای ساختار است خب گفته بعدی این است که هر شی یک سری رفتار(behavior) را در طی زمان انجام میدهد.

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

اگر بخواهم با مفاهیم برنامه نویسی کامپیوتر تناظر برقرار کنم منظورم از رفتار همان متودهای کلاس است.

انواع روشهای اجرای یک رفتار: همزمان، غیر همزمان

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

در روش غیرهمزمان شی فرستنده پیام منتظر میماند تا شی گیرنده پیام رفتار درخور را انجام دهد. روش غیرهمزمان ساده تر است و جزئیات و پیچدگیهای کمتری دارد.

اینکه یک رفتار همزمان اجرا شود یا ناهمزمان به دو صورت میتواند مشخص شود، درهنگام تعریف رفتار نوع اجرای آن مشخص شود، در هنگام صدا زدن رفتار نوع اجرا مشخص شود. در حال حاضر صرفاً میتوان در هنگام صدا زدن رفتار نوع اجرا را مشخص کرد اما در آینده در C#3.0 این امکان اضافه شده است که در هنگام تعریف متود(رفتار) نوع اجرای آن را همزمان معین کرد.

دو نکته مهمی که در طراحی رفتارها وجود دارد اینست که

یک : تا انجایی که امکان دارد از ساختن رفتارهایی که در محیط اطراف(اشیا دیگر) تغییر ایجاد میکنند پرهیز کنید در غیر اینصورت یک اصل نرمال سازی کلاس(class normalization) به نام کم جفت شدگی (low coupling) را زیر پا خواهید گذاشت.

دو : از ساختن رفتارهایی که هم در ساختار داخلی خود و هم در اشیا دیگر تغییر ایجاد میکنند پرهیز کنید.

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

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

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

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

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

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

یعنی برای ویژگی که در دو پست پیشتر نوشتم، از متغیری به نام propertyValue_Name استفاده میکنم و این نام به قدر کافی تابلو است و اشتباهاً آن را در کدهایم دستکاری نخواهم کرد:

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

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

 

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

 
 

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

 

 

درباره آکنده

 
 

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

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

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

 

 

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

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

 

ابزارها

 
 
جستجو در بلاگ


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