Abstract driver & monitor: reasonableness

good day, everyone!
i have a master-slave interface (say, APB) and i need to make agents for both ends of this interface. Is it a good idea to make abstract classes for driver and monitor and then, using configuration object of agent, replace them with concrete classes (actual driver or responder)?
Thank you for your reply.

>> Abstract classes

Generally created when you find any common function/tasks across two components.

For example, In Master Driver component and Slave driver component, we need function called drive_dut() to send transaction to interface this we can include in the abstract class.

drive_dut is simple example I gave but if you more commmon tasks/functions you can add them.

Here now ahb_abstract_drv class puts restriction on the user to implement those common tasks/functions for that interface.

this methodology is generally followed when you are trying to build components from scratch.

>> Overriding the driver using configuration object::

Lets say you already have driver implemented(by someone) you just want to modify something some internals then extend driver class and override with new driver.

Now being said that all these, the proposal you gave also works, but I rarely engineers using that approach.

regards,
Santosh

In reply to santosh:

thank you, santosh. it helped)