面向对象很好地解决了"抽象"的问题， 但不可免的付出一定的代价。对于通常情况来讲，面向对象的成本大都可以忽略不计。但某些情况，面向对象所带来的成本必须谨慎处理。
典型模式：单例模式Singleton，享元模式Flyweight
一.单例模式(Singleton)
1.动机
在软件系统中,经常有这样一些特殊的类,必须保证他们在系统中只存在一个实例,才能保证他们的逻辑正确。以及良好的效率。
2.作用
绕过常规构造器，提供一种机制来保证一个类只有一个实例（设计者的责任）
3.定义
保证一个类仅有一个实例，并提供一个该实例的全局访问点。
4.代码
class Singleton{
private:
Singleton();
Singleton(const Singleton& other);
public:
static Singleton* getInstance();
static Singleton* m_instance;
};
Singleton* Singleton::m_instance=nullptr;
//线程非安全版本
Singleton* Singleton::getInstance() {
if (m_instance == nullptr) {
m_instance = new Singleton();
}
return m_instance;
}
//线程安全版本，但锁的代价过高
Singleton* Singleton::getInstance() {
Lock lock;
if (m_instance == nullptr) {
m_instance = new Singleton();
}
return m_instance;
}
//双检查锁，但由于内存读写reorder不安全
Singleton* Singleton::getInstance() {
if(m_instance==nullptr){
Lock lock;
if (m_instance == nullptr) {
m_instance = new Singleton();
}
}
return m_instance;
}
//C++ 11版本之后的跨平台实现 (volatile)
std::atomic Singleton::m_instance;
std::mutex Singleton::m_mutex;
Singleton* Singleton::getInstance() {
Singleton* tmp = m_instance.load(std::memory_order_relaxed);
std::atomic_thread_fence(std::memory_order_acquire);//获取内存fence
if (tmp == nullptr) {
std::lock_guard lock(m_mutex);
tmp = m_instance.load(std::memory_order_relaxed);
if (tmp == nullptr) {
tmp = new Singleton;
std::atomic_thread_fence(std::memory_order_release);//释放内存fence
m_instance.store(tmp, std::memory_order_relaxed);
}
}
return tmp;
}
5.解析
对于一些类来说，只有一个实例是很重要的。比如：虽然系统中可以由许多打印机，但却只应该由一个打印假脱机；只应该有一个文件系统和窗口管理器；一个数字滤波器只能有一个A/D转换器；一个会计系统只能专用于一个公司。这应该是类设计者的责任，而不是使用者的责任。
在上述代码中，线程非安全版本对单线程程序是安全的，但对多线程是不安全的；对于线程安全版本，通过加“锁”使多线程安全，但锁的代价过高（针对只读情况）；对于双检查锁，在“锁”之前先检查也提高效率，降低代价。
6.结构
Singleton：
定义一个Instance操作，允许客户访问它的唯一实例；Instance是一个类操作；
7.总结
1.Singleton模式中的实例构造器可以设置为protected以允许子类派生。
2.Singleton模式一般不要支持拷贝构造函数和Clone接口，因为这有可能导致多个对象实例，与Singleton模式的初衷违背。
3.实现多线程环境下安全的Singleton，注意对双检查锁的正确实现。
二.享元模式（Flyweight）
1.动机
在软件系统采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价——主要指内存需求方面的代价。
2.作用
避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式来进行操作。
3.定义
运用共享技术有效地支持大量细粒度的对象。
4.代码
class Font {
private:
//unique object key
string key;
//object state
//....
public:
Font(const string& key){
//...
}
};
ß
class FontFactory{
private:
map fontPool;
public:
Font* GetFont(const string& key){
map::iterator item=fontPool.find(key);
if(item!=footPool.end()){
return fontPool[key];
}
else{
Font* font = new Font(key);
fontPool[key]= font;
return font;
}
}
void clear(){
//...
}
};
5.解析
享元模式对那些通常因为数量太大而难以用对象来表示的概念或实体进行建模。例如，文档编辑器可以为每一个字母创建一个Flyweight，每个Flyweight存储一个字符代码。每次需要调用Flyweight对象时，用户不用直接对其进行实例化，而是通过FlyweightFactory对象得到ConcreteFlyweight对象（创建前先判断该对象是否存在，如果存在，直接返回；如果不存在，则创建该对象，并将其放入对象池，最后返回。），这样保证对它们适当进行共享。
6.结构
7.总结
1.面向对象很好地解决了抽象性问题，但作为一个运行在机器上地程序实体，我们需要考虑对象地代价问题。Flyweigh主要主要解决面向对象地代价问题，不触及抽象性问题。
2.Flyweigh采用对象共享地做法来降低系统中对象地个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理。
3.对象的数量太大从而导致对象内存开销加大——数量大小需要根据具体应用情况评估。
转载：https://www.cnblogs.com/gql-live-laugh-love/p/11922386.html