热度 10| |||
定义一系列算法,并把他们封装起来,其他门可以相互替换。(设计模式:可复用面向对象软件的基础)
Strategy模式强调的是数据与操作的分离,算法调用主体通过将操作抽象化,从而使得相同类型的算法可以被容易的替换,从而实现软件架构的稳定性。
类似日常家务中包含洗衣服的操作,但具体洗衣服可能是手洗,机洗,干洗,通过将具体操作方法抽象为“洗衣服”,使得软件主体不再关注具体如何洗。
在软件设计中,根据软件的不同需求场景,可能是性能,高效,等,采用不同的算法,来满足软件需求,使用strategy模式,可避免软件主体架构的变动。
在实现上,常表现为算法调用主体类包含算法类基类的成员变量。在类的关系上为表现为组合。
二,Uvm中的callbackUvm中的callback 并非典型的strategy模式,是对其的一种扩展,个人理解如下;
1. 成员算法类的存储方式不是单个而是存储了算法集合(pool/queue),如此可动态添加更多的算法进行调用,特别的在需要增加操作时,不用修改已有的算法实现,只需新增一个算法类,并添加到算法集合中即可。(在uvm中通过uvm_callback#(type T, type CB)::add实现)
2. 调用主体不再是单一类与对象,而是通过以<调用者类型,callback类型>为参数的模板类实现调用者类群。采用此种方式当特定实例在调用算法是,将会直接有对用类型参数的类执行。在一定程度上加快了搜索(不必遍历类群挨个进行匹配)
抛开繁杂细节,uvm callback 拥有strategy 模式的核心, 算法基类成员变量:m_pool, m_tw_cb_q;
注:uvm 的callball 有两种形式,以一种调用者类型相关的,一种特定对象的,即可以为特定对象添加callback
三,若干API1. Uvm_register_cb
通过在component声明中调用Uvm_register_cb,将会在component中添加callback类型成员变量,其中实际的算法存储容器为
uvm_pool#(uvm_object,uvm_queue#(uvm_callback)) m_pool; |
uvm_queue#(uvm_callback) m_tw_cb_q; |
2. uvm_callbacks#(T,CB)::add(T obj, uvm_callback cb, uvm_apprepend ordering=UVM_APPEND)
在声明算法容器后,将通过add想容器中添加具体操作算法
3. Uvm_do_callbacks
Uvm callback 的执行通过Uvm_do_callbacks,其中将首先对需要调用的算法进行查找,而后通过迭代器对指定类型的callback 进行遍历调用
在进行算法查找是设计如下两个核心函数
(1) m_get_q
包含度对象无关和类型相关的所有callback实现的搜索
(2) m_get_tw_cb_q
对调用者类型相关的callback的搜索,不针对特定对象