این الگو جزء دسته ی الگوهای سازنده از مجموعه Gang of Four می باشد.
فرض کنید که در یک پروژه فقط باید با یک نمونه از یک کلاس کار کنیم و نباید نمونه سازی دیگری انجام شود. مثلا Client در یک محیط چند نخی (multi thread) باید با کلاس دوربین مدار بسته کار کند و بتواند دوربین را در جهت های مختلف به حرکت در بیاورد. اگر فقط با یک نمونه از کلاس دوربین کار کند، مشکلی پیش نمی آید. اما اگر بخواهد دوباره نمونه ای از کلاس دوربین بسازد چه؟ یا اگر یک thread بخواهد دوربین را به سمت راست بچرخاند و thread دیگر آن را به سمت چپ، آن وقت چه اتفاقی خواهد افتاد؟ و هزاران مثال دیگر که به ما نشان می دهند در بعضی مواقع فقط یک نمونه از کلاس باید ساخته شود و نه بیشتر. اگر جلوی نمونه سازی مجدد را نگیریم، مشکلات زیادی در پروژه بوجود می آید. راه حل چیست؟
پاسخ ساده است؛ الگوی Singleton
چرا؟ چون این الگو تنها یک نمونه از کلاس می سازد و دسترسی Global به آن را فراهم می کند. همچنین تمام راه هایی که از طریق آنها می توان بیش از یک نمونه از کلاس را ساخت، مسدود می کند. این الگو، سازنده ی کلاس را مخفی می کند. برای پیاده سازی الگوی Singleton از Static ها استفاده می شود زیرا اعضای استاتیک از قبل، مفهوم تک نمونه بودن یا singleton را دارا می باشند.
الگوی Singleton یکی از کاربردی ترین الگو های طراحی است، کاربرد آن بیشتر برای مواقعی است که نمی خواهیم وضعیت شی تغییر کند و یا می خواهیم class را به صورت stateless نگه داریم. این قضیه بیشتر در محیط های چند نخی (multi thread) به چشم می خورد که بهتر است کلاس stateless باشد.
بهتر است نگاهی به UML الگوی Singleton بیاندازیم
کاربرد ها:
- زمانی که قرار است یکسری داده های master را یکجا بارگذاری کنیم و اجازه دهیم مصرف کنندگان داده به جای فراخوانی های متعدد، با ساخت یک نمونه از کلاس، یک فراخوانی به یک کلاس Singleton داشته باشند.
- در حالت کلی، در هر برنامه پیچیده، می توان به کلاس های Repository و لایه Data Access به صورت Singleton نگاه کرد. چون معمولاً نمی خواهیم وضعیت در این لایه ها حفظ شود.
- از جمله مثال های دیگر می توان به بحث log گیری، تنظیمات یا configuration ، Caching و غیره اشاره کرد که می توان آن ها را به صورت Singleton پیاده‌سازی کرد. چون در تمام مثال های ذکر شده نیاز به یک نقطه مرکزی و سراسری حس خواهد شد تا به این کلاس ها دسترسی داشته باشیم.
- استفاده از الگوی Singleton در کلاس های Repository از ساخت نمونه های اضافه و افزایش سربار حافظه جلوگیری به عمل می آورد و کارایی برنامه را افزایش می دهد.
به دلایل مختلفی نباید از کلاس های static استفاده کرد. برخی از این دلایل عبارتند از:
- بعضی مواقع می خواهیم Interface ها را در یک کلاس پیاده‌سازی کنیم (برای مثال پیاده‌سازی IOC) و به جای پیاده‌سازی کلاس به صورت static، آن را به صورت Singleton پیاده‌سازی می کنیم.
- در صورت نیاز، می توانیم از یک کلاس singleton به صورت پارامتر یک متد استفاده کنیم در صورتی که نمی توان این کار را با کلاس static انجام داد.
پیاده سازی
می خواهیم یک کلاس به صورت Singleton بنویسیم که برای نمونه سازی احتیاج به یک نام دارد و آن نام را با متدی به نام Print چاپ می کند.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
public class SingletonClass { private static SingletonClass instance = null; private static object lockMe = new object(); private string _name {get; set;} private SingletonClass(string name) { _name = name; } public static SingletonClass GetInstance(string name) { if (instance == null) lock (lockMe) { instance = new SingletonClass(name); } return instance; } public void Print() { Console.WriteLine(_name); } } |
حال می خواهیم دو نمونه از این کلاس بسازیم، آیا این کلاس به ما اجازه می دهد؟
|
1 2 3 4 5 6 7 8 9 10 |
class Program { static void Main(string[] args) { SingletonClass sc = SingletonClass.GetInstance("Shahin"); sc.Print(); sc = SingletonClass.GetInstance("Morad"); sc.Print(); } } |
خیر، با استفاده از الگوی Singleton کلاسی ساختیم که تنها یک بار می توان از روی آن نمونه ساخت.
Shahin
Shahin
