Singleton.

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

يحل نمط Singleton مشكلتين في آنٍ واحد، مما ينتهك مبدأ المسؤولية الواحدة:

1. ضمان أن الصنف لديه نسخة واحدة فقط. لماذا يريد أحدهم التحكم في عدد النسخ التي يمتلكها الصنف؟ السبب الأكثر شيوعاً هو التحكم في الوصول إلى مورد مشترك—مثل قاعدة بيانات أو ملف.

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

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

2. توفير نقطة وصول عالمية لتلك النسخة. تذكر تلك المتغيرات العالمية التي استخدمتها (حسناً، أنا) لتخزين بعض الكائنات الأساسية؟ رغم أنها مفيدة جداً، إلا أنها غير آمنة للغاية، إذ يمكن لأي كود احتمال الكتابة فوق محتويات تلك المتغيرات وتعطيل التطبيق.

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

   ثمة جانب آخر لهذه المشكلة: لا تريد أن يتناثر الكود الذي يحل المشكلة رقم 1 في جميع أنحاء برنامجك. من الأفضل بكثير احتواؤه ضمن صنف واحد، خاصةً إذا كان بقية الكود يعتمد عليه.

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

جميع تطبيقات Singleton لها هاتان الخطوتان المشتركتان:

• جعل المُنشئ الافتراضي خاصاً، لمنع الكائنات الأخرى من استخدام المُشغّل new مع صنف Singleton.
• إنشاء طريقة إنشاء ساكنة تعمل كمُنشئ. تحت الغطاء، تستدعي هذه الطريقة المُنشئ الخاص لإنشاء كائن وتحفظه في حقل ساكن. جميع الاستدعاءات اللاحقة لهذه الطريقة تُرجع الكائن المخزن مؤقتاً.

إذا كان الكود لديك يملك وصولاً إلى صنف Singleton، فإنه يستطيع استدعاء الطريقة الساكنة لـ Singleton. لذا في كل مرة تُستدعى فيها تلك الطريقة، يُرجع دائماً نفس الكائن.

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

// يُعرّف صنف Database طريقة `getInstance` التي تتيح
// للعملاء الوصول إلى نفس نسخة اتصال قاعدة البيانات
// في جميع أنحاء البرنامج.
class Database is
    // يجب الإعلان عن الحقل المخصص لتخزين نسخة Singleton
    // كحقل ساكن.
    private static field instance: Database

    // يجب أن يكون مُنشئ Singleton خاصاً دائماً لمنع
    // استدعاءات الإنشاء المباشرة باستخدام المُشغّل `new`.
    private constructor Database() is
        // بعض كود التهيئة، مثل الاتصال الفعلي
        // بخادم قاعدة البيانات.
        // ...

    // الطريقة الساكنة التي تتحكم في الوصول إلى
    // نسخة Singleton.
    public static method getInstance() is
        if (Database.instance == null) then
            acquireThreadLock() and then
                // التحقق من أن النسخة لم تتم تهيئتها بعد
                // من قِبَل خيط آخر بينما كان هذا الخيط
                // ينتظر تحرير القفل.
                if (Database.instance == null) then
                    Database.instance = new Database()
        return Database.instance

    // أخيراً، يجب أن يُعرّف أي Singleton منطق أعمال
    // يمكن تنفيذه على نسخته.
    public method query(sql) is
        // على سبيل المثال، تمر جميع استعلامات قاعدة البيانات
        // لأي تطبيق عبر هذه الطريقة. لذلك يمكنك وضع
        // منطق التحكم في معدل الطلبات أو التخزين المؤقت هنا.
        // ...

class Application is
    method main() is
        Database foo = Database.getInstance()
        foo.query("SELECT ...")
        // ...
        Database bar = Database.getInstance()
        bar.query("SELECT ...")
        // سيحتوي المتغير `bar` على نفس الكائن
        // الموجود في المتغير `foo`.

1. أضف حقلاً ساكناً خاصاً إلى الصنف لتخزين نسخة Singleton.

2. أعلن طريقة إنشاء ساكنة عامة للحصول على نسخة Singleton.

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

4. اجعل مُنشئ الصنف خاصاً. ستظل الطريقة الساكنة للصنف قادرة على استدعاء المُنشئ، لكن ليس الكائنات الأخرى.

5. راجع كود العميل واستبدل جميع الاستدعاءات المباشرة لمُنشئ Singleton باستدعاءات طريقة الإنشاء الساكنة.

• يمكن في الغالب تحويل صنف Facade إلى Singleton إذ يكفي في معظم الحالات كائن facade واحد.

• يشبه Flyweight نمط Singleton إذا تمكنت من اختزال جميع الحالات المشتركة للكائنات في كائن flyweight واحد. غير أن ثمة فرقين أساسيين بين هذين النمطين:

  1. يجب أن تكون هناك نسخة Singleton واحدة فقط، في حين يمكن أن يمتلك صنف Flyweight نسخاً متعددة بحالات داخلية مختلفة.
  2. يمكن أن يكون كائن Singleton قابلاً للتغيير. كائنات Flyweight غير قابلة للتغيير.

• يمكن تطبيق Abstract Factories وBuilders وPrototypes جميعها كـ Singletons.