كيف تشرح لشخص ما أن بنية البيانات يجب ألا ترسم نفسها ، وشرح فصل المخاوف؟

Question

لديّ مبرمج آخر أحاول شرح سبب عدم وجود مكون واجهة المستخدم أيضًا.

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

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

وبالتالي وفقًا لهذا المنطق ، يجب على مجموعة السجلات إدارة رسم واجهة المستخدم.

****** مكتب الرأس *****

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

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

هل هناك أي نصيحة أخرى يمكنني إرسال طريقه بخلاف المثال أعلاه؟ أتفهم أنه عندما تتعلم أولاً ، تمر بـ "مرحلة" حيث تريد فقط تمديد كل شيء.

تليها مرحلة عندما تعتقد أن أنماط التصميم هي الحل كل مشكلة واحدة ... وهي غير صحيحة تمامًا أيضًا ...شكرا جيف.

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

Answer 1

هل سمعت عن مارتن فاولر؟

فصل رمز واجهة المستخدم

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

Answer 2

هذا يتلخص في المسؤوليات الوظيفية مقابل غير وظيفية. ما يفعله هيكل البيانات وكيف يتم تصوره هما شيئان منفصلان تمامًا - في الأساس جذر نمط MVC.

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

Answer 3

بشكل عام على نقطة الفصل:

1. ليس فقط يمكن أن يكون هناك مكونات مختلفة من واجهة المستخدم مما يجعل هيكل البيانات نفسه. قد يكون لديك حتى واجهة مستخدم مختلفة تمامًا (الويب ، تطبيق سطح المكتب ، ...) الآن بالطبع ، يمكنك فئة فرعية Person مع WebPerson و DesktopPerson (هذا يبدو خطأ بالفعل ، أليس كذلك؟ التسمية لا تدور حول نوع الشخص - إنه يتعلق بشيء آخر).

2. يمكن لكل واجهة مستخدم العمل على أنواع مختلفة من الأشخاص ، على سبيل المثال Teacher و Student. لذلك نحصل WebPerson, WebTeacher, WebStudent, DesktopPerson, DesktopTeacher و DesktopStudent.

الآن دعنا نقول ، WebPerson يحدد طريقة "DrawAddressFields ()" لرسم إصدار ويب من حقول العناوين. لكن منذ WebTeacher يجب أن تستمد من Teacher لاستخدام حقل البيانات الإضافي "راتب" (ودعنا نفترض ميراثًا واحدًا) ، يجب أن ينفذ "DrawAddressFields ()" مرة أخرى!

لذلك ربما تساعد حجة "هذا سيؤدي إلى مزيد من العمل" على خلق بعض الدافع :-)

راجع للشغل ، سيؤدي ذلك تلقائيًا إلى إنشاء بعض المندوبين الذي يقوم بتنفيذ رمز DrawAddressField () ، والذي سيتطور بعد ذلك إلى إنشاء مكون يقوم بالرسم بشكل منفصل عن بنية البيانات.