design patterns - فئات التسمية-كيفية تجنب استدعاء كل شيء "مدير<WhatEver>"؟




design-patterns oop (9)

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

على سبيل المثال ، إذا كان طلبي (باعتباره تطبيقًا تجاريًا نموذجيًا) يتعامل مع المستخدمين والشركات والعناوين ، فستكون لديّ فئة User Company وفئة Address - وربما في مكان ما ، UserManager و CompanyManager و AddressManager سوف يطفو على هذا المقبض هذه الأشياء.

هل يمكن أن تخبرنا ما يفعله UserManager و CompanyManager و AddressManager ؟ لا ، لأن المدير عبارة عن مصطلح عام جدًا يناسب أي شيء يمكنك القيام به مع كائنات المجال الخاصة بك.

أوصت المقالة قرأت باستخدام أسماء محددة للغاية. إذا كان تطبيق C ++ ووظيفة UserManager هي تخصيص وتحرير المستخدمين من كومة الذاكرة المؤقتة فإنه لن يقوم بإدارة المستخدمين ولكن حماية ولادتهم وموتهم. حسنًا ، ربما يمكننا تسمية هذا UserShepherd .

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

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

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

في نهاية المطاف ، أود أن أحصل على شيء مثل كتالوج النمط في ذهني (كثيرًا ما توفر أنماط التصميم أسماء الكائنات ، على سبيل المثال مصنعًا )

  • Factory - ينشئ كائنات أخرى (التسمية مأخوذة من نمط التصميم)
  • الراعي - يعالج الراعي عمر الأشياء وإبداعها وإغلاقها
  • المزامن - يقوم بنسخ البيانات بين كائنين أو أكثر (أو التسلسلات الهرمية للكائنات)
  • مربية (Nanny) - تساعد الكائنات على الوصول إلى حالة "قابلة للاستخدام" بعد الإنشاء - على سبيل المثال عن طريق توصيل الأسلاك بأشياء أخرى

  • الخ

لذا ، كيف تتعامل مع هذه القضية؟ هل لديك مفردات ثابتة ، هل تقوم باختلاق أسماء جديدة على الطاير أو هل تعتبر تسمية أشياء غير مهمة أو خاطئة؟

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

تحديث: ملخص الإجابات

فيما يلي ملخص بسيط لما تعلمته من هذا السؤال في هذه الأثناء.

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

مقالات / كتب أخرى حول هذا الموضوع:

وقائمة من البادئات / اللواحق التي قمت بجمعها (ذاتيًا!) من الإجابات:

  • منسق
  • باني
  • كاتب
  • قارئ
  • معالج
  • حاوية
  • بروتوكول
  • استهداف
  • محول
  • مراقب
  • رأي
  • مصنع
  • كيان
  • دلو

وتلميح جيد للطريق:

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


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

أنا نفسي كنت أستخدم نمط الواجهة كثيرًا (على الأقل ، أعتقد أن هذا هو ما يطلق عليه). يمكنني الحصول على فئة User تصف مستخدمًا واحدًا فقط ، وفئة Users تتعقب "مجموعة المستخدمين" الخاصة بي. أنا لا UserManager الفصل UserManager لأنني لا أحب المديرين في الحياة الحقيقية ولا أريد أن أذكرهم بهم :) ببساطة ، يساعد استخدام صيغة الجمع على فهم ما يفعله الفصل.


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

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


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

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

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


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


خاصة بـ C # ، وجدت "إرشادات تصميم الإطار: الاتفاقيات ، التعابير ، والأنماط للمكتبات القابلة لإعادة الاستخدام. NET" للحصول على الكثير من المعلومات الجيدة عن منطق التسمية.

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


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

على سبيل المثال ، يمكن تفسير UserRecordsClerk بشكل أفضل على أنه امتداد لواجهة RecordsClerk العامة التي يقوم كل من UserRecordsClerk و CompanyRecordsClerk بتطبيقها ثم تتخصص ، مما يعني أنه يمكن للمرء أن ينظر إلى الطرق في الواجهة لمعرفة ما تقوم به الفئات الفرعية الخاصة به بشكل عام.

شاهد كتابًا مثل Design Patterns for info ، إنه كتاب ممتاز وقد يساعدك على توضيح المكان الذي تريد الوصول إليه باستخدام الشفرة - إذا لم تكن تستخدمه بالفعل! ؛ س)

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


لقد طرحت سؤالاً مشابهاً ، ولكن كلما أمكن ، أحاول نسخ الأسماء الموجودة بالفعل في .NET framework ، وأبحث عن أفكار في إطارات Java و Android.

يبدو أن Helper و Manager و Util هي الأسماء التي لا يمكن تجنبها والتي يتم إرفاقها لتنسيق الفصول التي لا تحتوي على أية حالة وتكون إجرائية وثابتة بشكل عام. البديل هو Coordinator .

يمكنك الحصول على prosi الأرجواني بشكل خاص مع الأسماء وتذهب لأشياء مثل Minder ، Overseer ، Overseer ، Supervisor ، Master ، ولكن كما قلت أنا أفضل الاحتفاظ بها مثل أسماء الإطار التي تستخدمها.

بعض اللواحق الشائعة الأخرى (إذا كان هذا هو المصطلح الصحيح) تجد أيضًا في .NET framework:

  • Builder
  • Writer
  • Reader
  • Handler
  • Container

يبدو وكأنه منحدر زلق إلى شيء ما سوف يتم نشره على thedailywtf.com ، "ManagerOfPeopleWhoHaveMortgages" ، إلخ.

أفترض أنه من الصواب أن تكون فئة مدير واحدة متجانسة غير جيدة ، ولكن استخدام "مدير" ليس سيئًا. بدلاً من UserManager ، يمكننا تقسيمه إلى UserAccountManager و UserProfileManager و UserSecurityManager وما إلى ذلك.

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


يمكننا القيام به دون أي xxxFactory xxxManager أو xxxRepository أو xxxRepository إذا قمنا بتصميم العالم الحقيقي بشكل صحيح:

Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
        .Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
        .OfType<User>().CreateNew("John Doe");

؛-)







naming