elegates

Delegates در سي شارپ روشي مطمئن و typesafe را براي بكار گيري مفهوم function pointer ارائه مي دهند. يكي از ابتدايي ترين استفاده هاي function pointers پياده سازي callback مي باشد. اما در ابتدا لازم است تا با اصول اوليه ي كاري آن آشنا شويم.

مثال يك :
يك delegate چگونه تعريف و استفاده مي شود؟
Delegate يك شيء است كه بيانگر يك تابع مي باشد بنابراين مي تواند بعنوان آرگومان ورودي يك تابع ديگر و يا عضوي از يك كلاس بكار رود.
در زبان "function-pointer" ، Func1() اشاره گري به Func2() را بعنوان پارامتر دريافت كرده و نهايتا آنرا فراخواني مي كند.
در زبان "delegate" ، Func1() يك شيء delegate از Func2() را دريافت كرده و سپس آنرا فراخواني مي كند.
در مثال زير از دو تابع براي شرح اين مطلب سود جسته شده است:
Func1() از delegate استفاده مي كند.
Func2() يك delegate است.

( شماره گذاري خطوط ، در كد زير ، صرفا براي راحت تر شدن توضيحات در مورد آنها است و لزومي به تايپ آنها در برنامه ي اصلي نيست. )

01 using System;
02 delegate void Delg(string sTry);
03 public class Example1{

// function which uses the delegate object
04 private static void Func1(Delg d){
05 d("Passed from Func1");
06 }

// function which is passed as an object
07 private static void Func2(string sToPrint){
08 Console.WriteLine("{0}",sToPrint);
09 }

// Main execution starts here
10 public static void Main(){
11 Delg d = new Delg(Func2);
12 Func1(d);
13 }
14 }

LINE 02
يك شيء delegate را براي Func2 تعريف مي كند.

LINE 04-06
تابعي را تعريف كرده است كه آرگومان ورودي آن از نوع Delg است.

LINE 07-09
تابعي را تعريف مي كند كه بايد به صورت delegate به تابع ديگر فرستاده شود.

LINE 10-14
تابع Main اجراي برنامه را با ايجاد يك شيء delegate براي Func2 آغاز كرده و سپس تابع Func1 را فراخواني مي كند.

سربارگذاري عملگر ها (Operator OverLoading)

به تعريف مجدد راه و روش اجراي عملگر ها توسط ما ، سربارگذاري عملگرها گفته مي شود. فرض كنيد مي خواهيد عدد 2 را به يك مقدار datetime اضافه كنيد. خطاي زير حاصل خواهد شد:

CS0019: Operator '+' cannot be applied to operands of type 'System.DateTime' and 'int'

جالب بود اگر مي توانستيم عدد 2 را به datetime اضافه كنيم و نتيجه ي آن تعداد روزهاي مشخص بعلاوه ي دو مي بود. اينگونه توانايي ها را مي توان بوسيله ي operator overloading ايجاد كرد.

تنها عملگر هاي زير را مي توان overload كرد:

Unary Operators
+ - ! ~ ++ -- true false

Binary Operators
+ - * / % & | ^ << >> == != > < >= <=

نحوه ي انجام اينكار نيز در حالت كلي به صورت زير است:

return_datatype operator operator_to_be_overloaded (agruments)
{
}

به مثال زير توجه كنيد:

using System;
class MyDate
{
public DateTime tempDate;
public MyDate(int year,int month,int day)
{
tempDate=new DateTime(year,month,day);
}
public static DateTime operator + (MyDate D,int noOfDays)
{
return D.tempDate.AddDays(noOfDays);
}
public static DateTime operator + (int noOfDays,MyDate D)
{
return D.tempDate.AddDays(noOfDays);
}
}

class Test
{
static void Main()
{
MyDate MD=new MyDate(2001,7,16);
Console.WriteLine(MD + 10 );
}
}

output:
2001-07-26

مقابله با خطاها در سي شارپ (Exception Handling in C#)

EXCEPTION يك خطاي زمان اجر است كه بدليل شرايطي غيرنرمال در برنامه ايجاد مي شود. در سي شارپ exeption كلاسي است در فضاي نام سيستم. شيء ايي از نوع exception بيانگر شرايطي است كه سبب رخ دادن خطا در كد شده است. سي شارپ از exception ها به صورتي بسيار شبيه به جاوا و سي پلاس پلاس استفاده مي نمايد.

دلايلي كه بايد در برنامه exception handling حتما صورت گيرد به شرح زير است:
- قابل صرفنظر كردن نيستند و اگر كدي اين موضوع را در نظر نگيرد با يك خطاي زمان اجرا خاتمه پيدا خواهد كرد.
- سبب مشخص شدن خطا در يك نقطه از برنامه شده و ما را به اصلاح آن سوق مي دهد.

بوسيله ي عبارات try...catch مي توان مديريت خطاها را انجام داد. كدي كه احتمال دارد خطايي در آن رخ دهد درون try قرار گرفته و سپس بوسيله ي يك يا چند قطعه ي catch مي توان آنرا مديريت كرد. و اگر از اين قطعات خطايابي استفاده نشود برنامه به صورتهاي زير متوقف خواهد شد :

class A {static void Main() {catch {}}}
TEMP.cs(3,5): error CS1003: Syntax error, 'try' expected

class A {static void Main() {finally {}}}
TEMP.cs(3,5): error CS1003: Syntax error, 'try' expected

class A {static void Main() {try {}}}
TEMP.cs(6,3): error CS1524: Expected catch or finally

بهتر است يك مثال ساده را در اين زمينه مرور كنيم:

int a, b = 0 ;
Console.WriteLine( "My program starts " ) ;
try
{
a = 10 / b;
}
catch ( Exception e )
{
Console.WriteLine ( e ) ;
}
Console.WriteLine ( "Remaining program" ) ;
The output of the program is:
My program starts
System.DivideByZeroException: Attempted to divide by zero.
at ConsoleApplication4.Class1.Main(String[] args) in
d:\dont delete\consoleapplication4\class1.cs:line 51
Remaining program

در كلاس CCommObj كه با آن آشنا شديم ، آرايه اي Private از نوع ICommObjEvents به نام m_arSinkColl وجود دارد. اين آرايه تمام اينترفيس هاي sink شده را ذخيره مي كند. واژه ي sink در اينجا به كلاسي گفته مي شود كه دريافت كننده ي رخدادها است. متد Advise تنها sink وارده به آنرا در يك آرايه ذخيره مي كند و سپس انديس آرايه را كه در اينجا cookie ناميده شده است بر مي گرداند. اين كوكي توسط كلاينتي كه ديگر نمي خواهد از آن آيتم هيچونه رخدادي را دريافت كند به سرور فرستاده مي شود و سپس سرور اين آيتم را از ليست خودش حذف خواهد كرد.

نحوه ي فراخواني متد advise توسط كلاينت نيز جالب است.

public void Init(CCommObj theSource)
{
m_Server = theSource;
theSource.Advise (this);
string strAdd = ("Hello");
m_Server.read (strAdd,10);
}

در اينجا تنها يك this بعنوان آرگومان به متد advice فرستاده شده است در حاليكه انتظار مي رفت آرگوماني از نوع ICommObjEvents به تابع فرستاده شود. دليل صحت اين عمل بدين صورت است كه كلاس ClientApp_A از اينترفيس ICommObjEvents ارث برده است و آنرا پياده سازي نموده است.
در ادامه ليست كامل برنامه ي نوشته شده را در حالت Console ملاحظه مي فرماييد.

namespace CSharpCenter
{

using System;

public interface ICommObjEvents
{
void OnDataSent();
void OnError();
}
public class CCommObj
{
private int m_nIndex;
public ICommObjEvents [] m_arSinkColl;
public CCommObj()
{
m_arSinkColl = new ICommObjEvents[10];
m_nIndex = 0;
}

public void Advise(ICommObjEvents theSink)
{

m_arSinkColl[m_nIndex] = theSink;
m_nIndex++;
}
public void SendData(string strData)
{
foreach ( ICommObjEvents theSink in m_arSinkColl)
{
if(theSink != null )
{
theSink.OnDataSent ();
}
}
}
}
class CClientApp_A:ICommObjEvents
{
public void OnDataSent()
{
Console.WriteLine("OnDataSent Client App A");
}
public void OnError()
{
Console.WriteLine("OnError");
}
public void Read()
{
string strAdd = ("Hello");
m_Server.SendData (strAdd);

}
private CCommObj m_Server;
public void Init(CCommObj theSource)
{
m_Server = theSource;
theSource.Advise (this);
}
}
class CClientApp_B:ICommObjEvents
{
public void OnDataSent()
{
Console.WriteLine("OnDataSent Client App B");
}
public void OnError()
{
Console.WriteLine("OnError");
}
private CCommObj m_Server;
public void Init(CCommObj theSource)
{
m_Server = theSource;
theSource.Advise (this);
}
}
class ConsoleApp
{
public static void Main()
{
CClientApp_A theClient = new CClientApp_A ();
CClientApp_B theClient2 = new CClientApp_B ();
CCommObj theComm = new CCommObj ();
theClient.Init (theComm);
theClient2.Init (theComm);
theClient.Read();

}
}

}

 
كلاس ها ي abstract
كلاس ها را همچنين مي توان به صورت abstract تعريف كرد. از اين نوع كلاس ها نمي توان instance ايي را ايجاد نمود. در اين كلاس هاي پايه ، صرفا تعريف متدها و خواص هايي عنوان گرديده و در آينده در كلاس هاي فرزند توسعه داده خواهند شد. براي مثال :

public abstract class Named
{
public abstract String Name {get; set;} // property
public abstract void PrintName(); // method
}
public class B : Named
{
private String name = "empty";
public override String Name
{
get{return name;}
set{name=value;}
}
public override void PrintName()
{
Console.WriteLine("Name is {0}", name);
}
}

والي كه شايد پيش بيايد اين است كه اگر interface ها صرفا تعريف توابع و خواص را مي توانند در خود جاي دهند پس چه دليلي براي بكار بردن آنها و طولاني كردن كار كد نويسي وجود دارد؟
كاربردهاي زيادي را مي توان براي اينترفيس ها برشمرد. اينترفيس يك رفتار را تعريف مي كند. فرض كنيد در حال توسعه ي برنامه ايي هستيد كه بر روي دو كامپيوتر مختلف بايد با هم در ارتباط مستقيم بوده و برهم كنش داشته باشند و هر برنامه از ماژولي به نام CCommObj communication object استفاده مي نمايد. يكي از متدهاي اين شيء ، SendData() مي باشد كه رشته اي را دريافت كرده و به برنامه ي ديگر مي فرستد. اين فراخواني از نوع asynchronous است زيرا ما نمي خواهيم اگر خطايي در شبكه رخ داد، برنامه براي هميشه منتظر باقي بماند. اما چگونه برنامه ي A كه تابع ذكر شده را فراخواني كرده است مي تواند تشخيص دهد كه پيغام به مقصد رسيده است يا خير و يا آيا خطايي در شبكه مانع رسيدن پيغام گشته است يا خير؟ جواب بدين صورت است كه CCommObj هنگام دريافت پيغام ، رخدادي را سبب خواهد شد و اگر خطايي رخ داده باشد خير. در اين حالت نياز به يك ماژول logging نيز احساس مي گردد تا خطاهاي رخ داده را ثبت نمايد. يك روش انجام آن اين است كه CCommObj پياده سازي اين امكان را نيز بعهده گرفته و اگر فردا نيز خواستيم ماژول ديگري را به برنامه اضافه كنيم هر روز بايد CCommObj را تغيير دهيم. تمام اين كارها را به سادگي مي توان در يك اينترفيس مدل كرد. روش آن نيز در ادامه بيان مي گردد:
در ابتدا يك اينترفيس ايجاد مي كنيم تا ليست تمام امكانات ممكن را "منتشر" كند:

interface ICommObjEvents
{
void OnDataSent();
void OnError();
}