从下面一段代码，我们猜一下最终的输出是什么？
那我先把运行结果丢给大家，然后从源码一一来分析为什么是这样。
get_name() 在uvm_object.svh中定义了这个virtual函数，经过追踪发现这个函数并没有被重写过。
- 经过上述代码，我们能清楚的看到get_name()其实就是我们new(create)的时候对应的string name.并不是我们声明的名称。
- 当然get_name()除了从new(string name)以外，也可以通过set_name()的方式获取，但是并不常用。
- 对比开头的那段代码，我们可以得出get_name()返回的应该是“my_component_create”,而不是“my_component_def”.
get_full_name()，在uvm_object.svh中定义了这个virtaul函数，并且在外部被从写过。
- 虽然get_full_name()这个函数会在uvm_object.svh以外的函数进行重新，但是我觉得这里的注释很有意义。解读一下就是return hierarchy name.并且继承自uvm_object和uvm_component的意义是不同的。
- uvm_component.svh里面重写了get_full_name(),但是直白的看好像并不能看出来什么，但是再仔细看，你就可以看出来uvm_component的new函数其实将其调用的。
- get_full_name()其实就是get_name()的拼接！！！！
那既然说到这里，那就要想一个问题，UVM里面有两大类一类是uvm_component派生来的，比如树形结构的uvm_driver，另一类的uvm_object派生来的，比如说uvm_sequence.,上面我们看到派生自uvm_component的get_full_name()其实是在uvm_component的new函数完成了拼接，那么派生自uvm_object的类呢？get_full_name()又会表现出什么行为呢？
其实通过源码分析，我们也可以知道，对于派生自uvm_object的类，get_full_name()其实也就是调用的get_name().所以我们的uvm_sequence/uvm_sequence_item这些其实都是没有生命的(也就是说这些其实不是uvm树的节点，所以并没有Hier)组件其实get_name()=get_full_name().
get_type_name()
通过源代码我们可以看出，如果派生自uvm_component/uvm_object的函数没有重写get_type_name()的话，那么结果应该是源代码中的值，但实际上从第一张图上，我们就可以清楚地发现，其实跟我们的预期是不一样的，那么问题出在什么地方呢？
没错，就是`uvm_componet_utils(my_compont)
我们接下来看看这个宏做了什么，如果不看源码，我们知道这个宏其实就是将component注册到factory中。下面我们来看一下这个宏的展开的模样。
- m_uvm_component_registry_internal()这个跟factory相关，这里不展开介绍。
- m_uvm_get_type_name_func()其实已经一目了然了。
- 由此我们也可以猜测，扩展自uvm_object的`uvm_object_utils()应该也有类似的定义。
- get_type_name()其实就是返回的class的名称。也就是`uvm_componet_utils()/uvm_object_utils()注册的名称。
小结：
- get_name():返回的是type_id::create(string name,null)里面对应的name.
- get_full_name():根据是不是UVM树的节点分为两种情况，一种是扩展自uvm_component的时候，返回的是uvm_test_top.开始的路径图，也就是get_name()的拼接，另一种情况是扩展自uvm_object的时候，get_full_name()=get_name().
- get_type_name():返回的是class的名称，也就是uvm_component_utils()/uvm_object_utils()里面对应的name()