هل هي فكرة سيئة الكشف عن التسلسل الهرمي للميراث في بنية مساحة الاسم؟

Question

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

على سبيل المثال، خذ بعين الاعتبار مساحات الأسماء والفئات التالية:

namespace Protocol
{
  public abstract class Message { }
  public abstract class Driver { }
}
namespace Protocol.Tcp
{
  public class TcpMessage : Message { }
  public class TcpDriver : Driver { }
}
namespace Protocol.Ftp
{
  public class FtpMessage : Message { }
  public class FtpDriver : Driver { }
}

ما هي أفضل طريقة لتنظيم مساحات الأسماء؟يبدو أنه لا مفر من كشف الميراث في مساحة الاسم نظرًا لأن الفئات الأساسية لا تنتمي حقًا إلى مساحة الاسم Protocol.Tcp أو مساحة الاسم Protocol.Ftp.

Answer 1

أعتقد أنك ربما تقلق أكثر من اللازم!

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

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

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

ما لديك يبدو منطقيا :)

يحرر:

كمثال:

using System.Data;
using System.Data.Sql;

;)

Answer 2

توضح العلامات الأصلية أن هذا المنشور يدور حول C# - وبالتالي فإن الوراثة المتعددة غير ذات صلة - لا يمكنك مضاعفة الوراثة في C#.

ربما يجب أن تفكر في تحديد بعض الواجهات التي تحدد ماهية العقود الأساسية لـ Message و أ Driver هي ومن ثم قد تشعر بالحرية قليلاً في استخدام بنية مساحة الاسم لتقليد الاختلافات التقنية.

Answer 3

لو كان هذا أنا، فسأحدد مجالين للاسم:

Protocol

و

Protocol.Driver

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