دليل أنماط C ++ من Google. الجزء الرابع

الجزء 1. مقدمة

...

الجزء 4. الفئات

...





هذه المقالة هي ترجمة لجزء من دليل أسلوب Google C ++ إلى اللغة الروسية.

المقالة الأصلية (fork on github) ، الترجمة المحدثة .

الطبقات

الفصول هي لبنة البناء الرئيسية في C ++. وبالطبع يتم استخدامها غالبًا. يصف هذا القسم القواعد الأساسية والمحظورات التي يجب اتباعها عند استخدام الفئات.

كود في المنشئ

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



التعريف



بشكل عام ، يمكن إجراء أي تهيئة في المُنشئ (أي يمكن إجراء جميع التهيئة في المُنشئ).



لكل

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

ضد

• إذا تم استدعاء الوظائف الافتراضية في المُنشئ ، فلن يتم استدعاء عمليات التنفيذ من الفئة المشتقة. حتى لو لم يكن للفصل الآن أحفاد ، فقد يصبح هذا مشكلة في المستقبل.
• ( ) ( ).
• , ( — ) . : bool IsValid(). .
• . , , .

يجب ألا يستدعي صانعو الحكم وظائف افتراضية. في بعض الحالات (إذا كان مسموحًا بذلك) ، يمكن معالجة أخطاء التصميم من خلال إنهاء البرنامج. بخلاف ذلك ، ضع في اعتبارك نمط Factory Method أو استخدم Init () (مزيد من التفاصيل هنا: TotW # 42 ). استخدم Init () فقط إذا كان للكائن علامات حالة تسمح باستدعاء وظائف عامة معينة (نظرًا لأنه من الصعب العمل بشكل كامل مع كائن تم إنشاؤه جزئيًا).

التحويلات الضمنية

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



التعريف



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



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



الكلمة الأساسية الصريحة على مُنشئ أو عامل تحويل للإشارة صراحة إلى أنه لا يمكن استخدام الوظيفة إلا عندما يكون هناك تطابق صريح من النوع (على سبيل المثال ، بعد عملية cast). هذا لا ينطبق فقط على التحويلات الضمنية ، ولكن أيضًا على قوائم التهيئة في C ++ 11:

class Foo {
  explicit Foo(int x, double y);
  ...
};
void Func(Foo f);

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Func({42, 3.14});  // 

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

هذا المثال من الكود ليس تحويلًا ضمنيًا من الناحية الفنية ، لكن اللغة تعامله كما لو كان من المفترض أن يكون صريحًا .



لكل

• , .
• , string_view std::string const char*.
• .

• , ( ).
• , : , .
• , .
• explicit : , .
• , . — , .
• , , , .

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



يمكن التصريح عن المنشئات التي لا يمكن استدعاؤها باستخدام وسيطة واحدة بدون صريح . يقبل المُنشئون قائمة الأمراض المنقولة جنسياً: :: initializer_listيجب أيضًا التصريح عنها بدون صريح لدعم تهيئة النسخ (على سبيل المثال ، MyType m = {1، 2}؛ ).

أنواع قابلة للنسخ وقابلة للنقل

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



التعريف



النوع القابل للنقل هو النوع الذي يمكن تهيئته أو تعيينه من قيم مؤقتة.



النوع القابل للنسخ - يمكن تهيئته أو تعيينه من كائن آخر من نفس النوع (على سبيل المثال ، نفس الكائن القابل للنقل) ، بشرط أن يظل الكائن الأصلي بدون تغيير. على سبيل المثال ، std :: unique_ptr <int> قابلة لإعادة تحديد موضعها ، لكن لا النوع المراد نسخه (لأن قيمة الكائن الأصلي std :: unique_ptr <int> يجب أن تتغير عند تعيينه إلى الهدف). intو std :: string هي أمثلة على الأنواع القابلة لإعادة التوطين التي يمكن نسخها أيضًا: بالنسبة إلى عمليات النقل والنسخ int هي نفسها ، بالنسبة إلى std :: string ، تتطلب عملية النقل موارد أقل من النسخ.



بالنسبة للأنواع المعرفة من قبل المستخدم ، يتم تحديد النسخ بواسطة مُنشئ النسخ وعامل النسخ. يتم تحديد الحركة إما بواسطة مُنشئ النقل مع مشغل النقل ، أو (إذا لم يكن موجودًا) بواسطة وظائف النسخ المقابلة.



يمكن للمترجم استدعاء مُنشئات النسخ والتحريك ضمنيًا ، على سبيل المثال ، عند تمرير الكائنات بالقيمة.



لكل



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



عادةً ما يكون تعريف مُنشئ النسخ / النقل وعوامل التخصيص المرتبطة به أسهل من تحديد البدائل مثل Clone () أو CopyFrom () أو Swap () لأن يمكن للمترجم إنشاء الوظائف المطلوبة (ضمنيًا أو مع = افتراضي ). من السهل إعلانها (الوظائف) ويمكنك التأكد من نسخ جميع أعضاء الفصل. عادة ما يكون المنشئون (نسخ ونقل) أكثر كفاءة لأن لا تتطلب تخصيص الذاكرة ، التهيئة المنفصلة ، التخصيصات الإضافية ، تم تحسينها جيدًا (انظر حذف النسخة ).



تسمح لك عوامل النقل بمعالجة موارد الكائنات بكفاءة (وبشكل ضمني). هذا يجعل الترميز أسهل في بعض الأحيان.



ضد



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



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



الحكم



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



على وجه الخصوص ، يجب أن تعلن الفئة المنسوخة صراحةً عن عمليات النسخ ؛ فقط فئة قابلة للنقل يجب أن تعلن صراحة عن عمليات النقل ؛ يجب أن ترفض فئة غير قابلة للنسخ / غير قابلة للنقل ( = حذف ) عمليات النسخ بشكل صريح . من المقبول أيضًا الإعلان صراحة عن وظائف النسخ والنقل الأربعة أو إزالتها ، على الرغم من أنها غير مطلوبة. إذا قمت بتنفيذ النسخة و / أو عامل النقل ، فيجب عليك أيضًا إنشاء المُنشئ المقابل.

class Copyable {
 public:
  Copyable(const Copyable& other) = default;
  Copyable& operator=(const Copyable& other) = default;
  //       (..  )
};
class MoveOnly {
 public:
  MoveOnly(MoveOnly&& other);
  MoveOnly& operator=(MoveOnly&& other);
  //     .  ( )    :
  MoveOnly(const MoveOnly&) = delete;
  MoveOnly& operator=(const MoveOnly&) = delete;
};
class NotCopyableOrMovable {
 public:
  //       
  NotCopyableOrMovable(const NotCopyableOrMovable&) = delete;
  NotCopyableOrMovable& operator=(const NotCopyableOrMovable&)
      = delete;
  //     (),    :
  NotCopyableOrMovable(NotCopyableOrMovable&&) = delete;
  NotCopyableOrMovable& operator=(NotCopyableOrMovable&&)
      = delete;
};

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

يمكن حذف إعلانات الوظائف الموصوفة أو عمليات الحذف في الحالات الواضحة:

• إذا كان الفصل لا يحتوي على قسم خاص (على سبيل المثال ، بنية أو فئة واجهة) ، فيمكن عندئذٍ الإعلان عن قابلية النسخ وإعادة التوطين من خلال خاصية مماثلة لأي عضو عام.
• , . , , .
• , () /, / (.. ). / . .

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



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

الهياكل مقابل الطبقات

استخدام الهياكل ( البنية ) فقط لالسلبي الكائنات التي تخزين البيانات. في حالات أخرى ، استخدم الفئات ( الفصل ).



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



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



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



في بعض الحالات ( الدوال الوصفية للقالب ، والسمات ، وبعض الدوال ) من أجل الاتساق مع STL ، يُسمح باستخدام الهياكل بدلاً من الفئات.



تذكر أن المتغيرات في الهياكل والفئات يتم تسميتها بأساليب مختلفة.

الهياكل مقابل الأزواج والمجموعات

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



أثناء استخدام أزواج والصفوف يتجنب إعادة اختراع العجلة مع نوع الخاصة بك وسوف يوفر لك الكثير من الوقت في كتابة كود والحقول مع أسماء ذات مغزى (بدلا من . أولا ، .second، أو الأمراض المنقولة جنسيا :: الحصول على <X> ) سوف يكون من الأسهل لل قراءة عند قراءة التعليمات البرمجية. وعلى الرغم من أن C ++ 14 تضيف وصولاً من النوع ( std :: get <Type> ، ويجب أن يكون النوع فريدًا) بالإضافة إلى فهرس الوصول إلى tuples ، فإن اسم الحقل أكثر إفادة من النوع.



تتناسب الأزواج والبطاقات في الكود حيث لا يوجد تمييز خاص بين عناصر الزوج أو المجموعة. كما أنهم مطالبون بالعمل مع الكود الموجود أو واجهات برمجة التطبيقات.

ميراث

غالبًا ما يكون تكوين الطبقة أكثر ملاءمة من الميراث. عند استخدام الميراث ، اجعلها عامة .



التعريف



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



لكل



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



السلبيات



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



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



الحكم



يجب أن تكون الميراث علنية . إذا كنت تريد أن تجعله خاصًا ، فمن الأفضل إضافة عضو جديد بنسخة من الفئة الأساسية.



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



المحمية ( المحمية ) تفعل فقط تلك الوظائف التي يجب أن تكون متاحة للفئات الفرعية. لاحظ أن البيانات يجب أن تكون خاصة.



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



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

زيادة الحمولة على المشغل

المشغلين الزائد بشكل معقول قدر الإمكان. لا تستخدم القيم الحرفية المخصصة. يسمح



تحديد



رمز C ++ للمستخدم بتجاوز عوامل التشغيل المضمنة باستخدام عامل تشغيل الكلمة الأساسية ونوع المستخدم كأحد المعلمات ؛ يسمح لك عامل التشغيل أيضًا بتعريف القيم الحرفية الجديدة باستخدام عامل التشغيل "" ؛ يمكنك أيضًا إنشاء وظائف الصب مثل عامل التشغيل bool () .



لكل



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



تعد القيم الحرفية المخصصة طريقة فعالة جدًا لإنشاء كائنات مخصصة.



ضد

• (, ) — , , .
• , .
• , , .
• , , .
• , .
• / ( ), «» . , foo < bar &foo < &bar; .
• . & , . &&, || , () ( ) .
• , . , .
• (UDL) , C++ . : «Hello World»sv std::string_view(«Hello World»). , .
• لان لم يتم تحديد مساحة اسم لـ UDL ، فستحتاج إما إلى استخدام توجيه استخدام (وهو أمر محظور ) أو تصريح استخدام (وهو محظور أيضًا (في ملفات الرأس) ، ما لم تكن الأسماء المستوردة جزءًا من الواجهة المعروضة في ملف الرأس). بالنسبة لملفات الرأس هذه ، من الأفضل تجنب لواحق UDL ، ومن المستحسن تجنب التبعيات بين العناصر الحرفية المختلفة في ملف الرأس والمصدر.

الحكم



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



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



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



لا حاجة لمحاولة تجاوز تجاوزات المشغل. إذا كانت المقارنة (أو وظيفة التعيين والإخراج) مطلوبة ، فمن الأفضل تحديد == (أو = و << ) بدلاً من Equals () و CopyFrom () و PrintTo () . على العكس من ذلك ، لا تحتاج إلى إعادة تعريف عامل فقط لأن المكتبات الخارجية تتوقع ذلك. على سبيل المثال ، إذا كان لا يمكن ترتيب نوع البيانات وتريد تخزينه في std :: set ، فمن الأفضل عمل وظيفة مقارنة مخصصة وعدم استخدام عامل التشغيل < .



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



معلومات إضافية:

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

الوصول إلى أعضاء الفصل

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



يجوز الإعلان عن بيانات الفئة على أنها محمية لاستخدامها في فئات الاختبار (على سبيل المثال ، عند استخدام اختبار Google ) أو حالات أخرى مماثلة.

إجراء الإعلان

ضع إعلانات متشابهة في مكان واحد ، واعرض الأجزاء المشتركة.



تعريف الفئة عادة ما تبدأ مع قسم من الجمهور: ، يذهب مزيد من الحماية: ثم وخاصة: . لا تحدد الأقسام الفارغة.



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



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