Can Composites and Components be abstract classes?

[drewj-usnctech]

I've made a couple issues about adding new Composite subclasses into ARMI (#1134 #1030 #1088) and we've also been exploring adding new Component types to handle new geometries. We know there are methods that we should add to make these classes be more compliant with the ARMI data model, but the process of finding them really boils down to what raises a NotImplementedError somewhere in the armi run stack or in tests. However, if Composite and Component were abstract classes, we could find out as soon as something tried to create our new class.

It's a little trickier to make Composite and Component abstract because of the metaclass mechanics on CompositeModelType and ComponentType. It's not impossible as you would need to make those metaclasses a subclass of abc.ABCMeta. I added the following in #1088

class AbstractCompositeMetaclass(ABCMeta, CompositeModelType):
    """Metaclass that allows for abstract composites"""


class AbstractComposite(ABC, Composite, metaclass=AbstractCompositeMetaclass):
    """Composite that can have abstract methods
    Useful for enforcing interfaces across generic subclasses
    """

The next step is to find out what methods should be marked as abstractmethod so subclass implementers know what they need to do. The following stand out

• Component.getBoundingCircleOuterDiameter
• Component.getArea
• Component.getVolume
• Component.getComponentArea :: maybe redundant w/ Component.getArea

Most of the abstract methods would be on the leaves of the tree (Component) because other members of the tree just need their children to provide some base functionality that can be used. Like Block.getMass sums the mass of the children, and eventually requiring Component.getMass to be properly defined