انجام پایان نامه

درخواست همکاری انجام پایان نامه  بانک مقالات رایگان انجام پایان نامه

سفارش پایان نامه

|

انجام پایان نامه ارشد

 پایان نامه 

پایان نامه‏ کامپیوتر

انجام پایان نامه‏ ارشد کامپیوتر

مقايسه زبان‌هاي برنامه‌نويسي C # و جاوا
 مقدمه
بسياري از زبان‌هاي برنامه‌نويسي امروزي از اين قرارند: C++,C ، Javad , C# , COBOL , Microsoft Visual Basic و غيره. با وجود اين همه زبان، يك مهندس نرم‌افزار چگونه تصميم مي‌گيرد كه كداميك از آنها را براي يك پروژه استفاده كند. گاهي اوقات، يك زبان به اين دليل انتخاب مي‌شود كه توليد كنندگان يك شركت كار با آن را دوست دارند و يا مي‌شناسند، كه اين مي‌تواند يك دليل منطقي باشد. گاهي اوقات يك زبان به دليل جديد بودن و فوق العاده بودنش انتخاب مي‌شود، كه اين يك ابزار بازاريابي براي جلب نظر عمومي به يك محصول مي‌باشد، و ممكن است اين دليل منطقي به نظر نرسد. در حالت ايده‌آل، يك زبان برنامه‌نويسي بايد بر مبناي توانايي‌هاي آن جهت اجراي يك كار خاص انتخاب شود و حل يك مشكل بايد تعيين كننده زبان باشد.
ما تنها به مقايسه زبان‌هاي C# و جاوا مي‌پردازيم. برخي زبان‌ها، همچون C++ و پاسكال، نيز در اين مقايسه استفاده مي‌شوند، اما تنها براي كمك به اثبات انگيزه‌هاي بالقوه براي ايجاد زبان‌هاي برنامه‌نويسي جديدتر با ويژگي‌هاي جديدتر. اگر در زبان قديمي‌تر ضعف‌هايي وجود دارد و در زبان جديدتر اين ضعف‌ها ديده نمي‌شوند و يا از نظرها پنهان شده‌اند، اين مسئله مي‌تواند بيانگر انگيزه معماران در انجام برخي تغييرات در زبان جديدتر باشد. شناخت اين انگيزه اغلب حائز اهميت است،‌ چرا كه در غير اينصورت انتقاد هدف‌دار از يك زبان غيرممكن مي‌شود.
مثلا، اگر ويژگي معروفي كه در زبان قبلي وجود داشته از زبان جديدتر حذف شود، يك توليد كننده برنامه كاربردي ممكن است احساس كند كه زبان جديدتر جايگزين با ارزشي براي زبان قبلي نيست، چرا كه قدرت زبان قبلي را ندارد. هر چند كه زبان جديدتر ممكن است واقعا ويژگي‌هاي موثري را در اختيار او قرار دهد و او را از گرفتار شدن در برخي مشكلات شناخته شده حفظ نمايد.
توليد جاوا به قبل C# باز مي‌گردد، و C# جداي از ديگر زبان‌ها ايجاد نشد. كاملا طبيعي است كه C# در برگيرنده نقاط قوت و ضعف جاوا است، درست مانند جاوا كه برگرفته از Objective – C بود و آن هم برگرفته از C و به همين ترتيب.
بنابراين، C# نبايد متفاوت از جاوا باشد. اگر جاوا كامل بود، ديگر دليلي براي ايجاد C# وجود نداشت. اگر C# كامل باشد، ديگري دليلي براي ايجاد زبان برنامه‌نويسي جديدتر وجود ندارد. بهرحال، آينده نامشخص است، و هم اكنون C# و جاوا زبان‌هاي برنامه‌نويسي شي‌ءگراي خوبي هستند.
شباهت‌هاي بين C# و جاوا
از نقطه نظر توليد كننده برنامه كاربردي، C# و جاوا كاملا شبيه هم هستند، در اين بحث به شباهت‌هاي اصلي اين دو زبان خواهيم پرداخت.
تمامي آبجكت‌ها مرجع هستند
انواع مرجع‌ها بسيار شبيه اشاره‌گرها (pointer) در C++ هستند، به خصوص وقتي كه شناسه‌اي را براي برخي نمونه‌هاي جديد كلاس تنظيم مي‌كنيد. اما هنگام دستيابي به نمونه‌هاي داده‌ها در C++  است كه در پشته ايجاد مي‌شوند. تمامي نمونه‌هاي كلاس با استفاده از اپراتور جديد در هيپ ايجاد مي‌شوند، اما استفاده از delete مجاز نيست چرا كه هر دو زبان از روش‌هاي garbage collection متعلق به خود استفاده مي‌كنند.
Garbage Collection
طبيعتا، ياري نكردن حافظه مشكل بزرگي در زبان‌هاي نظير C++ است. اين فوق‌العاده است كه شما بتوانيد بطور پويا نمونه‌هاي كلاس را در زمان اجرا در هيپ ايجاد كنيد، اما مديريت حافظه مي‌تواند مشكل‌ساز باشد.
C# و جاوا هر دو داراي garbage collection توكار هستند. به عبارتي براي آزادسازي حافظه ديگر نيازي به فراخواني delete نيست. هيچ زباني اجازه تسهيم كردن Object اي را كه قابل مصرف است به شما نمي‌دهد. اما ممكن است از شما خواسته شود تا new را حتي بيشتر از آنچه كه دوست داريد، فرا بخوانيد. علت اين مسئله آن است كه در هر دو زبان تمامي Object ها در هيپ ايجاد مي‌شوند، به اين معني كه چنين چيزي در هر زباني قابل قبول نيست.

Class BadaBing
{
           Public BadaBing   (  )
           {
           }
}
BadaBing badaBing   (  ) ;     // You can’t create
temporary data but You must use parens on
a constructor
كامپايلر پيغام كوتاهي را در اين باره براي شما مي‌فرستد، چرا كه شما سعي مي‌كنيد ذخيره‌سازي موقتي را ايجاد كنيد. بايد اين كار را انجام دهيد:
BadaBing badaBing = new BadaBing  (  ) ;
حال badaBoom ساخته شد و داراي حداقل يك مرجع است. بعد، ممكن است بخواهيد تا از دست آن خلاص شويد.
delete BadaBoom;    // illegal in C# and
Java – the compiler will complain
تا جائيكه مي‌خواهيد از badaBoom استفاده كنيد، سپس زمانيكه تصميم مي‌گيريد مرجع خود را به ديگري بدهيد، garbage colletor شما را از دست آن خلاص مي‌كند.
بسياري از توليد كنندگان برنامه‌هاي كاربردي از garbage collection شكايت دارند، شايد آنها كنترل مي‌خواهند. شايد با وجود اين امكان احساس مي‌كنند برنامه‌نويسان واقعي نيستند، چرا كه نمي‌توانند Object اي را كه ايجاد كرده‌اند، delete كنند. شايد داشتن يك زبان بسيار پيچيده و مستعد خطا، مالكيت كد را از جانب توليد كننده اصلي به مدت طولاني تضمين مي‌كند. بدون توجه به اين دلايل garbage collection داراي مزايايي است كه برخي از آنها از اين قرارند:
1ـ عدم ياري حافظه. اين مزيت مشخصي است. هر دو روش garbage collection تضمين مي‌كنند تا در برخي مواقع هنگام اجراي برنامه، تمامي آبجكت را حذف كنند، اما هيچكدام زمان آن را تضمين نمي‌كنند، جز اينكه هيچ آبجكتي حذف نمي‌گردد تا زماني كه حداقل تمام ارجاعات برنامه به آن حذف گردد.
2ـ garbage collection توليد كنندگان را تشويق به نوشتن كدهاي شي‌ءگراي بيشتر مي‌كند. اين يك مزيت ظريف و دقيق است. مثلا، در C++، توليدكنندگاني كه متدهاي كلاس را ايجاد مي‌كنند بايد داده‌هايي را بازگردانند كه معمولا مرجع non-const يا پارامترهاي اشاره‌گر را در هنگام اجراي متد تنظيم مي‌كنند، يا بايد نمونه كلاسي از نوع ديگر را باز گردانند كه تركيبي از تمام داده‌هاي ضروري را نگاه مي‌دارد.
به نظر مي‌رسد مورد دوم بهتر از مورد اول باشد. چه كسي مي‌خواهد تابعي با10 پارامتر را فرا بخواند؟ و پارامترهاي بيشتري كه بين سرويس گيرنده و كد سرويس دهنده رد و بدل مي‌شوند، درگيري بيشتري ايجاد مي‌كند، كه اين اصلا خوب نيست. مثلا، اگر بعدا مشخص شود كه تابعي نياز به بازگرداندن داده‌هاي بيشتري دارد، تنها لازم است اين اجراي تابع با يك افزايش به كلاس مركب، كه ممكن است براي سرويس گيرنده تنها يك recompiler باشد، تغيير داده شود. نه تنها از اين جهت، بلكه زمانيكه يك تابع تنها يك آبجكت را باز مي‌گرداند، اين تابع مي‌تواند با ديگر فراخواني‌هاي تابع تو در تو شود، در حاليكه داده‌هاي بازگشتي با پارامترهاي in/out مانع اين تو در تويي مي‌شوند. هنگاميكه آبجكت‌ها با اين متد بهتر بازگردانده مي‌شوند، معمولا توليد كننده تنها دو گزينش پيش رو دارد: بازگرداندن يك كپي از داده‌هاي موقت كه در تابع ساخته و مقداردهي اوليه مي‌شوند، يا ايجاد اشاره‌گر جديد آبجكت در تابع، side – effect كردن مقادير derefrence شده آن، سپس بازگرداندن اشاره‌گر، كه مطمئن است، چرا كه كامپايلر، اشاره‌گرها يا داده‌هاي هيپ را در ميان فراخواني‌هاي توابع خراب نخواهد كرد. با وجود اينكه بازگرداندن يك اشاره‌گر داراي مزايايي است (يك سازنده كپي نبايد فراخواني شود بنابراين ممكن است سريعتر باشد، خصوصا با داده‌هاي بزرگتر، زير كلاسي از يك نوع اشاره‌گر مي‌تواند براي گسترده شدن به فراخوانده بازگردانده شود)، اما در C++ از اشكالات جدي نيز برخوردار است: حال سرويس گيرنده بايد با فراخواني delete در اشاره‌گر بازگشتي، به مديريت حافظه توجه كند.
براي اين كار راه‌هايي وجود دارد، يكي از اين راه‌ها شمارش مرجع با استفاده از الگوهاي عمومي است (براي اطلاعات بيشتر به سايت زير مراجعه كنيد.
Ms-help : //MS. VSCC/MS.MSDNVS/vbcon/html/
Vbcon Reference Counting Garbage Collection Object Lifetime. htm
بهرحال، شمارش مرجع به دليل نحوه گرامري الگو كاملا رضايت‌بخش نيست، و اگر زمانيكه طرح‌‌هاي garbage collection جاوا و C# كار مي‌كنند، اجراهاي شمارش چرخه‌ها را به درستي اداره نكند، وضعيت بدتر هم مي‌شود (يك چرخه از شمارش مرجع ساده‌اي استفاده مي‌كند: اگر دو آبجكت به يكديگر ارجاع داشته باشند، و سپس تنها مرجعات بيروني براي هر دو منتشر شود، هيچ كدام delete  نمي‌شوند، زيرا هر كدام يك مرجع ديگر دارند، و هر Object تا زمانيكه شماره مرجع آن به صفر برسد delete نمي‌شود. بنابراين، توليد كنندگان معمولا ايمن‌ترين راه را انتخاب مي‌كنند، و تنها يك كپي از نوع كلاس شناخته شده زمان كامپايل را باز مي‌گردانند.
اما از آنجائيكه هر دو زبان C# و جاوا از garbage collection استفاده مي‌كنند، توليد كنندگان تشويق مي‌شوند هنگام نوشتن الگوسازي‌هاي تابع (بجاي استفاده از پارامترهاي داخلي / خارجي) ارجاع جديد به داده‌ها را باز گردانند، كه در اينصورت نيز ترغيب مي‌شوند در جائيكه فراخواننده نبايد از نوع دقيق داده‌ها اطلاعي داشته باشد، زير كلاسي از نوع بازگشتي تعريف شده، يا نمونه كلاسي كه رابط‌ها را اجرا مي‌كند، بازگردانند. بدين طريق توليدكنندگان به راحتي مي‌توانند در صورت نياز، كد سرويس را در آينده بدون متوقف كردن سرويس گيرنده‌هاي آن، با ايجاد زير كلاس‌هاي مخصوص نوع بازگشتي، تغيير دهند.
3ـ Garbage collection، به اشتراك گذاشتن داده‌ها را ساده‌تر مي‌سازد. گاهي اوقات برنامه‌هاي كاربردي ساخته مي‌شوند كه مستلزم به اشتراك گذاردن آبجكت هستند. مشكلاتي كه در تعريف مسئوليت‌هاي clean up وجود دارد از اين قرارند: اگر آبجكتA و آبجكتB، pointer C  را به اشتراك بگذارند، آيا آبجكتA بايد C delete كند يا آبجكتB ؟ مشكل همين حذف كردن است: B,A نبايد (و يا نمي‌توانند) C را كه از C# يا جاوا، استفاده مي‌كند delete كنند. آبجكت B,A تا زمانيكه لازم باشد از C استفاده مي‌كنند، سپس زمانيكه ديگر ارجاعي صورت نمي‌گيرد، سيستم مسئول حذف كردنC است. طبيعتا، توليد كننده نيز هنگام دسترسي به داده‌هاي مشترك بايد به قسمت‌هاي اصلي توجه داشته باشد و بايد به روش استاندارد آن را اداره نمايد.








انجام پایان نامه

انجام پایان نامه کامپیوتر، انجام پایان نامه ارشد کامپیوتر، انجام پایان نامه، پایان نامه

برای دیدن ادامه مطلب از لینک زیر استفاده نمایید

 

سفارش پایان نامه

نقشه