Misnomer in the term "child class"

SystemVerilog
,
1

I have read some articles and videos here in Verification Academy, and what I noticed is that there seems to be a misnomer regarding the term “child class”. According to other websites, a child class is also called a subclass which means that it is the derived or inherited class from a base/parent class. For example, in the code below, class C is a child class of class P, since the former is extended from class P:


class P;

endclass : P

class C extends P;

endclass : C

However, some articles or videos here in Verification Academy also refers an instantiated class as a child class. Example:


class A;

endclass : A

class P;

A A_h; // Should we treat an instantiated class as a child of class P?

endclass : P

So, should we treat an instantiated class as a child of the class where it was instantiated?
Please correct me if I’m wrong.

Thanks.

2

In reply to Reuben:
The words parent and child are ad-hoc terminology. I recommend against using parent and child when referring to OOP inheritance. Parents create(construct) children and they are distinct objects from their parents. When you inherit property, that property becomes yours and all your property is part of one object.

The UVM uses terms parent and child to refer to relationships between objects when build a hierarchical tree/graph structure. The class uvm_component has a handle to its parent and handles to all its children so that you can traverse the hierarchical structure. This terminology is used in most programming languages and is independent of OOP.

3

An ongoing SV/UVM study/research brought me here, sorry for reviving this 8-yr old thread :blush:

I have a few follow-up questions :

  1. For simpler discussions like this, it is way more easier for me (a non-OOP expert) to understand that class A is a parent and class B is a child that inherits the properties of that parent (through the extend construct) and adds new properties for itself. Just like in the real world, a parent has black hair and so the child inherits the black hair plus other qualities/personalities that the parent doesn’t have.

Are there implications of using the terminologies parent and child in bigger/deeper/more technical discussions that’s why they should not be called as such?

  1. I somehow understood Dave’s explanation as this :
class plantA;
   int flower;
endclass : plantA

class plantB extends plantA;
  int thorns;
enclass : plantB

class garden;
   plantA  orchid;
   plantB  cactus;

   function new();
      orchid = new();
      cactus = new();
   endfunction // # so children = orchid and cactus, then parent = garden??
endclass : garden
4

These terms of parent/child in UVM are not like in real life…
It only helps to understand the hierarchical structure of the testbench, nothing more than that.

In OOP more accurate terms to use are:
Base class
Derived class
As Dave stated, it is better not to use parent and child when referring to OOP inheritance.

In your example:
plantB is a derived class of plantA.

The class garden contains the classes: orchid and cactus,
not even a parent…

1 Like
5

The example you show does not create parent/child relationships. There’s no way to traverse all the plants in the garden, or have a plant know which garden it belongs to. These are concepts that don’t require OOP (but can still take advantage of it).

I find that Object-Oriented Programming (OOP) requires a significant leap in education to master. Once you are over that leap, the terminology does not matter that much. But it helps others get over that leap.