Sometimes the differences between the singleton mode and the static class are not so obvious. They are all operation classes unrelated to data, that is, the whole process cannot have too much data dependencies-more accurately, object dependencies, it is better that it is only responsible for processing an object of a certain type that can be passed in as an interface). Let's look at the following code:
interface IPeople { string Name { set;} int Age { set; } string ToStringPeople();}class PeopleServer { public PeopleServer() { } public void ToStringPeople(IPeople p) { Console.WriteLine(p.ToStringPeople()); }}
In this way, all objects implementing the IPeople interface can be processed by the PeopleServer to reduce the coupling relationship between modules. So what are the specific differences between static classes and Singleton models?
Differences |
Singleton Mode |
Static class |
Inheritance |
Interfaces that can be inherited and implemented |
Can be integrated, but cannot be an instance Member |
Load |
The Singleton mode is flexible and can be initialized as needed |
It has been initialized during compilation, and the cost is relatively high, even if it is not used. |
Resource release |
Static objects are not purged by GC unless the entire CLR/JVM exits. |
Objects generated by static methods in static classes are cleared by GC after execution is completed. |
Polymorphism |
There can be Polymorphism |
Polymorphism is not supported. |
Object Extension |
Because the singleton mode only has one instance, it can follow the system for dynamic changes, which is conducive to the later increase and maintenance, and has the status feature. |
Expansion not supported |
Let's talk about the advantages of the singleton mode: for example, DAO initialization will occupy system resources. If the static method is used, resources will be continuously initialized and released. If complex transaction management is not involved at this time, the Singleton mode is better. In addition, it is easy to use and flexible in Initialization. I personally feel that it is better than static classes.
Here is an example of code:
/// <Summary> /// site pseudo Url Information class /// </summary> public class SiteUrls {# region internal attributes and Methods private static object lockHelper = new object (); private static volatile SiteUrls instance = null; string SiteUrlsFile = Utils. getXmlMapPath (DTKeys. FILE_SITE_XML_CONFING); private ArrayList _ Urls; public ArrayList Urls {get {return _ Urls;} set {_ Urls = value;} private NameValueCollection _ Paths; public NameValueCollection Paths {get {return _ Paths;} set {_ Paths = value ;}} private SiteUrls () {Urls = new ArrayList (); Paths = new NameValueCollection (); BLL. url_rewrite bll = new BLL. url_rewrite (); List <Model. url_rewrite> ls = bll. getList (""); foreach (Model. url_rewrite model in ls) {Paths. add (model. name, model. path); model. page = model. page. replace ("^", "&"); model. querystring = model. querystring. replace ("^", "&"); Urls. add (model) ;}# endregion public static SiteUrls GetSiteUrls () {SiteUrls _ cache = CacheHelper. get <SiteUrls> (DTKeys. CACHE_SITE_HTTP_MODULE); lock (lockHelper) {if (_ cache = null) {CacheHelper. insert (DTKeys. CACHE_SITE_HTTP_MODULE, new SiteUrls (), Utils. getXmlMapPath (DTKeys. FILE_URL_XML_CONFING); instance = CacheHelper. get <SiteUrls> (DTKeys. CACHE_SITE_HTTP_MODULE) ;}} return instance ;}}
Note thatprivate
ArrayList _Urls;
It can be changed when the system is running. When we update the value of SiteUrls, the Cache object has been removed. When we call it againreturn
instance
This may change, because we need to update data from the database again and put the new data into the cache.
Finally, you are welcome to shoot bricks ~~~