فئة مع طريقة واحدة — أفضل النهج ؟

Question

أقول لقد الفئة التي من المفترض أن تؤدي وظيفة واحدة.بعد أداء وظيفة ، يمكن أن يتم تدميرها.هل هناك أي سبب لتفضيل أحد هذه المقدمة.

// Initialize arguments in constructor
MyClass myObject = new MyClass(arg1, arg2, arg3);
myObject.myMethod();

// Pass arguments to method
MyClass myObject = new MyClass();
myObject.myMethod(arg1, arg2, arg3);

// Pass arguments to static method
MyClass.myMethod(arg1, arg2, arg3);

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

Answer 1

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

تعدد الأشكال
نقول لدينا طريقة UtilityClass.SomeMethod التي بسعادة الطنين جنبا إلى جنب.فجأة نحن بحاجة إلى تغيير وظيفة قليلا.أكثر من وظيفة هو نفسه ، ولكن علينا أن نغير بضعة أجزاء على الرغم من ذلك.كان أسلوب ثابت ، ونحن يمكن أن تجعل مقتبسة من الدرجة وتغيير طريقة المحتويات حسب الحاجة.كما أنه أسلوب ثابت ، لا يمكننا.بالتأكيد, إذا نحن بحاجة فقط لإضافة وظائف سواء قبل أو بعد الطريقة القديمة ، يمكننا إنشاء فئة جديدة وندعو القديم داخل ذلك - ولكن هذا مجرد الإجمالي.

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

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

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

المعلمة زحف
أن تبدأ مع هذا لطيف قليلا الأبرياء أسلوب ثابت قد تأخذ معلمة واحدة.مثل وظيفة تنمو بضع معلمات جديدة تضاف.قريبا مزيد من المعلمات وأضاف أن اختيارية ، حتى نخلق الزائدة من طريقة (أو مجرد إضافة القيم الافتراضية في اللغات التي تدعمها).قبل فترة طويلة, لدينا أسلوب يأخذ 10 معلمات.الثلاثة الأولى فقط هي حقا مطلوب معلمات 4-7 اختيارية.ولكن إذا المعلمة 6 المحدد, 7-9 يجب ملؤها في وكذلك...نحن قد خلق فئة مع غرض واحد فعل ما هذا أسلوب ثابت هل يمكننا حل هذا عن طريق أخذ في المعلمات المطلوبة في منشئ ، مما يتيح للمستخدم مجموعة اختياري القيم من خلال خصائص أو أساليب مجموعة متعددة مترابطة القيم في نفس الوقت.أيضا ، إذا كان الأسلوب نمت على هذا القدر من التعقيد ، فإنه على الأرجح يجب أن يكون في الطبقة الخاصة به على أي حال.

مطالبا المستهلكين إلى إنشاء مثيل من الطبقات دون سبب
واحدة من الحجج الأكثر شيوعا هو: لماذا طلب المستهلكين من الطبقة إنشاء مثيل اللجوء إلى هذه طريقة واحدة ، في حين وجود أي استخدام على سبيل المثال بعد ذلك ؟ إنشاء مثيل فئة جدا جدا رخيصة العملية في معظم اللغات ، لذلك السرعة ليست قضية.مضيفا إضافية سطر من التعليمات البرمجية إلى المستهلك منخفضة التكلفة من أجل إرساء أسس أكثر تستعصي على الحل في المستقبل.وأخيرا, إذا كنت ترغب في تجنب خلق حالات ببساطة إنشاء المفرد المجمع من الدرجة التي تسمح لسهولة استخدامها - على الرغم من أن هذا لا تجعل شرط أن فئة عديمي الجنسية.إذا لم يكن عديم الجنسية ، لا يزال بإمكانك إنشاء ساكنة المجمع أساليب التعامل مع كل شيء ، في حين لا تزال تعطي لك كل الفوائد على المدى الطويل.أخيرا, يمكن أن تجعل أيضا فئة يخفي مثيل كما لو كان المفرد:MyWrapper.المثال هو الملكية التي يعود فقط new MyClass();

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

المعايير المعايير المعايير!
باستخدام أساليب المثال لا تمنع من أيضا باستخدام أساليب ثابتة والعكس بالعكس.طالما هناك منطق وراء التمايز وانها موحدة.لا يوجد شيء أسوأ من يبحث على عمل طبقة المترامية الاطراف مع مختلف أساليب التنفيذ.

Answer 2

وأنا أفضل وسيلة ثابتة. منذ الفئة لا تمثل كائن فإنه لا معنى لجعل مثيل له.

وفئات التي لا توجد إلا لأساليبهم ينبغي أن تترك ثابت.

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

وأنا حقا لا أعرف ما هو الوضع هنا، ولكن أود أن ننظر في وضعه كأسلوب في واحدة من الفئات التي ARG1، ARG2 أو arg3 تنتمي إلى - إذا كنت أستطيع أن أقول غويا أن واحدة من تلك الفئات سيملك هذه الطريقة.

Answer 7

وأنا أقترح أن من الصعب الإجابة استنادا إلى المعلومات المقدمة.

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

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

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

Answer 8

ويمكن أن يتم فصلك ثابت؟

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

Answer 9

وإذا كان هذا الأسلوب عديم الجنسية، وكنت لا تحتاج إلى تمرير حولها، ثم يجعل اكثر احساسا لتحديد أنها ثابتة. إذا كنت بحاجة لتمرير طريقة حولها، قد تفكر في استخدام <لأ href = "http://msdn.microsoft.com/en-us/library/aa288459(VS.71).aspx" يختلط = "نوفولو noreferrer "> مندوب بدلا من واحدة من الأساليب المقترحة الأخرى.

Answer 10

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

• الخدمات
  • محددة من قبل I[ServiceName]Service واجهة.
  • المصدرة والمستوردة خلال واجهة نوع.
  • واحدة التنفيذ يتم توفيرها من قبل التطبيق المضيف و المستهلكة داخليا و/أو امتداد.
  • الطرق على واجهة الخدمة هي مؤشر الترابط-الآمن.

كما المفتعلة على سبيل المثال:

public interface ISettingsService
{
    string ReadSetting(string name);

    void WriteSetting(string name, string value);
}

[Export]
public class ObjectRequiringSettings
{
    [Import]
    private ISettingsService SettingsService
    {
        get;
        set;
    }

    private void Foo()
    {
        if (SettingsService.ReadSetting("PerformFooAction") == bool.TrueString)
        {
            // whatever
        }
    }
}

Answer 11

وأود فقط أن تفعل كل شيء في المنشئ. مثل ذلك:

new MyClass(arg1, arg2, arg3);// the constructor does everything.

أو

MyClass my_object(arg1, arg2, arg3);

Answer 12

وثمة مسألة أكثر أهمية للنظر هو ما إذا كان النظام سيكون قيد التشغيل في بيئة مؤشرات، وعما إذا كان سيكون موضوع آمن أن يكون أسلوب ثابت أو متغيرات ...

ويجب إيلاء اهتمام خاص لحالة النظام.

Answer 13

وأنت قد تكون قادرة على تجنب وضع كل ذلك معا. محاولة ريفاكتور بحيث تحصل arg1.myMethod1(arg2, arg3). ARG1 مبادلة مع أي ARG2 أو arg3 إذا كان أكثر منطقية.

إذا لم يكن لديك السيطرة على فئة من ARG1، ثم تزين به:

class Arg1Decorator
    private final T1 arg1;
    public Arg1Decorator(T1 arg1) {
        this.arg1 = arg1;
    }
    public T myMethod(T2 arg2, T3 arg3) {
        ...
    }
 }

 arg1d = new Arg1Decorator(arg1)
 arg1d.myMethod(arg2, arg3)

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

Answer 14

وأعتقد، إذا لن يتم استخدام خصائص الطبقة أو مثيل فئة في منشئات أو في أساليب الاتصال، لا يتم اقترح الأساليب التي صممت مثل نمط 'ثابت'. أسلوب ثابت يجب thinked دائما في "مساعدة" الطريقة.