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

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

reusability  در كوتاهترین شكل قابل فهم "قابل استفاده مجدد بودن" معنی میدهد. این فارسی عجب زبان توپی است وقتی میخواهید یك مفهوم را به كار ببرید به جای اینكه نام آن مفهوم را ذكر كنید، شرحش را بیان میكند.(مثلاً تو انگلیسی برای مفهومی كه در ادامه میخواهم توضیح بدهم چنین آن را شرح میدهد : "be able to be used again" و اگر بخواهند از نام آن مفهوم استفاده كنند همان resusability را بكار میبرند.)
البته اگر دوست دارید از یك واژه ای مانند "بازكاربردی بودنی" استفاده كنید تا موجب انبساط خاطر همكارانتان شوید.
قابل استفاده مجدد بودن به این موضوع اشاره میكند كه فرایند انجام كاری را تدوین میكنیم و یا محصولی را  ایجاد میكنیم، طوری تدوین كنیم و یا تولید كنیم كه اگر دوباره در آینده احتیاج داشتیم همان كار را انجام دهیم و یا همان محصول را داشته باشیم، از همان تدوین فرایند قبلی و یا از همان محصول قبلی استفاده كنیم.
قابل استفاده مجدد بودن یك مفهوم مهندسی است كه مختص مهندسی نرم افزار نیست یعنی یك مهندس كسی است كه در انجام كارهایشان قابل استفاده مجدد بودن را در نظر میگیرد. البته توجه داشته باشید كه استفاده مجدد از یك محصول تقریباً مختصص مهندسی نرم افزار است و در سایر رشته ها من نمونه ای سراغ ندارم.

برای مثال یك شركت خودروسازی برای تولید هر خودرو از روشی مشابه برای خودروهای قبلی استفاده میكند، یعنی یكبار روش تولید خودرو(در این مثال تولید خودرو فرایند ما است.) را تدوین و مشخص میكند و سپس برای تولید بقیه خودروها از همین روش استفاده میكند.

در نرم افزار به دلیل ماهیتش، محصول تولید شده نیز میتواند قابل استفاده مجدد باشد. به محصولات تولید شده قابل استفاده مجدد asset(من دارائی نامجسم ترجمه میكنم) میگویند. با این حساب این یك وظیفه مهندس نرم افزار میشود كه طوری طراحی كند كه محصول تولید شده قابل استفاده مجدد باشد. و بدین ترتیب مفهموم component ها شكل میگیرند، component اجزا یك نرم افزار هستند كه یك ویژگی مهم آنها قابل استفاده مجدد بودن است.
مفهوم قابلیت استفاده مجدد دربرنامه نویسی، در قدم اول منجر به پیدایش برنامه نویسی procedural شد، همانطور كه میدانید در این روش به جای اینكه كدی كه یك رفتار را ارائه میكند هر بار كه به آن رفتار احتیاج پیدا شد از اول نوشته شود، یك بار نوشته میشود و هر بار كه رفتار مورد نیاز بود آن تكه كد فراخوانی میشود، به این تكه كد method یا procedure میگویند.
مفهوم قابلیت استفاده مجدد دربرنامه نویسی، در قدم اول دوم درمفاهیم شیگرائی ارائه شد. اگر خواستید بعداً بیشتر توضیح میدهم.
و سوم اثر از مفهوم قابلیت مجدد در بحث نسبتاً جدیدتر AOP است. اگر خواستید بعداً بیشتر توضیح میدهم.

.نكته آخر: اینكه یك سازمان علاوه بر فرایند ها و محصولات دارای عنصر سومی است به نام دانش كه دانش همواره قابل استفاده مجدد است و بحث زیادی درباره آن ندارم.

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

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

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

تو محل كارم هم روشهایی برای دور زدن طراحی كردن ها دارم، یه بار به عنوان طراحی component ای كه باید مینوشتم كه در واقع سرویسهای جهانی سازی(globalization) بود به عنوان طراحی مستند راهنمای برنامه نویسان آن component را آنطور كه در ذهنم در نظر داشتم، نوشتم و به مدیرم ارائه دادم و قرار شد كه همان را پیاده سازی كنم. برای نوشتن مستند راهنما ساختار بعضی از كلاسها را نیز نوشتم ولی متودهایش را پیاده سازی نكردم تا بتوانم تصوری از اینترفیس آن component و همچنین نحوه عملكرد آن و تعامل اشیا آن با یكدیگر بدست آورم.

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

در هر iteration ساده ترین رفتار ممكن را پیاده سازی كنید.

اصول low coupling و high cohesion و دیگر اصول class normalization را به شدت مورد توجه قرار دهید. چون همانطور كه در نرمالسازی رابطه ها در پایگاه داده بارها تجربه كرده ایم، عدم تبعیت از این نوع اصول مشكلات اساسی و وحشتناكی را به بار می آورند.

هرگز كاری را به آینده موكول نكنید، كل یك تكه از كد - كلاس، كامپوننت،متود،... - را به طور كامل یكجا و در یك مقطع زمانی بنویسید.

كد را مستند كنید، اگر در مورد عملكرد كدی كه خودتان نوشته اید به راحتی مستندات همراه را اضافه كنید، احتمالاً منطق مورد استفاده در كدتان غلط است و به همین دلیل نمیتوانید در مورد آن توضیح بنویسید.

من حدود 8 -9 ماه است كه بر روی یك ORM (ابزار نگاشت شیگرایی-رابطه ای) كار میكنم، در تمام مدت پیاده سازی iteration اول كارم كه به 15 هزار خط كد رسید و مدت 4 ماه طول كشید، حتی یكبار هم آن را تست نكردم و این ORM شامل مولفه های گوناگون بودند كه باید با هم كار میكردند، بعضی از آنها مربوط به پایگاه داده بودند و بعضی مربوط به ریموتینگ و دسته ای نیز مربوط به سرویسهای رابط كاربر و همچنین مولد كد(به خاطر type-safety مجبور شدم مولد كد داشته باشم.). بعد از حدود 4 ماه تصمیم گرفتم برای تست آن یك برنامه حسابداری شخصی مختصر با تقلید از Microsoft Money به طور آزمایشی بنویسم تا هم اجرای چارچوپ ORM را تست كنم و هم كارائی آن را در افزایش سرعت تولید بررسی كنم. این كار فقط حدود 2 هفته طول كشید كه البته حدود نصف آن مربوط به افزودن چیزهایی بود كه تاكنون به آنها توجه نداشتم. نمیتونید تصور كنید كه چه حسی داشتم، از اینكه بعد این مدت طولانی تونستم كدهایم را در حال اجرا میدیم فوق العاده لذت میبردم و برای خودم ذوق میكردم، از اینكه تمام مشكلاتش را تنها در مدت 1 هفته حل كردم فوق العاده خوشحال بودم، حتی یك شب تا صبح از فرط خوشحالی خوابم نبرد.

راستی هیچ دقت كردید با وجود اینكه اسم وبلاگم را random انتخاب كردم ولی به غرورم میخورد.)

الان دارم یك مستند در مورد CAB میخونم، خیلی دوست دارم كه در مورد پیچیدگی(complexity) و سادگی(simplicty) و ساده ارائه كردن(simplexity) دیدگاهم را ارسال كنم.

به امید خدا تا فردا...

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

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

چند تا نکته کوچک در مورد 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، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

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

در ادامه بحث شی گرایی، و اینکه نوشتم هر شی دارای ساختار است خب گفته بعدی این است که هر شی یک سری رفتار(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، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

ویژوال استودیو دات نت ۲۰۰۵[توسعه نرم‏افزار , ]

خب چند پیش ویژوال استودیو دات نت ۲۰۰۵ رو رو سیستمم نصب کردم و اول از همه از برنامه نصبش معلومم شد که اوضاع چطور است، افتضاح. حیف اون همه پولی که دادم و خریدمش.

اولین چیزی که جالب بود این بود که پیغام های فارسی نمایش میداد(ارسال گزارش خطا را با زبان فارسی و چیدمان فارسی نشان داد.) فکر میکنم مربوط به دات نت فریم ورک ۲ باشد.

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

زبان C# خیلی فرق نکرده است و در آینده شاید یک گزارش درست و حسابی در مورد تغییرات آن بدهم، اما از بعضی تغییرات خوشم نیومد، بیشتر منظورم تغییراتی که در modifier های مربوط به accessor های property ها اعمال کرده است.

علاوه بر C# خود ویژوال استودیو هم افتضاح است، مثلاً برای ثبت AddIn ها یک مکانیزم Xml Registration اضافه کرده که به نظر من خیلی چرت اومد.

مشکل اساسی که دارد اینست که به شدت حافظه میخورد(به خصوص Form Designer اش) و اگر حافظه سیستم کم باشد هنگ میکند.

در یک کلام خدا مایکروسافت رو لعنت کند، از رو نقشه دره سیلیکون محو کند، ....

درضمن من چون به اینترنت دسترسی ندارم، حالا حالا ها ممکنه پست نفرستم.

در ضمن دوم اینکه چون مطالب فنی مخاطب ندارد(برخلاف تصور اولیه من) و اینکه نوشتن آنها یه خورده زمان میبرد دیگر مطلب فنی نمی نویسم.

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

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

در هنگام تعریف متغییرهای داخلی برای ذخیره کردن مقدار ویژگیها(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، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

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

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

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

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

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

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

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

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

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

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

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

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

    شی و ساختار و دسته[توسعه نرم‏افزار , ]

    من فکر میکنم لازم نیست شی را تعریف کنیم، یعنی بدین صورت تعریف کنیم:

    شی شی است.

    در عوض مشخص میکنیم چگونه شی را مشخص میکنیم، بکار میبریم.

    برای اشیا ساختار تعریف میکنیم.

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

    سه نکته را در نظر داشته باشید:

    ۱. گروهی از اشیا میتوانند دارای ساختار مشابه باشند.

    ۲. هر چه بیشتر از ویژگیهای اشیا صرف نظر صرف نظر کنیم، اشیا در دسته های عامتری قراری میگیرند و هر چه بیشتر بر روی ویژگیها تاکید کنیم دسته ها خاصتر میشود.

    ۳. تعریف ساختار به ازای هر شی حجم کاری(در تحلیل و طراحی و پیاده سازی) را زیاد میکند.

    ۴. احتیاجی به همه قسمتهای ساختار یک شی نداریم. این بستگی دارد که به شی از چه زاویه ای نگاه میکنیم و شی را برای چه کاربردی میخواهیم.

    نکات ۳ و ۴ دو دلیل برای دسته بندی اشیا است، پس

    دسته های اشیا را مشخص میکنیم و به جای ساختار هر شی ساختار دسته را مشخص میکنیم

    علت استفاده از کلمه class(دسته) در زبانهای برنامه نویسی نیز به همین خاطر است.

    سلسله مراتب اشیا(Class Hierarchy):

    بر اساس نکته ۱ و ۲ در هنگام تعریف دسته ها، برای دسته ها سلسله مراتب در نظر میگیریم، یعنی دسته هایی تعریف میکنیم که در قالب یک دسته عام تر قرار میگیرند و برعکس میتوان گفت دسته هایی تعریف میکنیم که خود به چندین دسته خاصتر تقسیم میشوند.

    سلسله مراتب اشیا را مشخص میکنیم

    در یک سلسله مراتب دسته های خاصتر دارای جزئیات بیشتر نسبت به دسته های عامتر هستند.

    دسته های مبنا(Base Classes):

    به دسته ای که دسته های دیگر بر مبنای آن قرار دارند(یعنی دسته های دیگر با افزودن جزئیات به آن ساخته شده اند) دسته مبنا گفته میشود.

    منبعد به دسته های عامتر دسته پایه میگوئیم.

    دسته های مشتق شده(Derived Classes):

    به دسته ای که با افزودن بعضی جزئیات به دسته ای مبنا ساخته شده است، دسته مشتق شده گفته میشود.

    منبعد به دسته های خاصتر دسته مشتق شده میگوئیم.

    هر دسته مشتق شده فقط از یک دسته میتواند مشتق شود.(البته این یک دیدگاه است و بعضی از زبانهای برنامه نویسی امکان مشتق کردن از بیش از یک دسته پایه را فراهم میکنند به این اشتباه مهلک ارث بری چندگانه(Multiple Inheritance) میگویند.)

    ارث بری(Inheritance):

    ساختار دسته های مشتق شده دارای جزئیات ساختار پایه نیز هستند به این وضعیت ارث بری میگویند و  میگویند که دسته مشتق شده ساختار دسته پایه را به ارث میبرند.

    دسته های عینی(Concrete Classes):

    به دسته هایی که اجزا آن به حدی مشخص هستند که میتوان شی مشخصی را از آن دسته متصور شد دسته های عینی(concreate classes) گفته میشود 

    دسته های مجرد(Abstract Classes):

    یه دسته هایی که نمتوان از آنها شی ای متصور شد دسته های مجرد(Abstract Classes) گفته میشود.

    دسته تمام اشیا

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

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

     

     

    تا اینجا خیلی به جزئیات ساختار دسته ها اشاره کردیم، در ادامه در مورد جزئیات ساختار دسته ها بحث را ادامه میدهیم، موافقید؟؟

     

    منتظر نظرات، دیدگاههای شما هستم و همچنین در مورد مطالب مطرح شده پاسخگوی سوالات.

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

    چند تعریف پایه شیگرایی[توسعه نرم‏افزار , ]

    شیگرایی(Object Oriention)

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

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

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

    شی (موجود) (Object) :

    هر چیزی را که بتوانید در نظر بگیرید، یک شی است. البته منظور صرفاً اشیا فیزیکی نیست مثل یک ایده، یا یک مفهوم.

    هر شی دو بعد مهم دارد :

    1. وجود : هر شیی وجود دارد.

    یک شی در یک مقطع از زمان بوجود می آید(توسط اشیا دیگر) و مدتی وجود دارد و در یک مقطع زمانی (توسط خودش و یا اشیا دیگر) نابود میشود.

    2. ساختار(structure) : مجموعه ای از ویژگیها و خصائص که موجب تمایز بین یک شی با اشیا دیگر میشود.

    ساختار (Structure):

    ساختار برای یک شی حکم یک قالب را دارد و حتی در زبانهای شیگرا برای ایجاد اشیا باید از طریق ساختارش اقدام کرد(مثل استفاده از قالب در ریخته گری)

    نکته خیلی مهم در مورد تعریف ساختار اینست که ساختار مشخص میکند که شی چه ویژگیهایی دارد، اما مشخص نمیکند که مقدارهر ویژگی چیست.

    هر شی یک ساختار درونی و یک ساختار بیرونی دارند. از دید اشیا دیگر ساختار بیرونی هر شی مهم است و ساختار درونی هر شی فقط برای خود شی اهمیت دارد.

    رویه (Interface):

    به ساختار بیرونی یک شی رویه(interface) گفته میشود. به ساختار دورنی پیاده سازی رویه شی گفته میشود.

    دسته (Class):

    در طراحی شیگرا اشیایی که دارای ساختار مشابه(با صرفنظر کردن از بعضی ویژگیها) هستند را در یک دسته(class) قرار میدهند و برای تمام آنها از یک تعریف ساختار استفاده میکنند و به اشیایی که درون یک دسته قرار میگیرند نمونه(Instance) میگویند.

    مخفی کردن اطلاعات (Information Hiding):

    غیر قابل دسترسی کردن ساختار درونی یک شی از اشیا بیرونی را مخفی کردن اطلاعات(Information Hiding) میگویند.

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

    کپسوله کردن(Encapsulation):

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

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

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

     

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

     
     

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

     

     

    درباره آکنده

     
     

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

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

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

     

     

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

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

     

    ابزارها

     
     
    جستجو در بلاگ


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