http://electron64.blog.163.com/blog/#m=0&t=1&c=fks_084066087094087064080095087095085086087067087085095068084 Callback——最简单的callback 2012-01-21 22:06:01| 分类： SystemVerilog|字号 订阅 在RVM、VMM、OVM/UVM中，常常提到callback这个概念。指在事先设置好的地方留下一个接口，通过向这个接口添加一些函数对象，来达到不改变代码结构而动态修改代码行为。下面用systemverilog来举一个简单的callback例子： 1 class callback; 2 3 virtual task cb_pre_run( ); 4 $display(\); 5 endtask:cb_pre_run 6 7 endclass:callback 8 9 class widget; 10 11 callback cb_queue[$]; 12 13 function void add_cb(callback cb); 14 cb_queue.push_back(cb); 15 endfunction:add_cb 16 17 task run(); 18 // add callback here 19 foreach(cb_queue[i]) begin 20 cb_queue[i].cb_pre_run(); 21 end 22 $display(\); 23 endtask:run 24 endclass:widget 25 26 module top; 27 28 class ext_callback extends callback; 29 task cb_pre_run(); 30 $display(\); 31 endtask:cb_pre_run 32 endclass:ext_callback 33 widget w; 34 callback cb0; 35 ext_callback cb_ext; 36 37 38 initial begin 39 w = new; 40 cb0 = new; 41 cb_ext = new; 42 w.run; 43 w.add_cb(cb0); 44 $display(\); 45 w.run; 46 w.add_cb(cb_ext); 47 $display(\Callback\); 48 w.run; 49 end 50 51 endmodule; // top 在sysverilog中，没有函数指针的概念，因此必须将函数包装成为一个对象，就是上面例子中的callback class. 而为了在widget的对象中使用这个函数对象，必须事先在设计好的调用点对callback对象中的函数进行逐个调用（代码19-21行）。 widget的对象事先并不知道有多少callback对象，而是将所有的callback对象放到自己的一个callback对象队列中(cb_queue)。然后逐个对这个队列中的所有对象进行函数调用。 上面的程序编译执行后，结果如下： widget run.... =========== After Add base Callback base callback run widget run.... =========== After Add extention Callback base callback run ext callback run widget run.... 可以看出，在执行的过程中，可以对widget对象进行动态的添加callback，从而动态的改变widget对象的动作。 上面的例子非常简单，仅仅是输出一些讯息而已，有一些局限： 1. 这个callback结构并不能够真的改变widget对象的内部成员，以及处理
的数据内容，仅仅能够输出一些讯息。
2. 对每一个widget的对象，都需要单独添加相关callback对象，假如程序
中又创建了一个新的widget对象，那么这个对象的callback queue初始是空的，也就是没有callback。必须再次添加才能让这个新的widget调用相应的callback功能。
3. callback只有一个地方，可以扩展到多个地方。另外也可以使用function，
而不仅仅是task.
工厂模式的简单理解
首先,如果一个客户要用到一款手机,一般的做法是客户去创建一款手机,然后拿来用:
这时,客户需要知道怎么去创建一款手机,客户和手机就紧密耦合在一起了.为了降低耦合,就出现了工厂类,把创建手机的操作放到了工厂里面去,客户直接使用工厂的创建手机方法,传入想要的手机型号就行了,而不必去知道创建的细节.
随着手机种类越来越多,简单工厂模式出现了弊端,每次新加入手机品种,工厂类都要加入新的创建逻辑.这时我们就可以把工厂类定义成了接口,而每增加一种新的手机,就增加该手机对应工厂类的实现,这样工厂的设计就可以扩展了,而不必去修改原来的代码:
随着工厂规模的继续扩大,工厂开始生产充电器了.这时候工厂有二个系列的产品:手机和充电器.而手机必须使用对应的充电器才能使用.这时候分别使用一个手机工厂和一个充电器工厂都不能满足我们的需求,我们必须确认手机跟充电器的对应关系.我们把工厂改造一下,把手机工厂跟充电器工厂联系在一起:
抽象工厂模式 工厂方法模式 简单工厂模式