ترث من فئة أو فئة مجردة

Question

إذا كان لديك عدة فئات تريد أن ترثها من فئة أساسية للوظائف المشتركة، فهل يجب عليك تنفيذ الفئة الأساسية باستخدام فئة أو فئة مجردة؟

Answer 1

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

Answer 2

إذا الفئة الأساسية لا يجب ان يكون مثيل ثم جعله فئة مجردة - إذا الفئة الأساسية تحتاج إلى إنشاء مثيل ثم لا تجعل مجردة

في هذا المثال فإنه من المنطقي أن جعل المجرد الفئة الأساسية كما لايوجد الفئة الأساسية أي معنى ملموس:

abstract class WritingImplement
{
    public abstract void Write();
}

class Pencil : WritingImplement
{
    public override void Write() { }
}

ولكن في هذا المثال التالي يمكنك أن ترى كيف يكون الفئة الأساسية معنى ملموسا:

class Dog
{
    public virtual void Bark() { }
}

class GoldenRetriever : Dog
{
    public override void Bark() { }
}

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

Answer 3

وهذا يعتمد، أنه لا معنى للفئة الأساسية في مسألة الوجود على نفسه دون أن تستمد من؟ إذا كان الجواب نعم، ثم يجب أن تكون الطبقة العادية، وإلا، فإنه يجب أن تكون فئة مجردة.

Answer 4

أقترح:

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

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

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

الآن، إذا كان إنشاء مثيل للفئة الأساسية سيكون خطيرًا بطريقة أو بأخرى، فاجعلها مجردة - أو يفضل أن تجعلها أقل خطورة، إن أمكن؛-)

Answer 5

وأعتقد أنه من مثل حساب مصرفي:

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

وبعد ذلك يمكنك إنشاء اثنين من الفئات المشتقة يسمى "SavingAccount" أو "DebitAccount" التي يمكن أن يكون لها سلوك معين الخاصة بهم مع الاستفادة من سلوك الفئة الأساسية.

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

إذا يمكنك إنشاء سيناريو مماثل لاحتياجاتك، مجردة هو الطريق للذهاب.

Answer 6

والطبقات الخلاصة هي لفئات نفذت جزئيا.

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

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

Answer 7

والتفكير في هذا بطريقة مختلفة

<اقتباس فقرة>   

هل لي فئة أساسية كائن كامل على نفسه؟

إذا كان الجواب بالنفي، ثم جعله مجردة. اذا كان نعم فإنك على الأرجح تريد أن تجعل من فئة محددة.

Answer 8

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

Answer 9

وهذا يعتمد على ما إذا كنت تريد الفئة الأساسية التي سيتم تنفيذها من تلقاء نفسها أم لا.

وأما فئة مجردة، لا يمكنك جعل الأشياء منه.

Answer 10

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

abstract class ADataAccess
{
    abstract public void Save();
}

وعادي (غير مجردة) الطبقات يمكن أن تكون كبيرة لأشياء مماثلة ولكن عليك أن تعرف تفاصيل التنفيذ لتكون قادرة على كتابتها.

public class DataAccess
{
    public void Save()
    {
        if ( _is_new )
        {
            Insert();
        }
        else if ( _is_modified )
        {
            Update();
        }
    }
}

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

interface ISaveable
{
    void Save();
    void Insert();
    void Update();
}

class UserAccount : ISavable
{
    void ISavable.Save() { ... }
    void ISavable.Insert() { ... }
    void ISavable.Update() { ... }
}

ولكن هناك خيار آخر قد تستخدم الأدوية

class GenDataAccess<T>
{
    public void Save()
    {
        ...
    }
}

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

Answer 11

واعتقد ان الكثير منكم يجب أن رست الطبقات OO الأساسية مرة أخرى.

والمبدأ الأساسي الأساسي في OOA / OOD هو مجردة مجردة مجردة، حتى لا يمكنك مجردة لا أكثر. إذا ما تبحث الخاص بك في هو التجريد فليكن، أن يكون ما لديك OOA / OOD قال بالفعل لك. ولكن إذا كنت جالسا هناك ويتساءل ما إذا كانت "كود" يجب أن يكون مجردا أو لم يكن ثم من الواضح أنك لا تعرف ما يعنيه مصطلح ويجب ان تذهب تعلم الأساسي OOA / OOD / OOP مرة أخرى: -)

وأكثر لهذه النقطة يجب عليك أن تعلم أنماط التصميم ونظرية التوافقية، وهذا سوف يساعد مع OO بك تصاميم كثيرا!