لماذا يجب علي تجنب الميراث المتعدد في C++؟

Question

هل يعد استخدام الميراث المتعدد مفهومًا جيدًا أم يمكنني القيام بأشياء أخرى بدلاً من ذلك؟

Answer 1

الوراثة المتعددة (المختصرة بـ MI) الروائح, ، مما يعنى عادة, لقد تم ذلك لأسباب سيئة، وسوف ينتقم في وجه المشرف.

ملخص

1. النظر في تكوين الميزات، بدلا من الميراث
2. كن حذرا من الماس الرهبة
3. فكر في وراثة واجهات متعددة بدلاً من الكائنات
4. في بعض الأحيان، الميراث المتعدد هو الشيء الصحيح.إذا كان الأمر كذلك، فاستخدمه.
5. كن مستعدًا للدفاع عن بنيتك المتعددة الموروثة في مراجعات التعليمات البرمجية

1.ربما التكوين؟

وهذا ينطبق على الميراث، وبالتالي فهو أكثر صحة بالنسبة للميراث المتعدد.

هل يحتاج كائنك حقًا إلى أن يرث من كائن آخر؟أ Car لا يحتاج إلى أن يرث من Engine للعمل، ولا من أ Wheel.أ Car لديه Engine وأربعة Wheel.

إذا كنت تستخدم الوراثة المتعددة لحل هذه المشكلات بدلاً من التركيب، فقد ارتكبت خطأً ما.

2.الماس الرهبة

عادة، لديك فئة A, ، ثم B و C كلاهما يرث من A.و(لا تسألني لماذا) ثم يقرر شخص ما ذلك D يجب أن يرث كلاهما من B و C.

لقد واجهت هذا النوع من المشاكل مرتين خلال 8 ثماني سنوات، ومن الممتع أن أرى ذلك للأسباب التالية:

1. كم كان الخطأ منذ البداية (في كلتا الحالتين، D ولا ينبغي أن يرث من كليهما B و C)، لأن هذه كانت بنية سيئة (في الواقع، C لا ينبغي أن تكون موجودة على الإطلاق ...)
2. كم كان المشرفون يدفعون مقابل ذلك، لأنه في C++، الفئة الأصلية A كان حاضرا مرتين في صف الحفيد D, ، وبالتالي تحديث حقل أصل واحد A::field يعني إما تحديثه مرتين (من خلال B::field و C::field) ، أو حدوث خطأ ما بصمت وتعطله لاحقًا (مؤشر جديد في B::field, ، وحذف C::field...)

يؤدي استخدام الكلمة الأساسية virtual في لغة C++‎ لتأهيل الميراث إلى تجنب التخطيط المزدوج الموضح أعلاه إذا لم يكن هذا هو ما تريده، ولكن على أي حال، من خلال تجربتي، من المحتمل أنك تفعل شيئًا خاطئًا...

في التسلسل الهرمي للكائنات، يجب أن تحاول الاحتفاظ بالتسلسل الهرمي كشجرة (العقدة لها أصل واحد)، وليس كرسم بياني.

المزيد عن الماس (تحرير 2017-05-03)

المشكلة الحقيقية مع Diamond of Dread في C++ (بافتراض أن التصميم سليم - قم بمراجعة الكود الخاص بك!)، هل هذا تحتاج إلى الاختيار:

• هل هو مرغوب فيه للفئة A أن تتواجد مرتين في تخطيطك، وماذا يعني ذلك؟إذا كان الجواب نعم، فبالتأكيد ورث منه مرتين.
• وإذا كان يجب أن يوجد مرة واحدة فقط، فيرث منه عمليا.

هذا الاختيار متأصل في المشكلة، وفي لغة C++، على عكس اللغات الأخرى، يمكنك فعل ذلك دون عقيدة تفرض تصميمك على مستوى اللغة.

ولكن مثل كل القوى، تأتي مع هذه القوة المسؤولية:قم بمراجعة التصميم الخاص بك.

3.واجهات

عادةً ما يكون الوراثة المتعددة لفئات ملموسة واحدة أو صفر، وواجهات صفر أو أكثر أمرًا جيدًا، لأنك لن تواجه "ماس الرهبة" الموصوف أعلاه.في الواقع، هذه هي الطريقة التي تتم بها الأمور في جافا.

عادة، ما تقصده عندما يرث C من A و B هو أنه يمكن للمستخدمين استخدامها C كما لو كان A, و/أو كما لو كان B.

في لغة C++، الواجهة عبارة عن فئة مجردة تحتوي على:

1. تم إعلان كل طريقتها افتراضية خالصة (ملحقة بـ = 0) ^{(تمت إزالة 2017-05-03)}
2. لا توجد متغيرات الأعضاء

لا يعتبر الميراث المتعدد من صفر إلى كائن حقيقي واحد والواجهات الصفرية أو أكثر "كريهة الرائحة" (على الأقل ليس بنفس القدر).

المزيد عن واجهة C++ Abstract (تحرير 2017-05-03)

أولاً، يمكن استخدام نمط NVI لإنتاج واجهة، لأن المعيار الحقيقي هو عدم وجود دولة (أي.لا توجد متغيرات الأعضاء، باستثناء this).الهدف من واجهتك المجردة هو نشر عقد ("يمكنك الاتصال بي بهذه الطريقة، وبهذه الطريقة")، لا أكثر ولا أقل.يجب أن يكون الحد من استخدام الطريقة الافتراضية المجردة فقط خيارًا للتصميم، وليس التزامًا.

ثانيًا، في لغة C++، من المنطقي أن ترث فعليًا من الواجهات المجردة (حتى مع التكلفة/المراوغة الإضافية).إذا لم تقم بذلك، وظهر وراثة الواجهة عدة مرات في التسلسل الهرمي لديك، فستواجه بعض الغموض.

ثالثًا، اتجاه الكائن رائع، لكنه ليس كذلك الحقيقة الوحيدة هناك^TM في سي ++.استخدم الأدوات المناسبة، وتذكر دائمًا أن لديك نماذج أخرى في C++ تقدم أنواعًا مختلفة من الحلول.

4.هل حقا بحاجة إلى وراثة متعددة؟

في بعض الأحيان، نعم.

عادة، الخاص بك C الطبقة ترث من A و B, ، و A و B هما كائنان غير مرتبطين (أي.ليس في نفس التسلسل الهرمي، لا يوجد شيء مشترك، مفاهيم مختلفة، وما إلى ذلك).

على سبيل المثال، يمكن أن يكون لديك نظام Nodes بإحداثيات X، Y، Z، قادرة على إجراء الكثير من الحسابات الهندسية (ربما نقطة، جزء من كائنات هندسية) وكل عقدة هي وكيل آلي، قادر على التواصل مع وكلاء آخرين.

ربما لديك بالفعل إمكانية الوصول إلى مكتبتين، لكل منهما مساحة اسم خاصة بها (سبب آخر لاستخدام مساحات الأسماء...لكنك تستخدم مساحات الأسماء، أليس كذلك؟)، كائن واحد geo والكائن الآخر ai

لذلك لديك الخاصة بك own::Node تستمد على حد سواء من ai::Agent و geo::Point.

هذه هي اللحظة التي يجب أن تسأل فيها نفسك ما إذا كان يجب عليك عدم استخدام التركيبة بدلاً من ذلك.لو own::Node هو حقا حقا على حد سواء أ ai::Agent و أ geo::Point, ، فإن التكوين لن يفعل.

إذًا ستحتاج إلى الميراث المتعدد، مع الحصول على own::Node التواصل مع العملاء الآخرين وفقًا لموقعهم في مساحة ثلاثية الأبعاد.

(سوف تلاحظ ذلك ai::Agent و geo::Point غير مرتبطين تمامًا، تمامًا، تمامًا...وهذا يقلل بشكل كبير من خطر الميراث المتعدد)

حالات أخرى (تحرير 2017-05-03)

وهناك حالات أخرى:

• باستخدام الميراث (نأمل أن يكون خاصًا) كتفاصيل التنفيذ
• يمكن لبعض مصطلحات C++ مثل السياسات استخدام الوراثة المتعددة (عندما يحتاج كل جزء إلى التواصل مع الآخرين من خلال this)
• الميراث الظاهري من std::exception (هل الميراث الافتراضي ضروري للاستثناءات؟)
• إلخ.

في بعض الأحيان يمكنك استخدام التركيب، وأحيانا يكون MI أفضل.المقصود هو:لديك خيار.افعل ذلك بطريقة مسؤولة (واطلب مراجعة الكود الخاص بك).

5.لذا، هل يجب أن أقوم بالميراث المتعدد؟

في أغلب الأحيان، حسب تجربتي، لا.MI ليس الأداة الصحيحة، حتى لو بدا أنه يعمل، لأنه يمكن أن يستخدمه الكسالى لتجميع الميزات معًا دون إدراك العواقب (مثل إنشاء Car كلاهما Engine و أ Wheel).

لكن في بعض الأحيان، نعم.وفي ذلك الوقت، لن يعمل شيء أفضل من MI.

ولكن نظرًا لأن MI كريهة الرائحة، فكن مستعدًا للدفاع عن بنيتك في مراجعات التعليمات البرمجية (والدفاع عنها أمر جيد، لأنه إذا لم تكن قادرًا على الدفاع عنها، فلا يجب عليك القيام بذلك).

Answer 2

مع بيارن ستروستروب :

<اقتباس فقرة>   

والكثير من الناس يعتقدون بشكل صحيح تماما أنك لا تحتاج إلى وراثة متعددة، لأن أي شيء يمكنك القيام به مع وراثة متعددة يمكنك القيام به أيضا مع الميراث واحد. كنت مجرد استخدام خدعة وفد ذكرتها. وعلاوة على ذلك، لا تحتاج أي الميراث على الإطلاق، لأن أي شيء تفعله مع الميراث واحدة يمكنك أن تفعل أيضا دون الميراث عن طريق إعادة توجيه من خلال فئة. في الواقع، لا تحتاج أي الطبقات سواء، لأنك يمكن أن تفعل كل شيء مع مؤشرات وهياكل البيانات. ولكن لماذا تريد أن تفعل ذلك؟ متى ملاءمة لاستخدام مرافق اللغة؟ عندما تفضل حلا؟ رأيت الحالات التي يكون فيها وراثة متعددة هو مفيد، وحتى رأيت الحالات التي يكون فيها وراثة متعددة معقدة جدا مفيد. عموما، أنا أفضل أن استخدام التسهيلات التي تقدمها لغة إلى القيام الحلول

Answer 3

وليس هناك سبب لتجنب ذلك، ويمكن أن تكون مفيدة جدا في حالات. عليك أن تكون على بينة من المشاكل المحتملة بالرغم من ذلك.

وأكبر واحد يجري الماس الوفاة:

class GrandParent;
class Parent1 : public GrandParent;
class Parent2 : public GrandParent;
class Child : public Parent1, public Parent2;

لديك الآن اثنين "نسخ" من جد داخل الطفل.

لقد فكرت C ++ من هذا على الرغم من ويتيح لك القيام الإرث الظاهري للالتفاف حول هذه القضايا.

class GrandParent;
class Parent1 : public virtual GrandParent;
class Parent2 : public virtual GrandParent;
class Child : public Parent1, public Parent2;

ومراجعة دائما التصميم الخاص بك، تأكد من أنك لا تستخدم الميراث لانقاذ على إعادة استخدام البيانات. إذا كنت يمكن أن تمثل نفس الشيء مع تكوين (وعادة ما استطعت) هذا هو نهج أفضل بكثير.

Answer 4

انظر ث:الميراث المتعدد.

تلقى الميراث المتعدد انتقادات ، وعلى هذا النحو ، لم يتم تنفيذها في العديد من اللغات.الانتقادات تشمل:

• زيادة التعقيد
• غالبًا ما يتم تلخيص الغموض الدلالي على أنه مشكلة الماس.
• عدم القدرة على الوراثة بشكل صريح عدة مرات من فئة واحدة
• ترتيب الميراث تغيير دلالات الطبقة.

الميراث المتعدد في اللغات مع مُنشئات نمط C ++/Java يزيد من تفاقم مشكلة الميراث للمصممين وسلاسل المنشئ ، وبالتالي خلق مشاكل في الصيانة والتمديد في هذه اللغات.من الصعب تنفيذ الكائنات في علاقات الميراث مع طرق البناء المتغيرة إلى حد كبير في إطار نموذج التسلسل.

الطريقة الحديثة لحل هذه المشكلة هي استخدام الواجهة (فئة مجردة خالصة) مثل واجهة COM وJava.

يمكنني أن أفعل أشياء أخرى بدلا من هذا؟

نعم يمكنك ذلك.انا ذاهب للسرقة من GoF.

• البرنامج إلى واجهة، وليس تنفيذ
• تفضيل التركيب على الميراث

Answer 5

والميراث العام هو IS-A العلاقة، وأحيانا فئة سيكون نوع من عدة فئات مختلفة، وأحيانا أنه من المهم أن تعكس ذلك.

و"Mixins" هي أيضا مفيدة في بعض الأحيان. هم الفصول الصغيرة عموما، وعادة لا يرث من أي شيء، وتوفير وظائف مفيدة.

وطالما التسلسل الهرمي الميراث ضحلة نسبيا (كما ينبغي أن يكون دائما تقريبا)، وتدار بشكل جيد، كنت من غير المحتمل للحصول على الميراث الماس اللعين. الماس ليست مشكلة مع جميع اللغات التي تستخدم وراثة متعددة، ولكن العلاج C ++ الصورة من هو في كثير من الأحيان محرجا ومحير في بعض الأحيان.

وبينما كنت تعمل في الحالات التي يكون فيها وراثة متعددة مفيد جدا، وانهم فعلا نادرة إلى حد ما. وهذا هو الأرجح لأنني تفضل استخدام أساليب التصميم الأخرى عندما لا حاجة لي حقا وراثة متعددة. أنا لا يفضلون تجنب بنيات اللغة مربكة، وأنه من السهل لبناء قضايا الميراث حيث لديك لقراءة دليل جيد لمعرفة ما يجري.

Answer 6

ويجب أن لا "تجنب" وراثة متعددة ولكن يجب أن يكون على بينة من المشاكل التي يمكن أن تنشأ مثل "مشكلة الماس '(<لأ href =" http://en.wikipedia.org/wiki/Diamond_problem "يختلط = "noreferrer"> http://en.wikipedia.org/wiki/Diamond_problem ) وعلاج قوة نظرا للكم مع الرعاية، ويجب عليك مع كل القوى.

Answer 7

وكل لغة البرمجة لديها معاملة مختلفة قليلا من وجوه المنحى البرمجة مع إيجابيات وسلبيات. النسخة C ++ الصورة يضع التركيز بشكل مباشر على الأداء ولديه الجانب السلبي المصاحب أنه من السهل مقلق لكتابة التعليمات البرمجية غير صالحة - وهذا صحيح من وراثة متعددة. ونتيجة لذلك هناك اتجاها لتوجيه المبرمجين بعيدا عن هذه الميزة.

وقد تناولت

وأشخاص آخرين مسألة ما هو وراثة متعددة يست جيدة ل. لكننا رأينا عدد غير قليل من التعليقات التي أكثر أو أقل يعني أن السبب لتجنب ذلك لأنه ليست آمنة. حسنا، نعم ولا.

وكما هو في كثير من الأحيان صحيح في C ++، إذا كنت تتبع المبدأ التوجيهي الأساسي الذي يمكن استخدامه بأمان دون الحاجة إلى "نظرة على كتفك" باستمرار. الفكرة الأساسية هي أن نميز نوع خاص من تعريف فئة تسمى "مزيج في". الطبقة هي مزيج الدخول إذا كل وظائف الأعضاء فيها هي الظاهرية (أو نقية الظاهري). ثم يسمح لك أن ترث من فئة رئيسية واحدة والعديد من "mixins" كما يحلو لك - ولكن يجب أن ترث mixins مع الكلمة "افتراضية". منها مثلا.

class CounterMixin {
    int count;
public:
    CounterMixin() : count( 0 ) {}
    virtual ~CounterMixin() {}
    virtual void increment() { count += 1; }
    virtual int getCount() { return count; }
};

class Foo : public Bar, virtual public CounterMixin { ..... };

واقتراحي هو أنه إذا كنت تنوي استخدام فئة بأنها مزيج في درجة التي تعتمد أيضا على اصطلاح التسمية لجعل من السهل على أي شخص يقرأ رمز لمعرفة ما يحدث وللتحقق من كنت تلعب وفقا لقواعد المبدأ التوجيهي الأساسي. وستجد أنه يعمل بشكل أفضل بكثير إذا كانت لديك مزيج الإضافية المنشئات الافتراضية جدا، فقط بسبب الطريقة التي تعمل بها فئات أساسية افتراضية. وتذكر أن تجعل كل تالفة الظاهري للغاية.

لاحظ أن استخدامي لكلمة "خلط في" هنا ليس هو نفس فئة القالب parameterised (انظر <لأ href = "http://www.thinkbottomup.com.au/site/blog/C ٪ 20٪ 20_Mixins _-_ Reuse_through_inheritance_is_good "يختلط =" نوفولو "> هذا الرابط للحصول على تفسير جيد) ولكن اعتقد انه هو الاستخدام العادل للمصطلحات.

والآن أنا لا أريد أن أعطي انطباعا بأن هذه هي الطريقة الوحيدة لاستخدام وراثة متعددة بأمان. انها مجرد وسيلة واحدة التي هي سهلة نسبيا للتحقق.

Answer 8

على الرغم من مخاطر التجريد بعض الشيء، أجد أنه من المفيد التفكير في الميراث ضمن إطار نظرية الفئة.

إذا فكرنا في جميع فئاتنا والأسهم الموجودة بينها تشير إلى علاقات الميراث، فعندئذ شيء من هذا القبيل

A --> B

يعني أن class B مشتق من class A.لاحظ أنه نظرا

A --> B, B --> C

نقول أن C مشتق من B الذي يشتق من A، لذلك يقال أيضًا أن C مشتق من A، وبالتالي

A --> C

علاوة على ذلك، نقول ذلك لكل فئة A هذا تافه A مشتق من A, وبالتالي فإن نموذج الميراث الخاص بنا يفي بتعريف الفئة.في لغة أكثر تقليدية، لدينا فئة Class مع الأشياء جميع الفئات والتشكلات علاقات الميراث.

هذا قليل من الإعداد، ولكن مع ذلك دعونا نلقي نظرة على Diamond of Doom:

C --> D
^     ^
|     |
A --> B

إنه رسم تخطيطي مشبوه، لكنه سيفي بالغرض.لذا D يرث من كل A, B, ، و C.علاوة على ذلك، والاقتراب من معالجة سؤال OP، D يرث أيضًا من أي فئة فائقة A.يمكننا رسم رسم تخطيطي

C --> D --> R
^     ^
|     |
A --> B
^ 
|
Q

الآن، المشاكل المرتبطة بماس الموت هنا هي متى C و B مشاركة بعض أسماء الخصائص/الطرق وتصبح الأمور غامضة؛ومع ذلك، إذا قمنا بنقل أي سلوك مشترك إلى A ثم يختفي الغموض.

بعبارات قاطعة، نريد A, B و C ليكون مثل ذلك إذا B و C يرث من Q ثم A يمكن إعادة كتابتها كفئة فرعية من Q.هذا يجعل A شيء يسمى أ دفع للخارج.

هناك أيضًا بناء متماثل D يسمى ب اسحب للخلف.هذه هي الفئة الأكثر فائدة التي يمكنك إنشاؤها والتي ترث من كليهما B و C.هذا إذا كان لديك أي فئة أخرى R ضرب الميراث من B و C, ، ثم D هو فئة حيث R يمكن إعادة كتابتها كفئة فرعية من D.

إن التأكد من أن أطراف المعين الخاصة بك عبارة عن عمليات سحب وعمليات دفع يمنحنا طريقة رائعة للتعامل بشكل عام مع مشكلات تضارب الأسماء أو الصيانة التي قد تنشأ بطريقة أخرى.

ملحوظة بيرسيبال'س إجابة لقد ألهم هذا لأن تحذيراته مضمنة في النموذج أعلاه نظرًا لأننا نعمل في فئة كاملة من جميع الفئات الممكنة.

أردت تعميم حجته على شيء يوضح مدى تعقيد علاقات الميراث المتعددة التي يمكن أن تكون قوية وغير إشكالية.

ليرة تركية؛ د فكر في علاقات الميراث في برنامجك على أنها تشكل فئة.ثم يمكنك تجنب مشاكل Diamond of Doom عن طريق إجراء عمليات دفع للفئات الموروثة بشكل مضاعف، وإنشاء فئة رئيسية مشتركة وهي عملية انسحاب.

Answer 9

ونحن نستخدم ايفل. لدينا MI ممتازة. لا داعى للقلق. لا توجد مواضيع لا مواضيع. تمكن بسهولة. هناك أوقات لعدم استعمال MI. ومع ذلك، من المفيد أكثر مما يدرك الناس لأنها: أ) بلغة الخطيرة التي لا إدارتها -أو- جيدا B) راض عن الطريقة التي عملت حول MI لسنوات وسنوات -أو- C) أسباب أخرى ( أكثر من أن تحصى وأنا واثق تماما - راجع الإجابات أعلاه)

.

وبالنسبة لنا، وذلك باستخدام ايفل، MI غير طبيعي مثل أي شيء آخر، وأداة غرامة أخرى في صندوق الأدوات. بصراحة، نحن غير مهتمين كثيرا جدا أن لا أحد يستخدم ايفل. لا داعى للقلق. ونحن سعداء مع ما لدينا وندعوكم لإلقاء نظرة.

وبينما كنت أبحث: خذ علما خاصا الفراغ السلامة والقضاء على باطل المؤشر dereferencing. بينما نحن الرقص في جميع أنحاء MI، مؤشرات بك والتخبط! : -)

Answer 10

ويجب استخدامه بعناية، وهناك بعض الحالات، مثل الماس مشكلة ، عندما يمكن أن تسير الأمور تعقيدا.

<الفرعية> (المصدر: learncpp.com )

Answer 11

يستخدم والانتهاكات من الميراث.

وهذه المادة يقوم بعمل رائع لشرح الميراث، وانه من الأخطار.

Answer 12

وبعيدا عن نمط الماس، وراثة متعددة يميل إلى جعل طراز كائن من الصعب فهم، وهذا بدوره يزيد من تكاليف الصيانة.

والتركيب سهلة جوهريا لفهم، فهم، وشرح. فإنه يمكن الحصول على مملة لكتابة رمز ل، ولكن IDE جيد (انها كانت منذ سنوات قليلة لقد عملت مع Visual Studio، ولكن بالتأكيد ايديس جافا جميعا اختصار تكوين عظيم أدوات أتمتة) يجب أن تحصل على هذه العقبة.

وأيضا، من حيث الصيانة و"مشكلة الماس" تأتي في حالات الميراث غير حرفية كذلك. على سبيل المثال، إذا كان لديك ألف وباء والفئة C الخاص بك يمتد لهم على حد سواء، و A لديه طريقة "makeJuice" مما يجعل عصير البرتقال ويمكنك تمديد لدينا جعل عصير البرتقال مع لمسة من الجير: ماذا يحدث عندما المصمم ل" B 'ويضيف' طريقة makeJuice "الذي يولد والتيار الكهربائي؟ 'A' و 'B' قد تكون متوافقة "الوالدين" الآن ، ولكن هذا لا يعني أنها ستكون دائما هكذا!

وعموما، فإن مكسيم تميل إلى تجنب الميراث، وخصوصا راثة متعددة، سليم. وجميع ثوابتها، هناك استثناءات، ولكن كنت بحاجة للتأكد من أن هناك وامض النيون الأخضر مشيرا في الوقت ذاته أي استثناءات كنت رمز (وتدريب دماغك بحيث أي وقت ترى هذه الأشجار الميراث ترسمه في الخاص وامض النيون الأخضر الخاص بك التوقيع)، وأنك تحقق للتأكد من كل معنى كل مرة واحدة في كل حين.

Answer 13

والقضية الرئيسية مع MI من الأشياء الملموسة هي أنه نادرا ما لديك كائن شرعيا يجب "كن A ويكون B"، لذلك نادرا ما يكون الحل الصحيح لأسباب منطقية. أكثر في كثير من الأحيان، لديك كائن C أن يطيع "C يمكن أن تكون بمثابة A أو B"، والتي يمكن أن تحقق عن طريق واجهة الميراث والتكوين. ولكن تأكد من عدم الميراث mistake- من واجهات متعددة لا يزال MI، مجرد مجموعة فرعية من ذلك.

لC ++ على وجه الخصوص، وضعف أساسي من ميزة ليست الوجود الفعلي من الميراث متعددة، ولكن بعض يبني أنه يسمح التي هي دائما تقريبا تالف. على سبيل المثال، وراثة نسخ متعددة من نفس الكائن مثل:

class B : public A, public A {};

وتالف من حيث التعريف. ترجمت إلى اللغة الإنجليزية وهذا هو "B هو A وA". لذلك، حتى في لغة البشر هناك غموض شديد. هل تقصد "B ديه 2 باسم" أو مجرد "B هو A" ؟. السماح هذه المدونة المرضية، وأسوأ مما يجعلها نموذجا الاستخدام وفعل C ++ لا تفضل عندما يتعلق الأمر جعل قضية من أجل الحفاظ على الميزة في اللغات خليفة.

Answer 14

ويمكنك استخدام تركيبة وتفضيلها على الميراث.

والشعور العام هو أن التكوين هو أفضل، وانها تناقش بشكل جيد للغاية.

Answer 15

ويستغرق 4/8 بايت في الصف الواحد المعنية. (واحد هذا المؤشر في الصف الواحد).

وهذا قد لا يكون مصدر قلق، ولكن لو يوم واحد لديك بنية بيانات الصغير الذي وضح المليارات من الوقت الذي سيكون.