ایستایی وجود ندارد ، هر چه هست جوشش و جاری بودن است.
خانه » پروژه » فناوری اطلاعات » مقاله مقايسه زبان‌هاي برنامه‌نويسي C # و جاوا
مقاله مقايسه زبان‌هاي برنامه‌نويسي C # و جاوا

مقاله مقايسه زبان‌هاي برنامه‌نويسي C # و جاوا

مقاله مقايسه زبان‌هاي برنامه‌نويسي 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 ها در هيپ ايجاد مي‌شوند، به اين معني كه چنين چيزي در هر زباني قابل قبول نيست.

بسياري از توليد كنندگان برنامه‌هاي كاربردي از garbage collection شكايت دارند، شايد آنها كنترل مي‌خواهند. شايد با وجود اين امكان احساس مي‌كنند برنامه‌نويسان واقعي نيستند، چرا كه نمي‌توانند Object اي را كه ايجاد كرده‌اند، delete كنند. شايد داشتن يك زبان بسيار پيچيده و مستعد خطا، مالكيت كد را از جانب توليد كننده اصلي به مدت طولاني تضمين مي‌كند. بدون توجه به اين دلايل garbage collection داراي مزايايي است كه برخي از آنها از اين قرارند:

1ـ عدم ياري حافظه. اين مزيت مشخصي است. هر دو روش garbage collection تضمين مي‌كنند تا در برخي مواقع هنگام اجراي برنامه، تمامي آبجكت را حذف كنند، اما هيچكدام زمان آن را تضمين نمي‌كنند، جز اينكه هيچ آبجكتي حذف نمي‌گردد تا زماني كه حداقل تمام ارجاعات برنامه به آن حذف گردد.

2ـ garbage collection توليد كنندگان را تشويق به نوشتن كدهاي شي‌ءگراي بيشتر مي‌كند. اين يك مزيت ظريف و دقيق است. مثلا، در C++، توليدكنندگاني كه متدهاي كلاس را ايجاد مي‌كنند بايد داده‌هايي را بازگردانند كه معمولا مرجع non-const يا پارامترهاي اشاره‌گر را در هنگام اجراي متد تنظيم مي‌كنند، يا بايد نمونه كلاسي از نوع ديگر را باز گردانند كه تركيبي از تمام داده‌هاي ضروري را نگاه مي‌دارد.

به نظر مي‌رسد مورد دوم بهتر از مورد اول باشد. چه كسي مي‌خواهد تابعي با10 پارامتر را فرا بخواند؟ و پارامترهاي بيشتري كه بين سرويس گيرنده و كد سرويس دهنده رد و بدل مي‌شوند، درگيري بيشتري ايجاد مي‌كند، كه اين اصلا خوب نيست. مثلا، اگر بعدا مشخص شود كه تابعي نياز به بازگرداندن داده‌هاي بيشتري دارد، تنها لازم است اين اجراي تابع با يك افزايش به كلاس مركب، كه ممكن است براي سرويس گيرنده تنها يك recompiler باشد، تغيير داده شود. نه تنها از اين جهت، بلكه زمانيكه يك تابع تنها يك آبجكت را باز مي‌گرداند، اين تابع مي‌تواند با ديگر فراخواني‌هاي تابع تو در تو شود، در حاليكه داده‌هاي بازگشتي با پارامترهاي in/out مانع اين تو در تويي مي‌شوند. هنگاميكه آبجكت‌ها با اين متد بهتر بازگردانده مي‌شوند، معمولا توليد كننده تنها دو گزينش پيش رو دارد: بازگرداندن يك كپي از داده‌هاي موقت كه در تابع ساخته و مقداردهي اوليه مي‌شوند، يا ايجاد اشاره‌گر جديد آبجكت در تابع، side – effect كردن مقادير derefrence شده آن، سپس بازگرداندن اشاره‌گر، كه مطمئن است، چرا كه كامپايلر، اشاره‌گرها يا داده‌هاي هيپ را در ميان فراخواني‌هاي توابع خراب نخواهد كرد. با وجود اينكه بازگرداندن يك اشاره‌گر داراي مزايايي است (يك سازنده كپي نبايد فراخواني شود بنابراين ممكن است سريعتر باشد، خصوصا با داده‌هاي بزرگتر، زير كلاسي از يك نوع اشاره‌گر مي‌تواند براي گسترده شدن به فراخوانده بازگردانده شود)، اما در C++ از اشكالات جدي نيز برخوردار است: حال سرويس گيرنده بايد با فراخواني delete در اشاره‌گر بازگشتي، به مديريت حافظه توجه كند.

براي اين كار راه‌هايي وجود دارد، يكي از اين راه‌ها شمارش مرجع با استفاده از الگوهاي عمومي است (براي اطلاعات بيشتر به سايت زير مراجعه كنيد.

 

فرمت : قابل ویرایش | WORD | صفحات : 94

*****************************************

نکته : فایل فوق قابل ویرایش می باشد

برای خرید اطلاعات خود را وارد کنید
  • کلیه پرداخت های سایت از طریق درگاه بانک سامان انجام می گیرد.هر مرحله از خرید می توانید مشکل خود را با پشتیبان و فرم تماس با ما در جریان بگذارید در سریعترین زمان ممکن مشکل برطرف خواهد شد
  • پس از پرداخت وجه ، فایل محصول هم قابل دانلود می باشد و هم به ایمیل شما ارسال می گردد .
  • آدرس ایمیل را بدون www وارد نمایید و در صورت نداشتن ایمیل فایل به تلگرام شما ارسال خواهد شد .
  • در صورت داشتن هرگونه سوال و مشکل در پروسه خرید می توانید با پشتیبانی سایت تماس بگیرید.
  • پشتیبان سایت با شماره 09383646575 در هر لحظه همراه و پاسخگوی شماست
  • 0

    User Rating: 4.55 ( 1 votes )
    اشتراک گذاری مطلب

    راهنما

    » فراموش نکنید! بخش پشتیبانی مقاله آنلاین ، در همه ساعات همراه شماست

    اطلاعات ارتباطی ما پست الکترونیکی: Article.university@gmail.com

    تماس با پشتیبانی 09383646575

    برای سفارشتان از سایت ما کمال تشکر را داریم.

    از اینکه ما را انتخاب نمودید متشکریم.

    معادله فوق را حل نمایید *

    تمام حقوق مادی , معنوی , مطالب و طرح قالب برای این سایت محفوظ است