الفئات مقابل البنى: دليل المطور للأداء

الملخص: اكتشف الفروقات الأساسية بين الفئات والبنى. تعلّم متى تستخدم كل منهما لكتابة كود نظيف عالي الأداء في C#، Swift، C++، والمزيد.

المقدمة

الفارق الأساسي بين الفئات (classes) والبنى (structs) بسيط لكنه حاسم: الفئات هي أنواع مرجعية والبنى هي أنواع قيمة. هذا التمييز يؤثر في تخطيط الذاكرة، وسلوك النسخ، وأداء وقت التشغيل عبر لغات مثل C# وC++ وSwift. فهم متى تختار أحدهما بدلاً من الآخر أمر أساسي لكتابة كود متوقع وأنظمة عالية الأداء.

فهم الاختلاف الأساسي

عندما تُنشئ مثيلاً لفئة، المتغير الذي تحتفظ به هو مرجع يشير إلى الكائن على الكومة. نسخ هذا المتغير ينسخ المرجع؛ يمكن لمرجعَين متعددين أن يشيرا إلى نفس الكائن، لذا التغييرات عبر أحد المراجع تظهر عبر الآخرين. هذه الدلالات المرجعية هي سبب رئيسي لاستخدام الفئات للكيانات ذات الهوية.¹

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

لمزيد حول التغليف وتصميم الكائنات، انظر دليلنا عن التغليف في البرمجة الشيئية: https://cleancodeguy.com/blog/object-oriented-encapsulation.

مقارنة سريعة: أنواع مرجعية مقابل أنواع قيمة

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

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

كيف يؤثر تخصيص الذاكرة على السرعة

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

تكاليف جمع القمامة

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

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

هذا مهم بشكل خاص في الأنظمة المصممة للتوسع والاستجابة—تقليل التخصيصات يقلل مباشرة نشاط جمع القمامة ويمكن أن يُنعِم أداء وقت التشغيل.

محلية الكاش والإنتاجية

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

فخ التغليف (Boxing)

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

كيف تختلف اللغات: C#، C++، وSwift

تفرض اللغات المختلفة أعرافًا وقدرات مختلفة. معرفة قواعد كل لغة تمنع تطبيق قواعد لغة واحدة بعمياء على الأخرى.

C#: نموذج واضح لأنواع مرجعية مقابل قيمة

في C#، الفئة = نوع مرجعي والبنية = نوع قيمة. استخدم الفئات للكيانات ذات الهوية (مثلاً، Customer أو DatabaseConnection) والبنى للقيم الصغيرة وغير المتغيرة (مثلاً، Point، Color). الحفاظ على البنى صغيرة وغير قابلة للتغيير يتجنب أخطاء دقيقة وتكاليف نسخ.

الأخطاء الشائعة تشمل جعل البنى كبيرة أو قابلة للتغيير؛ كلاهما يؤدي إلى أخطاء مفاجئة أو تراجع في الأداء. اتبع إرشاد البنى غير القابلة للتغيير والصغيرة عند التحسين في C#.

C++: العرف بدل التقييد اللغوي

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

هذه المرونة تعني أن مطوري C++ يجب أن يعتمدوا على الأعراف وخيارات التصميم بدلاً من تمييزات صريحة في اللغة بين القيمة والمرجع. للمزيد عن الأنماط المتعلقة بالتعددية والوراثة، انظر ملاحظات تصميم C++ لدينا: https://cleancodeguy.com/blog/polymorphism-vs-inheritance.

Swift: التوجّه نحو القيمة بشكل افتراضي

تشجع Swift تفضيل البنى لمعظم الأنواع المخصصة. تدعم البنى في Swift الطرق والامتدادات والالتزام بالبرتوكولات، مما يجعلها قوية ومع ذلك افتراضًا آمنًا. اختر الفئات فقط عندما تكون الدلالات المرجعية أو الهوية أو التوافق مع Objective-C مطلوبة.²

هذا التصميم الذي يفضل القيمة يشجع على عدم القابلية للتغيير وسهولة التفكير في تدفق البيانات، خصوصًا في الكود المتزامن.

متى تختار بنية لأقصى كفاءة

البنى مثالية لحزم بيانات صغيرة وغير قابلة للتغيير تُعرّف هويتها بالكامل بقِيَمها. أمثلة شائعة:

• بيانات هندسية: Point2D أو RGBColor
• قيم مالية: Money (المبلغ + العملة)
• DTOs الصغيرة المستخدمة في أنابيب عالية الإنتاجية

قاعدة عملية للحجم هي قاعدة “16–32 بايت”: إذا كانت حقول البنية تناسب تقريبًا هذا النطاق، فإن تكلفة النسخ معتدلة وغالبًا أرخص من تخصيص الكومة. إذا أصبحت البنية أكبر أو يجب أن تكون قابلة للتغيير، فغالبًا ما تكون الفئة الخيار الأفضل.⁵

قواعد الحجم وعدم القابلية للتغيير

• فضّل البنى غير القابلة للتغيير: يجب إنشاء القيم مرة واحدة واستبدالها بدلاً من تعديلها.
• احفظ البنى صغيرة: نسخ البنى الكبيرة بشكل متكرر قد يصبح أكثر تكلفة من تمرير المراجع.

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

الأخطار الشائعة وإعادة الصياغة

مشكلتان شائعتان هما البنى القابلة للتغيير والتغليف المفرط.

البنى القابلة للتغيير تؤدي إلى سلوك مفاجئ لأن التعديلات تؤثر على نسخة فقط. أعد صياغة البنى القابلة للتغيير إلى بنى غير قابلة للتغيير تُرجع مثيلات جديدة لتغييرات الحالة.

يحدث التغليف ضمنيًا في العديد من واجهات برمجة التطبيقات والمجموعات؛ حدّد مواقع التغليف وأزلها للحفاظ على مزايا أداء البنى.

مثال: إعادة صياغة نقطة قابلة للتعديل إلى بنية غير قابلة للتغيير (C#)

// PITFALL: Mutable struct public struct MutablePoint { public int X { get; set; } public int Y { get; set; }

public void Move(int dx, int dy)
{
    X += dx;
    Y += dy;
}

}

// REFACTOR: Immutable struct public readonly struct ImmutablePoint { public int X { get; } public int Y { get; }

public ImmutablePoint(int x, int y)
{
    X = x;
    Y = y;
}

public ImmutablePoint MovedBy(int dx, int dy)
{
    return new ImmutablePoint(X + dx, Y + dy);
}

}

هذه إعادة الصياغة تجعل النية صريحة وتلغي الفساد العرضي للحالة. للمزيد من ممارسات الكود النظيف، انظر دليل مبادئنا: https://cleancodeguy.com/blog/clean-coding-principles.

الأسئلة الشائعة (سؤال وجواب مختصر)

س1: متى أفضل استخدام بنية بدل فئة؟

ج: فضّل البنية عندما يكون النوع صغيرًا وغير قابل للتغيير ويمثل قيمة بدلًا من هوية. تتألق البنى للبيانات البسيطة مثل النقاط والألوان أو DTOs الصغيرة.

س2: ما فخاخ الأداء التي يجب أن أنتبه لها؟

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

س3: كيف تؤثر اختلافات اللغة على اختياري؟

ج: اتبع أعراف اللغة: C# تفرض القيمة مقابل المرجع؛ C++ تستخدم الأعراف؛ Swift تفضّل أنواع القيمة افتراضيًا. تعلّم قواعد المنصة قبل تطبيق أنماط عبر لغات.¹²

في Clean Code Guy، نساعد الفرق على تطبيق هذه المبادئ على قواعد الشيفرة الحقيقية. عمليات تنظيف قواعد الشيفرة وإعادة التأهيل الجاهزة للذكاء الاصطناعي تجعل البرامج أسرع وأكثر أمانًا وأسهل في الصيانة. زر https://cleancode.com لمعرفة المزيد.