ترحيل رمز C ++ من الهياكل إلى الفئات

Question

أقوم بترحيل بعض رمز C ++ من الهياكل إلى الفئات.

كنت أستخدم الهياكل بشكل أساسي لتحسينات حقل البتات التي لم أعد بحاجة إليها (أشعر بالقلق أكثر من السرعة من توفير المساحة الآن).

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

Answer 1

لا أستطيع الاسم الكل الأشياء الأساسية ، لكن يمكنني تسمية واحدة: التغليف.

الفرق الفني الوحيد في C ++ بين الهيكل والفئة هو الوصول الافتراضي. في البنية ، كل شيء عام افتراضيًا ؛ في الفصل ، كل شيء خاص. أفترض أنك تتحدث عن هياكل POD هنا ، حيث يكون كل شيء عامًا.

ما سأفعله هو:

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

Answer 2

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

لا تقل ما يكفي عن أهدافك ، لذلك ربما يكون هذا هو هدفك ، ولكن إذا كنت تحاول فقط التحويل إلى C ++ بحيث يمكن أن يكون الرمز الجديد في تطبيقك C ++ ، فقط إعادة تسمية الملفات ، وإضافة مجموعة من الممثلين حيث كانت التحويلات الضمنية من void* تحدث من قبل ، والمضي قدمًا في حياتك.

Answer 3

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

Answer 4

أولاً, ، سوف أنضم إلى الآخرين وأقول إن نقل جميع الكود من الهياكل إلى الفصول قد لا يكون أفضل خطوة. إذا كنت تريد أن تفعل ذلك بشكل جيد (أي أكثر من مجرد تغيير struct X { مع class X { public:) وهذا يعني إعادة تصميم التطبيق (أكثر أو أقل إعادة كتابة كاملة).

يتضمن ذلك تقديم أخطاء جديدة ودورات تطوير جديدة واختبار إضافي وتغيير الوثائق وما إلى ذلك.

ثانيا, ، بالنظر إلى أنه قد يكون لديك أسباب وجيهة للقيام بذلك (بالنسبة لي "من أجل المتعة" و "لمعرفة ما إذا كان بإمكاني القيام بذلك" يمكن أن تكون أسبابًا وثيقة في بعض المواقف: D) إليك إجاباتي على أسئلتك:

1. What are the general guidelines for doing this migration?
2. What are all the essential things I should keep in mind?

إرشادات وأشياء يجب وضعها في الاعتبار:

• العمل في تكرارات صغيرة جدا, ، وتأكد من أن التطبيق وظيفي بين التكرارات. إذا كان لديك اختبارات وحدة محددة ، فيمكنك العمل من خلالها (اختر وحدة واحدة ، وإعادة تصميم بعد مجموعة من الخطوات (انظر أدناه) ، ثم تكييف وتشغيل الاختبارات.

• اختر منطقة واحدة من الكود الخاص بك وإنهائها.

• حاول اتباع هذه الخطوات لكل تغيير:

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

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

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

مزايا منهجية إعادة البناء:

• يبقى التطبيق وظيفيًا إذا قررت في منتصف الطريق من خلال أن الجهد لا يستحق كل هذا العناء (أو إذا قررت الإدارة أن الجهد لا يستحق ذلك)

• يظل استقرار التطبيق قابلاً للإدارة من خلال التغييرات

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

حظا طيبا وفقك الله!