Qt的元对象(Meta-Object)系统

Qt中的元对象系统全称Meta Object System，是一个基于标准C++的扩展，为Qt提供了信号与槽机制、实时类型信息、动态属性系统。元对象系统基于QObject类、Q_OBJECT宏、元对象编译器MOC实现。
A、QObject 类
作为每一个需要利用元对象系统的类的基类。
B、Q_OBJECT宏
定义在每一个类的私有数据段，用来启用元对象功能，比如动态属性、信号和槽。
在一个QObject类或者其派生类中，如果没有声明Q_OBJECT宏，那么类的metaobject对象不会被生成，类实例调用metaObject()返回的就是其父类的metaobject对象，导致的后果是从类的实例获得的元数据其实都是父类的数据。因此类所定义和声明的信号和槽都不能使用，所以，任何从QObject继承出来的类，无论是否定义声明了信号、槽和属性，都应该声明Q_OBJECT 宏。
C、元对象编译器MOC (Meta Object Complier)，
MOC分析C＋＋源文件，如果发现在一个头文件(header file)中包含Q_OBJECT 宏定义，会动态的生成一个moc_xxxx命名的C++源文件，源文件包含Q_OBJECT的实现代码，会被编译、链接到类的二进制代码中，作为类的完整的一部分。

元对象系统引用反射的基本思想。所谓反射，就是指对象成员的自我检查。使用反射编程（reflection programming），就可以编写出通用的操作，可对有各种不同结构的类进行操作。使用通用的值存储器QVariant，就可以按照一种统一的方式来对基本类型和其它的普通类型进行操作。 
简而言之，所谓的反射模式，就是通过自己来查看所有的属性，通过自己的元对象属性来访问自己的全部属性，为什么不直接使用成员函数呢？使用成员函数过于繁琐，通过元对象对应的方法可以快速访问对象的属性
反射机制无疑会增加额外的存储空间，在效率上有所牺牲，而且在普通程序中没有用武之地，为了保持几乎与C同等的效率，C++不提供反射机制也有一定的道理。

但对于大型框架或类库来说，反射机制有时很有必要，它会增加程序的灵活性和动态性，例如动态加载类、解耦等。最明显的一个例子是编译器的智能提示，当输入完对象的名称，再输入.或->，就会提示该对象拥有的变量和函数，这是反射机制的典型应用。

元对象系统主要是为了实现信号和槽机制才被引入的，不过除了信号和槽机制以外，元对象系统还提供了其他的一些特性：

• QObject::metaObejct()函数可以返回一个类的元对象，它是QMetaObject类的对象。
• QMetaObject::className()函可以在运行时以字符串形式返回类名，而不需要C++编译器原生的运行时类型信息(RTTI)的支持。
• QObject:：inherits()函数返回一个对象是否是QObject继承树上一个类的实例的信息。
• QObject::tr()和QObject::trUtf8()进行字符串翻译来实现国际化
• QObject::setProperty()和QObject::property()通过名字来动态设置或者获取对象属性
• QMetaObject::newInstance()构造该类的一个新实例

通过QMetaObject来获取对象的属性
通过qobject_cast来进行对象类型的识别
通过Q_PROPERTY宏来描述QObject的属性。
通过QVariant类可以进行属性的访问
可是这些东西都有什么用呢？唯一让我觉得有用的就是那个信号，但是它只是个信号，具体做什么事情，全有你自己控制。那就是，模式对属性进行更加的控制。

qobject_cast()动态转换QObject类的类型。qobject_cast()函数和标准C++的dynamic_cast()功能类似，只是其不需要RTTI的支持，而且可以跨越动态连接库的边界。它尝试将它的参数cast成尖括号内的对象类型，如果对象是正确的类型（运行时决定）则返回非零，否则返回0，说明对象类型不兼容。

当某一个Object emit一个signal的时候，它就是一个sender,系统会记录下当前是谁emit出这个signal的，所以你在对应的slot里就可以通过sender()得到当前是谁invoke了你的slot，对应的是QObject->d->sender。
    有可能多个Object的signal会连接到同一个signal(例如多个Button可能会connect到一个slot函数onClick()),因此这是就需要判断到底是哪个Object emit了这个signal，根据sender的不同来进行不同的处理。这时就要用到qobject_cast()。

例如，假设MyWidget继承自QWidget，同时也声明了Q_OBJECT宏，

          QObject *obj = new MyWidget;

QObject类型的变量obj实际上指向一个MyWidget对象，因此我们可以这样进行类型转换：

          QWidget *widget = qobject_cast(obj);

到MyWidget的转型可以成功是因为qobject_cast()并没有对Qt内建对象和定制的扩展对象分别对待。

          QLabel *label = qobject_cast(obj);     // label is 0

另一方面到QLabel的转型则会失败，指针会被设置为0。这样使得我们可以在运行时根据对象类型，对不同类型的对象进行不同的处理：

   if (QLabel *label = qobject_cast(obj))

{       label->setText(tr("Ping"));   }

 else  if (QPushButton *button = qobject_cast(obj))

{      button->setText(tr("Pong!"));   }

尽管我们可以在不用Q_OBJECT宏和原对象信息的情况下仍旧使用QObject作为基类，但是像信号和槽以及其他这里描述的特性将无法使用。从元对象系统的观点来看，一个没有元对象代码的QObject子类和其最接近的有元对象代码的祖先是等同的。这也就意味着，QMetaObject::className()将不会返回你的类的真实的名字，而是该类某一个祖先的名字。

 

moc（Meta-Object-Compiler）元对象编译器，从概念上和其他编译器一样来理解就好了。signals、slots关键字并不是标准C++里面的东西，代码最后要交给C++编译器，那么就需要把这部分转化成C++编译器认识的东西，这个工作就是moc来完成了。这里需要注意的是，moc过程是发生在预编译之前的，简单说就是moc之后每一个包含Q_OBJECT宏头文件，都会根据该头文件里面的signals、slots、Q_MENU l来生成以moc_XXXX(自定义类名)的.cpp文件，我们常用IDE的构建生成的.o文件，就是最终的目标文件（包含moc生成的cpp）。

 

信号槽是观察者模式的一种实现，特性如下：
A、一个信号就是一个能够被观察的事件，或者至少是事件已经发生的一种通知；
B、一个槽就是一个观察者，通常就是在被观察的对象发生改变的时候——也可以说是信号发出的时候——被调用的函数；
C、信号与槽的连接，形成一种观察者-被观察者的关系；
D、当事件或者状态发生改变的时候，信号就会被发出；同时，信号发出者有义务调用所有注册的对这个事件（信号）感兴趣的函数（槽）。
信号和槽是多对多的关系。一个信号可以连接多个槽，而一个槽也可以监听多个信号。
信号槽与语言无关，有多种方法可以实现信号槽，不同的实现机制会导致信号槽的差别很大。信号槽术语最初来自 Trolltech 公司的 Qt 库，由于其设计理念的先进性，立刻引起计算机科学界的注意，提出了多种不同的实现。目前，信号槽依然是 Qt 库的核心之一，其他许多库也提供了类似的实现，甚至出现了一些专门提供这一机制的工具库。
  信号槽是Qt对象以及其派生类对象之间的一种高效通信接口，是Qt的核心特性，也是Qt区别与其他工具包的重要地方。信号槽完全独立于标准的C/C++语言，因此要正确的处理好信号和槽，必须借助于一个成为MOC（Meta Object Compiler）的Qt工具，MOC工具是一个C++预处理程序，能为高层次的事件处理自动生成所需要的附加代码。