Objects derived from AcDbAssocAction class are used to represent operations/behaviors in the drawing. When actions are evaluated, they take input, perform an algorithm, and produce output. The action owns a set of AcDbAssocDependencies that define which objects in the drawing the action depends on, either by using (reading) the properties of these objects, by changing (writing) properties of these objects, or both. We are saying that the action has "read only" dependencies, "write only" dependencies or "read write" dependencies on the objects. A single action can own any number of dependencies and can therefore use and modify any number of objects.
When an action has read dependencies on some objects and write dependencies on some other objects, it effectively defines a parent-child relationship between these objects. The objects the action reads from are the parent objects, and the objects the action writes into are the child objects. An example the parent-child relation may be an associative fillet action that has read dependencies on the filleted curves (that may be represented by AcDbCurve entities) and a write dependency on the fillet arc (that may be represented by an AcDbArc entity). The arc object is a child of the two filleted curves and is fully defined by the two curves and by the fillet radius. Changing the filleted curves or the fillet radius and evaluating the associative fillet action recalculates the fillet arc, but changing the fillet arc does not change the filleted curves. If the fillet arc is changed, this change is ignored and the fillet arc is reversed back to what it was.
The functionality of custom actions is implemented in classes derived from AcDbAssocActionBody. AcDbAssocAction is a hard owner of an AcDbAssocActionBody object. The reason for this split is to better handle situations when the custom application is not loaded. In this case the AcDbAssocAction objects will still be present and functional and the connectivity information about which actions depend on which objects will still be available. Only the AcDbAssocActionBody objects will become proxies and the custom functionality is going to be unavailable. You might have also noticed that the AcDbAssocAction class does not have any virtual methods and therefore it is no possible to override its methods. On the other hand the AcDbAssocActionBody class has numerous virtual methods whose name ends with "Override" suffix. These virtual methods correspond to the non virtual methods on the AcDbAssocAction class. They are to be overridden by custom applications to implement the custom functionality.
The main method of the AcDbAssocAction class is the evaluate() method. It calls the evaluateOverride() method of the owned AcDbAssocActionBody object that performs the algorithm of the action. The argument to the evaluate() method is a non null pointer to an object derived from AcDbAssocEvaluationCallback class that lets the action notify about the progress of its evaluation.