高手来谈一下，singleton模式和静态类，如何取舍singleton和静态类实现方式类似，当然也有些不同，比如静态类
高手来谈一下，singleton模式和静态类，如何取舍
singleton和静态类实现方式类似，当然也有些不同，比如静态类不能实例化，不能实现接口等。
但是在真正使用的时候，却体现不出差别，也就是说，很难取舍到底选谁，我在使用的时候发现使用静态类貌似更加方便。
高手来谈谈看法和观点吧。
[解决办法]
[解决办法]额，静态类和单件是不能拿来比较的
静态类的语义是全局唯一代码段，而单件的语义是全局唯一对象实例
语义上是完全不同地，不能说起修饰都是“全局唯一”就放一块比较
如果是这样那么所有public修饰的东西我们不是都得比较一翻了
另外：ls几位都说了，如果要研究对象设计，那么请先抛开代码。对象设计是本身哲学性和世界观的表达。
如何把现实的东西用概念还原表达出来，才是对象设计的实质。而代码则是体现你头脑里那个概念模型的工具。
所以这也很好的体现上面几位的观点
1。与其纠结那个代码，不如学习人家如何思考，如何表达这个世界
2。模式受限于技术手段，不同时期，技术手段不同。即使是同一个人在同一个世界观下的模型，在不同技术时期也不一样，毕竟技术手段不一样。这个你比较一下。C#，basic，python，prolog这几个语言风格写出来的费波拉契数就明白了，费波拉契数的计算规则是不会变滴，但是在对象式，过程式，申明式，逻辑式中他们代码手段则完全不同
3。各种设计模式书里所提到的那些例子，实际上也都是程序员个人的世界观和策略体现。或许这些例子表达了一些通行的策略，但是实际上每个人世界观和策略实际是不同地。所以针对同一个问题，让我和楼上几位星星去把问题抽象出来，我们答案也许都是不一样滴。这里面并没有谁正确，谁错误的区别，只是有谁更符合那个项目而已（当然也有可能，我们几位都给出了一样的答案，但也只能表明对于这个项目，这个问题我们在世界观上相近，而策略上也是英雄所见略同而已）
[解决办法]这也是大多数人觉着设计模式难学的原因
代码看的明白却不知道如何用在项目里。这个主要是因为太关注代码了，而忽略了去在头脑里去还原设计者的场景和当时人家的头脑中是如何还原那个场景的
我见过很多人学习设计模式就和在学校里学习hello world差不多。他们会一行一行地用手把书上的那个例子敲出来，然后运行，接着感叹！神了，太神奇，原来可以这样哦！但是后面呢，没有后面了，他除了了解到了一个“新”名词以外，就没啥了
实际上，我遇见的大多数设计模式学的好的人，甚至都没有完整滴把设计模式从头到尾读完 ，因为实在没有必要读完，我们只是需要还原一下场景和思考一下设计者当时所持的世界观和策略就ok。
另外提一句：别把设计模式看的太重，设计模式实际基于的理论是那5个基础设计原则。
只要你不是按过程的写法，只要你按照还原实现模型对象理念，只要你是按照那5个基础设计原则去设计。出来的东西80%就是符合模式滴。为什么设计模式被吹的神乎其神，这就是原因--80%可不是一个随便的数字，我个人虽然不太看重书本上那些模式，但是也不得不佩服总结出来的人。你写出来的东西，能有80%的东西都在上面找到，相当了不起的总结。
[解决办法]恰巧最近在看最老的那版设计模式（HeadFirst设计模式和大话设计模式也看过，但是那时候对OO语言的特性没有太好的认识，所以看了半天很糊涂）。
设计模式是在一定的用途或者目的环境下，如何发挥OO语言特性的经验总结。
原著优秀的地方就在于，没有让你读死书，读书死，而是尽量把分析和权衡、取舍的过程讲出来，并且给了你一不止一个参考实现。
至于Singleton模式和静态类，只有一个类的Singleton和静态类相比没什么代码行上的优势（差十行二十行？）。
但是，面向对象的编程，不是追求代码行最少，而是强调设计的灵活性。
单例模式有一个增强，就是有派生类的单例，在那种情况下，你看看静态类如何模拟？
