إذا كانت مشغلات قاعدة البيانات شريرة ، فهل من الشر أن يكون لديك آثار جانبية عند تعيين خاصية في Java أو C#؟

Question

لنفترض أن [مشغلات قاعدة البيانات هي شريرة].1

هل هذا يعني أن الآثار الجانبية عند تعيين خاصية على كائن Java أو C# هي أيضًا شريرة؟

يبدو لي أن كل المشاكل نفسها موجودة.

Answer 1

الذهاب ضد الحبوب هنا ...

لا ينبغي أن تؤدي الخصائص إلى آثار جانبية. هذه هي الطريقة التي هي.

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

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

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

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

Answer 2

ليس بالضرورة ، لا. اذا كان لديك Price أو Amount الخاصية ، وأنت تغير ذلك ، يبدو أن Cost يجب أن يتغير وفقًا لذلك؟

أم أن هناك شيئًا مختلفًا كنت تفكر في هذا المنشور؟

Answer 3

لا ، يمكن للعديد من الخصائص وينبغي أن تؤدي إلى آثار جانبية.

على سبيل المثال: تخيل عنصرين بصريين حيث يوجد طفل داخل أحد الوالدين. تعيين Parent.Visible = false يجب أن يعين أيضًا child.visible = false.

في كثير من الأحيان يتم صنع هذه الآثار الجانبية من خلال حدث ما (system.windows.forms مليئة بالأحداث التي تم تنسيقها) أو واجهة (مثل inotifyPropertyChanged).

Answer 4

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

هذا واحد من عدد من القضايا التي تنشأ:

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

في النهاية ، أعتقد أن النقطتين أعلاه لا يهمان طالما تم توثيق أي آثار جانبية أو عمليات مكلفة محتملة ، لأن الشيء نفسه يجب أن ينطبق على الأساليب أيضًا.

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

في بعض الأحيان أعتقد أن الخصائص تسبب مشاكل أكثر مما تحل.

Answer 5

هذا يعتمد على. من المؤكد أن هناك آثارًا جانبية ، والتي ستأخذ المستخدم على حين غرة ومن الأفضل تجنب تلك المنظمة الدولية للمنية.

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

Answer 6

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

هذا يجعل من السهل جدًا أن ننسى الأمر الذي يجعلها بدورها يصعب تصحيحها.

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

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