مسئله؛ وقتی همه در حال ساختن یک چیز هستند

فرض کنید در حال توسعه یک API با NestJS یا Express هستید.

برنامه به یک Connection با دیتابیس نیاز دارد. یکی از اعضای تیم در فایل database.ts این کد را می نویسد:

const db = new Database();

چند هفته بعد پروژه بزرگ تر می شود.

تیم دیگری روی ماژول احراز هویت کار می کند و چون از وجود آن فایل خبر ندارد، دوباره می نویسد:

const db = new Database();

چند روز بعد، تیم سومی روی سیستم گزارش گیری کار می کند و او هم یک Connection جدید ایجاد می کند.

کم کم در بخش های مختلف برنامه، چندین نمونه از کلاس Database ساخته شده است.

در ظاهر همه چیز درست کار می کند.

اما پشت صحنه اتفاقات دیگری در حال رخ دادن است.

هر نمونه ممکن است Connection جدیدی به دیتابیس باز کند، بخشی از منابع سیستم را اشغال کند یا حتی تنظیمات متفاوتی داشته باشد.

حالا تصور کنید همین اتفاق برای صدها Request و ده ها ماژول مختلف تکرار شود.

مشکل فقط مصرف حافظه نیست.

ممکن است به محدودیت تعداد Connectionهای دیتابیس برسید، مدیریت Connection Pool سخت تر شود یا رفتارهای غیرمنتظره ای در برنامه مشاهده کنید.

حالا بیایید یک مثال متفاوت را بررسی کنیم.

فرض کنید در حال توسعه یک ربات تلگرام هستید.

برای راه اندازی Bot می نویسید:

const bot = new Telegraf(process.env.BOT_TOKEN);

پروژه در ابتدا فقط چند فایل دارد و همه چیز ساده است.

اما بعد از مدتی پروژه بزرگ می شود.

ماژول مدیریت کاربران، ماژول سفارش ها، سیستم Notification و چند بخش دیگر به Bot دسترسی نیاز دارند.

یکی از توسعه دهندگان برای راحتی کار، دوباره یک Instance جدید می سازد.

نفر بعدی هم همین کار را می کند.

حالا برنامه چند Bot مختلف دارد که همگی با یک Token اجرا شده اند.

در بهترین حالت، فقط منابع بیشتری مصرف می شود.

اما در بدترین حالت، ممکن است چند Polling هم زمان اجرا شوند، Eventها چند بار پردازش شوند یا رفتارهایی ببینید که پیدا کردن علت آن ها ساعت ها زمان ببرد.

هر دو مثال یک سؤال مشترک را مطرح می کنند:

اگر کل برنامه فقط به یک نمونه از یک کلاس نیاز داشته باشد، چرا اجازه بدهیم چندین نمونه از آن ساخته شود؟

دقیقاً همین سؤال، نقطه شروع Singleton Pattern است.

چرا این مشکل به وجود می آید؟

در پروژه های کوچک، ساختن یک Object معمولاً ساده است.

هر جا به چیزی نیاز داریم، یک new می نویسیم و ادامه می دهیم.

const logger = new Logger();
const config = new Config();
const database = new Database();

تا زمانی که پروژه کوچک است، این روش کاملاً قابل قبول به نظر می رسد.

اما پروژه ها معمولاً همین جا متوقف نمی شوند.

با اضافه شدن قابلیت های جدید، تعداد فایل ها، کلاس ها و توسعه دهندگان بیشتر می شود.

در چنین شرایطی دیگر کسی نمی داند چند بار یک کلاس در نقاط مختلف برنامه ساخته شده است.

گاهی حتی خودمان هم فراموش می کنیم که یک نمونه از قبل وجود دارد و دوباره همان کلاس را نمونه سازی می کنیم.

مشکل اینجاست که همه کلاس ها قرار نیست رفتار یکسانی داشته باشند.

برای مثال، اگر چند نمونه از کلاس Product یا User بسازید، اتفاق خاصی نمی افتد.

اتفاقاً انتظار داریم هر کاربر یا هر محصول یک Object مستقل داشته باشد.

اما بعضی کلاس ها ذاتاً قرار نیست چند نمونه داشته باشند.

برای مثال:

Connection به دیتابیس
Configuration برنامه
Logger
Cache Manager
Instance یک ربات تلگرام

در این موارد، وجود چند نمونه مستقل معمولاً هیچ مزیتی ندارد و حتی می تواند باعث پیچیدگی بیشتر سیستم شود.

بنابراین مسئله اصلی این نیست که چطور Object بسازیم.

مسئله این است که چطور مطمئن شویم فقط همان تعداد نمونه ای که واقعاً نیاز داریم ساخته می شود.

راه حل های اشتباه

وقتی برای اولین بار با این مشکل روبه رو می شویم، معمولاً به سراغ ساده ترین راه حل ها می رویم.

یکی از رایج ترین آن ها، ساختن یک متغیر سراسری است.

export const database = new Database();

حالا هر جایی که به دیتابیس نیاز داشته باشیم، همین متغیر را Import می کنیم.

این روش در پروژه های کوچک ممکن است جواب بدهد، اما چند سؤال مهم ایجاد می کند:

اگر کسی دوباره new Database() بنویسد چه؟
چه کسی تضمین می کند همه از همین فایل استفاده کنند؟
اگر بخواهیم نحوه ساخت Database تغییر کند چه؟

راه حل رایج دیگر، استفاده از متغیرهای Global است.

global.database = new Database();

این روش هم اگرچه دسترسی را ساده می کند، اما وابستگی های پنهان ایجاد می کند و تست کردن برنامه را سخت تر می کند.

به مرور زمان، برنامه پر از بخش هایی می شود که بدون مشخص بودن وابستگی هایشان، از یک متغیر Global استفاده می کنند.

این دقیقاً خلاف چیزی است که در طراحی نرم افزار به دنبال آن هستیم.

مشکل مشترک تمام این راه حل ها این است که هیچ کدام قانونی برای ساخت Object تعریف نمی کنند.

آن ها فقط امیدوارند که همه توسعه دهندگان از یک قرارداد نانوشته پیروی کنند.

اما تجربه نشان داده است که در پروژه های بزرگ، امید داشتن به رعایت یک قرارداد کافی نیست.

ما به راه حلی نیاز داریم که خود ساختار برنامه، تعداد نمونه ها را کنترل کند.

Singleton Pattern؛ راه حل چیست؟

Singleton Pattern دقیقاً برای حل همین مسئله به وجود آمده است.

ایده آن بسیار ساده است:

اگر در کل برنامه فقط به یک نمونه از یک کلاس نیاز داریم، خود آن کلاس باید مسئول مدیریت نمونه اش باشد.

به جای اینکه هر بخش از برنامه آزادانه از new استفاده کند، کلاس تصمیم می گیرد که آیا باید نمونه جدیدی ساخته شود یا همان نمونه قبلی برگردد.

به این ترتیب، همه بخش های سیستم با همان Instance مشترک کار می کنند و دیگر نگران ساخت چندباره آن نیستیم.

البته این به معنای استفاده از Singleton در هر شرایطی نیست.

در واقع، Singleton یکی از بحث برانگیزترین Design Patternهاست و اگر بدون دلیل از آن استفاده شود، می تواند مشکلات جدیدی ایجاد کند.

پیاده سازی Singleton Pattern در TypeScript

تا اینجا فهمیدیم Singleton چه مسئله ای را حل می کند.

حالا سؤال این است که چطور می توانیم مطمئن شویم فقط یک نمونه از یک کلاس ساخته می شود؟

برای رسیدن به این هدف، باید دو قانون را رعایت کنیم:

هیچ کس نتواند مستقیماً از کلاس نمونه سازی کند.
خود کلاس مسئول ایجاد و نگهداری تنها نمونه خودش باشد.

بیایید قدم به قدم این پیاده سازی را بررسی کنیم.

مرحله اول؛ جلوگیری از ساخت مستقیم Object

در حالت عادی، هر کسی می تواند به سادگی یک نمونه جدید از کلاس ایجاد کند.

class DatabaseConnection {}

const db = new DatabaseConnection();

اگر چند نفر در قسمت های مختلف پروژه همین کار را انجام دهند، دیگر هیچ کنترلی روی تعداد Instanceهای ساخته شده نخواهیم داشت.

اولین قدم این است که Constructor را private کنیم.

class DatabaseConnection {
  private constructor() {}
}

حالا اگر کسی تلاش کند این کلاس را نمونه سازی کند:

const db = new DatabaseConnection();

TypeScript خطا می دهد.

یعنی از این لحظه به بعد، فقط خود کلاس اجازه ساختن Instance جدید را دارد.

این دقیقاً همان چیزی است که می خواستیم.

مرحله دوم؛ نگهداری تنها Instance

حالا که هیچ کس از بیرون نمی تواند Object جدیدی بسازد، خود کلاس باید تنها Instance را نگهداری کند.

برای این کار یک Property استاتیک تعریف می کنیم.

class DatabaseConnection {
  private static instance: DatabaseConnection;

  private constructor() {}
}

چرا این Property را static تعریف کردیم؟

چون قرار نیست به یک Object خاص تعلق داشته باشد.

ما هنوز هیچ Objectی نداریم.

این متغیر باید متعلق به خود کلاس باشد تا بتواند تنها Instance برنامه را نگهداری کند.

مرحله سوم؛ ساخت یا برگرداندن Instance

حالا باید راهی وجود داشته باشد که سایر بخش های برنامه بتوانند به این Instance دسترسی داشته باشند.

برای این کار معمولاً متدی به نام getInstance() ایجاد می کنیم.

class DatabaseConnection {
  private static instance: DatabaseConnection;

  private constructor() {}

  public static getInstance(): DatabaseConnection {
    if (!DatabaseConnection.instance) {
      DatabaseConnection.instance = new DatabaseConnection();
    }

    return DatabaseConnection.instance;
  }
}

اتفاقی که در این متد می افتد بسیار ساده است.

اگر Instance هنوز ساخته نشده باشد:

آن را ایجاد می کنیم.
داخل متغیر استاتیک ذخیره می کنیم.

اگر قبلاً ساخته شده باشد:

همان نمونه قبلی را برمی گردانیم.

به همین دلیل، در کل برنامه فقط یک Instance وجود خواهد داشت.

نتیجه را امتحان کنیم

حالا دو بار متد getInstance() را صدا می زنیم.

const db1 = DatabaseConnection.getInstance();
const db2 = DatabaseConnection.getInstance();

console.log(db1 === db2);

خروجی:

true

ممکن است دو متغیر متفاوت داشته باشیم، اما هر دو به یک Object در حافظه اشاره می کنند.

به همین دلیل تغییراتی که از طریق یکی انجام می شود، از طریق دیگری هم قابل مشاهده خواهد بود.

Lazy Initialization یعنی چه؟

پیاده سازی قبلی از روشی به نام Lazy Initialization استفاده می کند.

یعنی Object تا زمانی که واقعاً به آن نیاز نباشد، ساخته نمی شود.

در اولین فراخوانی getInstance()، نمونه ایجاد می شود و بعد از آن همیشه همان نمونه برگردانده می شود.

این روش معمولاً انتخاب بهتری است، چون از مصرف بی دلیل حافظه و منابع جلوگیری می کند.

به خصوص زمانی که ساخت Object پرهزینه باشد؛ مثل ایجاد Connection با دیتابیس یا راه اندازی یک سرویس خارجی.

آیا همیشه باید Lazy باشیم؟

نه لزوماً.

در بعضی پروژه ها، می دانیم که یک سرویس قطعاً در ابتدای اجرای برنامه موردنیاز خواهد بود.

در چنین شرایطی می توان Instance را همان ابتدای برنامه ایجاد کرد.

به این روش Eager Initialization گفته می شود.

اما در اکوسیستم JavaScript و TypeScript، معمولاً Lazy Initialization رایج تر است؛ چون انعطاف بیشتری دارد و فقط در صورت نیاز منابع را مصرف می کند.

آیا این پیاده سازی همیشه کافی است؟

برای بیشتر پروژه های مبتنی بر JavaScript و TypeScript، بله.

اما اگر وارد زبان هایی مانند Java یا C# شوید، موضوعات دیگری مثل Thread Safety هم مطرح می شود؛ چون چند Thread ممکن است هم زمان تلاش کنند اولین Instance را ایجاد کنند.

در JavaScript چنین نگرانی ای در اکثر سناریوهای معمول وجود ندارد، زیرا اجرای کد در یک Thread انجام می شود.

البته این به معنای بی نیازی کامل از مدیریت منابع نیست؛ اما پیاده سازی کلاسیک Singleton که در این مقاله دیدیم، برای بیشتر پروژه های TypeScript کاملاً کافی است.

تا اینجا با پیاده سازی کلاسیک Singleton آشنا شدیم.

اما سؤال مهم تری باقی مانده است.

آیا واقعاً در پروژه های واقعی خودمان Singleton می نویسیم؟

در بخش بعدی، دو مثال واقعی را بررسی می کنیم؛ یکی مدیریت Connection به دیتابیس و دیگری ساخت یک ربات تلگرام. خواهیم دید که چرا در هر دو سناریو داشتن فقط یک Instance، نه یک انتخاب، بلکه یک نیاز است.

Singleton Pattern در پروژه های واقعی

تا اینجا یاد گرفتیم Singleton چگونه پیاده سازی می شود.

اما سؤال مهم تر این است:

آیا واقعاً در پروژه های واقعی خودمان Singleton می نویسیم؟

پاسخ این سؤال هم بله است و هم خیر.

بله، چون هنوز هم مسئله هایی وجود دارند که فقط به یک Instance نیاز دارند.

و خیر، چون در بسیاری از Frameworkهای مدرن، خود Framework این مسئولیت را بر عهده گرفته است و دیگر لازم نیست هر بار Singleton را از صفر پیاده سازی کنیم.

برای درک بهتر، دو مثال واقعی را بررسی می کنیم.

مثال اول؛ مدیریت Connection به دیتابیس

فرض کنید در حال توسعه یک API هستید.

برنامه برای خواندن و ذخیره اطلاعات باید به دیتابیس متصل شود.

اگر هر بخش از برنامه Connection مخصوص خودش را ایجاد کند، چیزی شبیه این خواهیم داشت:

const db = new DatabaseConnection();

در نگاه اول، این کد هیچ مشکلی ندارد.

اما حالا تصور کنید:

ماژول کاربران یک Connection بسازد.
ماژول سفارش ها یک Connection دیگر.
ماژول احراز هویت یک Connection دیگر.
سیستم گزارش گیری هم یک Connection جدید ایجاد کند.

کم کم تعداد زیادی Connection به دیتابیس باز خواهد شد.

این موضوع می تواند مشکلات مختلفی ایجاد کند:

مصرف بی دلیل منابع
افزایش تعداد Connectionهای باز
رسیدن به محدودیت Connection Pool
دشوار شدن مدیریت Connectionها
افزایش احتمال بروز خطا

در چنین شرایطی معمولاً منطقی تر است که همه بخش های برنامه از یک Connection مشترک استفاده کنند.

دقیقاً به همین دلیل است که بسیاری از ORMها و Driverهای دیتابیس، یک Instance مرکزی از Connection یا Client ایجاد می کنند و کل برنامه از همان استفاده می کند.

مثال دوم؛ ربات تلگرام

فرض کنید در حال توسعه یک ربات تلگرام با کتابخانه Telegraf هستید.

برای شروع، کافی است Bot را مقداردهی کنید.

const bot = new Telegraf(process.env.BOT_TOKEN);

در ابتدای پروژه همه چیز ساده است.

اما پروژه به مرور بزرگ تر می شود.

حالا ماژول مدیریت کاربران، سیستم سفارش ها، Notification Service و بخش های دیگر هم به Bot نیاز دارند.

اگر هر توسعه دهنده بدون اطلاع از ساختار برنامه، دوباره این کد را بنویسد:

const bot = new Telegraf(process.env.BOT_TOKEN);

عملاً چند Instance از Bot ساخته خواهد شد.

در چنین شرایطی ممکن است با مشکلاتی مثل این روبه رو شوید:

چند Polling هم زمان
ثبت چندباره Handlerها
پردازش تکراری Messageها
مصرف بیشتر حافظه
رفتارهای غیرقابل پیش بینی

در حالی که کل برنامه فقط به یک Bot نیاز دارد.

به همین دلیل معمولاً Bot فقط یک بار ساخته می شود و همان Instance در اختیار بخش های مختلف برنامه قرار می گیرد.

آیا Frameworkها هم از Singleton استفاده می کنند؟

بله.

شاید بدون اینکه متوجه باشید، هر روز با Singleton کار می کنید.

برای مثال، در NestJS بیشتر Providerها به صورت پیش فرض Singleton هستند.

یعنی زمانی که یک Service را در چند Controller مختلف تزریق می کنید، برای هر Controller یک Object جدید ساخته نمی شود.

همه آن ها از همان Instance مشترک استفاده می کنند.

به همین دلیل معمولاً لازم نیست خودتان Singleton را پیاده سازی کنید؛ Framework این کار را برای شما انجام می دهد.

این Pattern را کجا دیده ایم؟

Singleton یکی از آن Patternهایی است که شاید کمتر آن را مستقیماً بنویسید، اما تقریباً هر روز از آن استفاده می کنید.

ابزار یا کتابخانه	کاربرد Singleton
NestJS Providers	به صورت پیش فرض فقط یک Instance از هر Provider ساخته می شود.
Prisma Client	معمولاً یک Client برای کل برنامه ایجاد می شود.
TypeORM DataSource	مدیریت Connectionها از طریق یک DataSource مشترک انجام می شود.
Telegraf	معمولاً فقط یک Bot Instance برای کل برنامه ساخته می شود.
Winston Logger	یک Logger مرکزی در اختیار کل برنامه قرار می گیرد.
Config Service	تنظیمات برنامه معمولاً از طریق یک Instance مشترک مدیریت می شوند.

مزایای Singleton Pattern

اگر در جای درست از Singleton استفاده کنیم، مزایای قابل توجهی خواهد داشت.

یکی از مهم ترین مزیت های آن، جلوگیری از ساخت Instanceهای غیرضروری است.

به جای اینکه چندین Object مشابه در حافظه داشته باشیم، همه بخش های برنامه از یک نمونه مشترک استفاده می کنند.

این موضوع علاوه بر کاهش مصرف منابع، مدیریت سرویس های مشترکی مانند Logger، Configuration یا Database Connection را نیز ساده تر می کند.

از طرف دیگر، وجود یک نقطه دسترسی مشخص باعث می شود مدیریت چرخه حیات این Objectها آسان تر شود و رفتار برنامه قابل پیش بینی تر باشد.

معایب Singleton Pattern

با وجود تمام مزایا، Singleton یکی از بحث برانگیزترین Design Patternهاست.

دلیل این موضوع آن است که استفاده نادرست از Singleton می تواند وابستگی های پنهان ایجاد کند.

وقتی همه بخش های برنامه به یک Object مشترک وابسته باشند، تست کردن آن ها سخت تر می شود و تغییر رفتار سیستم نیز پیچیده تر خواهد شد.

علاوه بر این، بسیاری از برنامه نویسان به مرور زمان از Singleton به عنوان یک متغیر Global استفاده می کنند.

در چنین شرایطی، کلاس های مختلف بدون اینکه وابستگی خود را به صورت شفاف اعلام کنند، مستقیماً به همان Instance مشترک دسترسی پیدا می کنند.

این کار Coupling را افزایش می دهد و نگهداری پروژه را دشوارتر می کند.

به همین دلیل بسیاری از Frameworkهای مدرن ترجیح می دهند به جای پیاده سازی مستقیم Singleton، از Dependency Injection برای مدیریت طول عمر Objectها استفاده کنند.

اشتباهات رایج

Singleton یکی از آن Patternهایی است که معمولاً با چند مفهوم دیگر اشتباه گرفته می شود.

Singleton با Global Variable تفاوت دارد.

Global Variable فقط یک متغیر است که از همه جا قابل دسترسی است، اما Singleton درباره کنترل فرآیند ساخت یک Object صحبت می کند.

Singleton با Static Class هم یکی نیست.

در Static Class اصلاً Objectی ساخته نمی شود، اما Singleton همچنان یک Object واقعی ایجاد می کند؛ فقط تعداد آن را به یک نمونه محدود می کند.

همچنین نباید Singleton را با Dependency Injection یکی دانست.

Dependency Injection فقط مسئول مدیریت وابستگی هاست و ممکن است برای بعضی سرویس ها از طول عمر Singleton استفاده کند، اما این دو مفهوم یکسان نیستند.

چه زمانی از Singleton استفاده کنیم؟

Singleton انتخاب مناسبی است اگر:

فقط به یک Instance از یک کلاس نیاز دارید.
ساخت چند نمونه باعث هدر رفت منابع می شود.
همه بخش های برنامه باید از یک وضعیت مشترک استفاده کنند.
مدیریت متمرکز یک سرویس اهمیت دارد.

چه زمانی از Singleton استفاده نکنیم؟

اگر فقط برای راحت تر شدن دسترسی به یک Object به سراغ Singleton می روید، احتمالاً انتخاب درستی نیست.

همچنین اگر کلاس شما وضعیت (State) پیچیده و قابل تغییر نگهداری می کند یا قرار است در تست های مختلف رفتار متفاوتی داشته باشد، استفاده از Singleton می تواند دردسرساز شود.

در بسیاری از پروژه های امروزی، استفاده از Dependency Injection انتخاب مناسب تر و انعطاف پذیرتری است.

جمع بندی

Singleton Pattern یکی از ساده ترین و در عین حال پرکاربردترین Design Patternهای خانواده Creational است.

این Pattern تضمین می کند که در طول اجرای برنامه فقط یک Instance از یک کلاس وجود داشته باشد و تمام بخش های سیستم از همان نمونه استفاده کنند.

با این حال، Singleton یک راه حل عمومی برای همه مسائل نیست.

اگر مسئله شما واقعاً به یک نمونه مشترک نیاز دارد، Singleton می تواند انتخاب بسیار خوبی باشد. اما اگر صرفاً به دنبال دسترسی آسان تر به یک Object هستید، احتمالاً راه حل های بهتری مانند Dependency Injection وجود دارند.

در مقاله بعدی، سراغ Factory Method Pattern می رویم و بررسی می کنیم چرا در پروژه های بزرگ، ساخت Objectها را معمولاً به خود کلاس ها یا بخش های دیگر سیستم واگذار می کنیم و کمتر مستقیماً از new استفاده می کنیم.

Singleton Pattern چرا گاهی فقط باید یک نمونه از یک کلاس وجود داشته باشد؟

علی صفری

نظرات