What kind of naming convention (if any) do we want for these top level abstract classes?

[TotoGaz]

PR #1418 implements an abstract base class (hence the ABC) CellBlockManagerABC on top of all the hierarchy.
Same for CellBlockABC. Those ABC classes are meant to describe the concept for the client code.

This trailing ABC does not exist yet in GEOSX.
When working at this refactoring, I used it as a reminder for myself.

The question is “What kind of naming convention (if any) do we want for these top level abstract classes?”

In GEOSX we currently have Base suffix convention to indicate that we have something on top of a hierarchy.
But quite often also this Base is meant to share/factorize code for the derived classes. (Which should not be the case for ABC classes).
And one may finish exposing too much: we may have to expose some factorized pre-computational method (or maybe simply a setter) that would not fit another context.
The idea of the ABC is to offer the contract and only the contract.

So how do we want to call these ABC classes. There are multiple options.

• Keep the ABC for abstractions, keep Base on centralized implementations.
• Forget about ABC, use Base on top instead. (CellBlockManagerABC becomes CellBlockManagerBase)
• Forget about ABC, use nothing instead. CellBlockManagerABC would become CellBlockManager, the derived implementations will have to find some descriptive name (can be Base?)
• Use namespace api (e.g. geosx::api::CellBlockManager) for the contracts.
• Any other suggestion?

Personally, I’m not too much in favor having devs manipulating Base classes.
Consider EventBase: devs manipulate a bunch of events, not eventBases. And we have an EventManager, not an EventBaseManager.