يستحق استخدام getters و etters في DTOs؟ (C ++)

Question

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

عندما رأيت DTOs ، غالبًا ما يكون لديهم Getters و Petters ، ولكن هل أي نقطة لهذه الأنواع من الفصل؟ لم أتساءل عما إذا كنت سأضع التحقق من الصحة أو أجريت حسابات في الأساليب ، لكنني ربما أفكر في أن هذا لا يبدو أنه يتجاوز نطاق هدفهم.

في نهاية الخادم ، تتعامل طبقة العمل مع المنطق ، وفي العميل ، سيتم استخدام DTOs في العرض (وإرسال البيانات إلى الخادم).

على افتراض أنني سأذهب إلى كل هذا بشكل صحيح ، ما الذي يفكر فيه الناس؟

شكرًا!

تعديل: وإذا كان الأمر كذلك ، فهل سيكون أي مشكلة في وضع تنفيذ GET / SET في تعريف الفصل؟ يحفظ تكرار كل شيء في ملف CPP ...

Answer 1

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

Answer 2

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

إذا كانت البيانات مجرد كائن من البيانات القديمة (POD) لحمل البيانات ، فهذا مرشح لكونه بنية (فئة عامة كاملة).

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

في أي حال ، في أي لغة ، فإن getter/setter هو علامة على ضعف التغليف. ليس من OOP أن يكون لديك getter/setter لكل حقول مثيل. يجب أن تكون الكائنات غنية ، وليس فقر الدم. إذا كنت تريد حقًا كائنًا فقرًا ، فاختر getter/setter وانتقل مباشرة إلى بنية Pod Pull-Public ؛ لا توجد فائدة تقريبًا لاستخدام Getter/Setter على بنية عامة كاملة ، باستثناء أنه يعقد الكود ، لذلك قد يمنحك تصنيفًا أعلى إذا كان مكان عملك يستخدم خطوط الكود كمقياس للإنتاجية.