مقاله مقایسه زبان‌های برنامه‌نویسی 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 دارای مزایایی است که برخی از آنها از این قرارند:

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

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

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

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

(( برای دانلود کلیک کنید ))