تحقیق مقاله مقایسه زبان‌ های برنامه ‌نویسی 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 است. طبیعتا، تولید کننده نیز هنگام دسترسی به داده‌های مشترک باید به قسمت‌های اصلی توجه داشته باشد و باید به روش استاندارد آن را اداره نماید.

4 برنامه‌ها باید بطور خودکارصحیح‌تر شوند. تولید کنندگان برنامه کاربردی می‌توانند بجای مدیریت حافظه، به منطق برنامه و صحت آن توجه و تمرکز کنند تا کدی با اشکالات کمتر ایجاد شود. این مسئله بسیار حائز اهمیت می‌باشد.

جاوا و C# هر دو زبان‌های Type – Safe هستند

Saraswat در صفحه وب خود می‌گوید:یک زبان در صورتی Type–Safe است که تنها عملیات انجام شده بر روی داده‌های آن، از نوع عملیاتی باشد که توسط نوع داده‌ها تصویب می‌شوند. بنابراین، نتیجه می‌گیریم که طبق این تعریف، C++ ، Type – Safe نیست، حداقل به این دلیل که یک تولید کننده ممکن است نمونه‌ای از برخی کلاس‌ها را به درگیری تبدیل نوع (cast) کند و داده‌های نمونه را با استفاده از تبدیل نوع غیر قانونی و متدها و اپراتورهای ناخواسته رونویسی نماید.

جاوا و C# طراحی شدند تا Type–Safe باشند. یک تبدیل نوع غیر قانونی در صورتیکه غیرقانونی بودن آن نشان داده شود، در زمان کامپایل گیر خواهد افتاد، و یا اینکه اگر Object نتواند به نوع جدید تبدیل شود، در زمان اجرا یک استثناء به وجود خواهد آمد. بنابراین Type–Safe بودن حائز اهمیت است، زیرا نه تنها تولید کننده را مجبور به نوشتن کد صحیح‌تر می‌کند، بلکه به سیستم کمک می‌کند تا از دست افراد بی‌توجه در امان بماند.

جاوا و C# هر دو زبان‌های شی‌ءگرا هستند

هر کلاسی در هر زبانی تلویحا (یا صریحا) یک Object را به زیر کلاس‌هایی تقسیم می‌کند. این ایده بسیار خوبی است، چرا که در اینصورت یک کلاس پایه پیش فرض برای هر کلاس توکار (built-in) یا تعریف توسط کاربر ارائه می‌شود. C++ می‌تواند تنها با استفاده از اشاره‌گرهای void این پشتیبانی را شبیه‌سازی کند، به دلایلی از جمله Type – Safe مسئله‌ساز هستند. چرا این افزایش در زبان جاوا و C# خوب است؟ یک دلیل آن اینست که ایجاد محفظه‌های (container) بسیار عمومی مجاز می‌شود. مثلا هر دو زبان دارای کلاس‌های پشته از پیش تعریف شده هستند، که به کد برنامه کاربردی اجازه می‌دهند تا هر Object را به یک نمونه پشته مقداردهی شده push کند، سپس pop را فرا بخواند تا مرجع بالایی Object را حذف و به فراخواننده بازگرداند شبیه تعریف قدیمی پشته است. طبیعتا، این امر مستلزم آن است که تولید کننده، مرجع حذف شده را به کلاس‌های خاص برگرفته از Object تبدیل نوع کند، بگونه‌ای که عملیات معناداری انجام شود، اما در حقیقت نوع تمامی Object هایی که در هر نمونه پشته وجود دارد باید از جانب تولید کننده به زمان کامپایل شناسانده شود حداقل به این دلیل که اگر رابط عمومی کلاس ناشناخته باشد، زمانیکه Object های حذف شده را ارجاع می‌دهد، اغلب کار کردن با آن Objectها دشوار است.

در C++، اکثر تولیدکنندگان از تطبیق دهنده محفظه stack در Standard Template Library (STL) استفاده می‌کنند. برای آنهایی که با STL آشنایی ندارند، Schildt می‌گوید که STL در اوایل سال 1990 توسط Alexander Stepanov طراحی شد و در سال (5) 1994 توسط انجمن ANSI C++ مورد تصویب واقع شده و در دسترس اکثر کامپایلرهای تجاری C++ و امروزه IDE ها، از جمله eMbdded Visual Tools.NET قرار گرفت. بخصوص اینکه، STL که مجموعه‌ای از محفظه‌ها، تطبیق دهنده‌های محفظه، الگوریتم‌ها و غیره می‌باشد، تولید برنامه کاربردی C++ را آسان می‌سازد به این ترتیب که به هر کلاس C++ (و ابتدائی‌ترین آنها) اجازه می‌دهد از طریق تعریف یک الگوسازی عمومی، ساخته و درج شود.

بهرحال، در مورد الگوسازی در C++ مسائلی وجود دارد. مثلا پشته جدید int ها بدین طریق ایجاد می‌شود:

# include    < stack >

using namespace std;

stack < int > intstack;

تعریف الگوسازی مشخص شد، پس تعریف واقعی کلاس پشته int و کد اجرایی با استفاده از آن الگوسازی، در پشت پرده ایجاد می‌شود. به این ترتیب طبیعتا کدهای بیشتری به فایل اجرایی اضافه می‌گردد. حافظه و درایو دیسک سخت امروزه ارزان است. اما اگر انواع مختلف الگوسازی‌ها توسط یک تولید کننده استفاده شود، مسئله‌ساز می‌گردد. یک پشته باید دارای یک constructor  یک destructor ، یک push، یک pop و شاید یک متد size و یا Boolean empty باشد. به چیز دیگری نیز نیاز ندارد. و تا زمانیکه آن نوع یک Object است، به دیگر نوع‌های موجود توجه نمی‌کند.

بهرحال، پشته STL به این روش کار نمی‌کند. این کار مستلزم دانستن زمان کامپایل نوعی است که آن را نگاه می‌دارد (تعریف الگوسازی مهم نیست، اما تعریف کامپایلر لازم می‌باشد). و پشته STL شامل مجموعه‌ایی از توابع پشته classic نیست. برای مثال، pop یک تابع void است، تولید کننده ابتدا باید top را فرا بخواند، که در این صورت یک آدرس به بالای پشته باز می‌گردد، سپس pop را فرا بخواند، که این بدان معنی است که یک عمل هم اکنون به دو عمل تبدیل شده است. مشکل وراثت در C++ به احتمال زیاد موجب این تصمیم می‌شود: اگر تابع pop عنصر را بازگرداند و آن را از stack حذف کند، باید یک کپی را بازگرداند(آدرس آن عنصر دیگر معتبر نیست). سپس اگر فراخواننده پس از بازرسی آن عنصر را نخواهد، باید کپی را به push , stack  کند. مجموعه این عملیات روند کندتری دارد، بخصوص اگر نوع stack کاملا بزرگ باشد. بنابراین یک متد بازرسی top اضافه شد که هیچ‌گونه تاثیر جانبی بر تعداد عناصر stack نداشت، و به تولیدکننده اجازه می‌داد تا قبل از حذف یک نمونه کلاس آن را peek کند. اما هنگامیکه یک تولید کننده به عنصر top دسترسی می‌یابد، برخی توابع را در آن فرا می‌خواند، وی ممکن است یک عنصر داخل محفظه (container) را side-effect کند، که حداقل در برخی سناریوها ممکن است روش خوبی نباشد. معماری اصلی STL ممکن است از تولید کنندگان بخواهد تنها از اشاره‌گرها یا محفظه‌ها استفاده کنند (در حقیقت، اشاره‌گرها مجازند، اما شما همچنان باید مدیریت حافظه را در نظر بگیرید)، که ممکن است تغییر الگوسازی را تحت تاثیر قرار دهد و موجب شود متد pop، یک اشاره‌گر را حذف و به عنصر بالایی بازگرداند، اما مسئله فقدان garbage collection مجددا مطرح می‌شود.

به نظر می‌رسد با وجود محدودیت‌ها و مشکلاتی که به C++ به ارث رسیده، لازم است تعریف عمومی STL , Stack از دیدگاه کلاسیک تغییر کند که چنین چیزی اصلا خوب نیست. تنها مزیت قابل بحث در C++ با استفاده از الگوسازی‌های پشته در مقایسه با الگوسازی‌های پشتهC# و جاوا از این قرار است: در متد الگوی top، نیاز به هیچ‌گونه تبدیل نوع نیست، زیرا زمان کامپایلی که کلاس stack را ایجاد کرده دارای اطلاعاتی درباره نوع آدرسی است که باید حفظ کند. اما اگر نظریه بالا تولید کننده را متقاعد کند که وی حتما باید بداند از چه نوعی در نمونه stack مختص خود استفاده کند، این مسئله اهمیت کمتری می‌یابد.

در عوض، رابط‌های عمومی مربوط به کلاس‌های stack در هر دو زبان جاوا و C# از روش کلاسیک پیروی می‌کنند: push دادن یک Object به Stack، که در این صورت Object در بالا قرار می‌گیرد، سپس pop کردن stack، که عنصر بالایی را حذف و باز می‌گرداند. چرا جاوا C# قادر به انجام این کار هستند؟ به این دلیل که آنها هر دو زبان OOP هستند، و شاید مهمتر اینکه، آنها با استفاده از مرجع‌ها از garbage collection پشتیبانی می‌کنند. کد Stack می‌تواند بسیار جدی باشد، چرا که می‌داند سرویس گیرنده نباید cleanup را اداره کند. و یک Stack می‌تواند هر Object ای را نگاه دارد.

دلایل زیاد دیگری وجود دارد که چرا ترجیحا باید از زبان شی‌ءگرای محض توسعه‌پذیری برنامه کاربردی، مدل‌سازی جهان واقعی و غیره استفاده کرد. اما چه چیزی یک زبان شی‌ءگرای محض را تعریف می‌کند:

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

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

تمام نوع‌های ایجاد شده توسط کاربر بطور تلویحی زیر کلاس برخی از کلاس‌های پایه باشند، که معمولا Object خوانده می‌شود.

زبانی که اجازه دهد متدها در کلاس‌های مشتق شده، متدهای کلاس پایه را override کنند

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

زبانی که اجازه دهد ترازهای امنیتی داده‌های کلاس، که معمولا به صورت public تعریف می‌شوند، به صورت private , protected تغییر یابند.

باید overload کردن اپراتور را مجاز بداند

نباید فراخوانی‌های عمومی تابع را مجاز بداند یا باید آن را بسیار محدود کند در برخی کلاس‌ها تابع باید بیشتر متد یا نمونه رابط باشد.

هر نوع (type) دارای داده و مجموعه عملیاتی است که می‌تواند در آن نوع اجرا شوند باید type-safe باشد

دارای توانایی‌های خوبی در مدیریت حالت استثناء‌ها باشد.

آرایه‌ها باید Object های first-class باشند: یک تولید کننده باید قادر به پرس و جوی یک Object در اندازه خود و نوعی باشد که آن را نگاه خواهد داشت.

از آنجائیکه C++ از ابتدا طوری طراحی شده که سازگار باC باشد، در برنامه‌نویسی شی‌ءگرایی محض سریعا ناسازگاری نشان خواهد داد، زیرا استفاده از فراخوانی‌های عمومی تابع را حداقل در صورت استفاده از نیازمندی‌ها شرح داده شده فوق، مجاز می‌داند. و آرایه‌ها در C++ ، Objectهای first-class نیستند که این امر موجب نگرانی تولیدکنندگان شده است. طبیعتا، اگر یک تولید کننده با ایجاد لفافه‌های آرایه، استفاده از وراثت، دوری از فراخوانی‌های عمومی تابع و غیره از زیرمجموعه‌ای از مجموعه مشخصات C++ استفاده کند، کد مخصوص C++ وی را می‌توان شی‌ءگرا نامید. اما از آنجائیکه C++ به شما اجازه انجام کارهایی را می‌دهد که در تعریف زبان شی‌ءگرای محض مجاز به انجام آنها نیستنید، بهتر است آن را هیبرید بنامید.

بنظر می‌رسد C# و جاوا معیارهای فوق را برآورده می‌سازند، بنابراین می‌توان گفت که هر دوی آنها زبان‌های برنامه‌نویسی شی‌ءگرای محض هستند. به نظر می‌رسد که تنها تجربه در برنامه‌نویسی است که به شما می‌گوید که زبانی واقعا شی‌ءگرا است یا خیر، نه ضرورتا بر اساس یکسری نیازمندی‌های سخت و محکم.

تک وراثتی

C# و جاوا تنها یک وراثت را مجاز می‌دانند. در هر دو زبان، هر کلاسی مجاز به اجرای هر تعداد رابطی است که نیاز دارد. یک رابط چیست؟ رابط شبیه یک کلاس است رابط دارای مجموعه متدهایی است که می‌توانند در هر نمونه کلاسی که آنها را اجرا می‌کند فراخونی شوند اما رابط از داده‌ها استفاده نمی‌کند و تنها یک تعریف است. هر کلاسی که یک رابط را اجرا می‌کند باید بازای تمام متدها یا خصوصیات تعریف شده توسط رابط، تمام کد اجرایی را بکار بگیرد. بنابراین، یک رابط بسیار شبیه یک کلاس در C++ است که دارای تمام توابع مجازی محض می‌باشد (متدهای یک constructor خصوصی یا محافظت شده و یک destructor عمومی که عملکرد جالبی را ارائه نمی‌دهد) و از داده‌های اضافی استفاده نمی‌کند.

چرا این دو زبان همانند C++ از وراثت چندگانه پشتیبانی نمی‌کنند؟ Lippman وراثت را به صورت سلسله مراتبی در نظر می‌گیرد و آن را به صورت نمودار مستقیم غیر مدور (DAG) شرح می‌دهد، بگونه‌ای که تعریف هر کلاس از طریق یک گره نشان داده می‌شود و برای هر رابطه پایه به فرزند مستقیم (base-to-direct-child) یک لبه (edge) وجود دارد. بنابراین، مثال زیر سلسله مراتب یک پاندا در باغ‌وحش را نشان می‌دهد.

حیوانات

باغ وحش

خرس

پاندا

چه چیزی در این شکل اشتباه است؟ تا زمانیکه تنها یک وراثت پشتیبانی می‌شود، هیچ اشکالی وجود ندارد. در مورد تک وراثتی، بدون در نظر گرفتن فاصله، تنها یک مسیر از هر کلاس پایه به هر کلاس مشتق شده وجود دارد. در وراثت چندگانه، وجود دارد، بازای هر گره، مجموعه‌ای از حداقل دو کلاس پایه وجود دارد که یک پایه از خودشان را به اشتراک می‌گذارند. بنابراین مثال Lippman به این طریق به نمایش در می‌آید: