SystemVerilog OOP Mastery · All levels

Abstract & Interface Classes: Tricky Q&A

Rapid-fire interview Q&A for Abstract & Interface Classes.

Section Q&A

Rapid-fire interview questions for Abstract & Interface Classes. Answer out loud, then check yourself.

Q1. If a base class is declared `virtual class` but has no pure virtual methods, why keep it virtual?

Answer: Marking it virtual still prevents direct construction and communicates design intent: this type is a framework scaffold, not a concrete runtime object. Teams use this to force subclasses for protocol specialization while still sharing fields and default methods.

Trap: Assuming `virtual class` matters only when pure virtual methods exist.

Q2. Can a class that `implements` an interface class skip one method and rely on inherited defaults?

Answer: Only if the full method implementation is already inherited from its single base class. If any required interface-class method remains unimplemented in the effective class body, the class is abstract and cannot be instantiated.

Trap: Believing `implements` is documentation-only and not enforced by elaboration rules.

Q3. Why doesn't SystemVerilog support multiple class inheritance like C++, and what does that imply for verification code?

Answer: The language avoids method-resolution ambiguity and duplicated base-state complexity (diamond problems) that are hard to reason about in simulation-heavy environments. Verification code should combine one `extends` chain with multiple `implements` contracts plus composition helpers to keep behavior explicit and debuggable.

Trap: Trying to stack behavior by creating deep single inheritance chains that mimic unrelated roles.

Q4. When emulating multiple inheritance, should shared helper objects be static singletons?

Answer: Usually no. Behavioral helpers often need per-object state (IDs, counters, policy knobs), and singleton sharing can create hidden cross-test coupling. Prefer per-instance composition unless the helper is stateless and thread-safe by construction.

Trap: Using global helper instances by default, then debugging non-deterministic test interference.