API: Major refactoring of all codes to use a strict Interface/AbstractBaseClass, Concrete style of naming

[imikejackson]

Major Refactoring of the SIMPLNX code base

The point of this PR is to create pure virtual Interfaces, Abstract classes and concreate classes where needed. Extract pure virtual where needed and create the intermediate abstract clases where needed.

[imikejackson]

Phase 15 Summary: Fix I-Prefix Naming Violations

Phase 15 completes the COM-style naming convention cleanup. All I-prefixed classes are now true pure interfaces — classes that had data members or concrete methods have been renamed to Abstract*.

---

Part A: Renamed 8 I-prefixed non-interfaces → Abstract*

These classes used the I prefix but were not pure interfaces (they had data members, concrete method bodies, or static helpers):

Old Name	New Name	Scope
IDataCreationAction	AbstractDataCreationAction	31 files, ~64 occurrences
IDataIO	AbstractDataIO	File rename + class rename
IGeometryIO	AbstractGeometryIO	File rename + class rename
IGridGeometryIO	AbstractGridGeometryIO	File rename + class rename
INodeGeom0dIO	AbstractNodeGeom0dIO	File rename + class rename
INodeGeom1dIO	AbstractNodeGeom1dIO	File rename + class rename
INodeGeom2dIO	AbstractNodeGeom2dIO	File rename + class rename
INodeGeom3dIO	AbstractNodeGeom3dIO	File rename + class rename

Part B: Promoted AbstractStringStore → IStringStore

AbstractStringStore had no data members and 12 pure virtual methods. Its only concrete methods were trivial iterator/comparison helpers delegating to pure virtuals. By project convention, it qualifies as a pure interface and was renamed to IStringStore.

---

Applied Across Repositories

• simplnx: 84 files changed (HDF5 IO classes)
• FileStore: 44 files changed (Zarr IO equivalents)
• Python bindings: Backwards-compatible alias added for IDataCreationAction

Post-Rebase Fixes

After rebasing onto the latest develop branches, several conflicts were resolved:

• StatusCode → Result<>: The develop branch changed geometry method return types from StatusCode to Result<>. Updated 4 Abstract geometry headers to match the new interface signatures.
• Constructor initializer lists: 7 concrete geometry .cpp files had constructor calls reverted to old I* names during rebase — fixed back to Abstract*.
• Constant qualifications: Fixed INodeGeometry2D::k_SharedEdgeListName → INodeGeometry1D::k_SharedEdgeListName (3 files) and INodeGeometry3D::k_SharedFacesListName → INodeGeometry2D::k_SharedFacesListName (2 files) — the standalone interfaces don't inherit from each other.
• getDataRefAs<IGeometry>: Fixed to getDataRefAs<AbstractGeometry> in ComputeFeatureSizes (2 files) — IGeometry is now a standalone interface, not part of the AbstractDataObject hierarchy.
• ComputeFeatureSizesFilter: Restored RectGrid to the allowed geometry types (lost during rebase conflict resolution).
• RectGridGeom::checkUpdatedIdsImpl: Fixed call from IGridGeometry:: to AbstractGridGeometry::.

[imikejackson]

Complete Summary of Name Changes in This Branch

This branch enforces a strict COM-style naming convention across the entire codebase:

• I prefix = pure virtual interface (no data members, no concrete methods)
• Abstract prefix = abstract base class (has data members and/or concrete implementations)
• No prefix = concrete class

Classes Renamed (Old → New)

Phase 2

Old Name	New Name
SegmentFeatures	AbstractSegmentFeatures
IParallelAlgorithm	ParallelAlgorithm

Phase 3

Old Name	New Name
IFilter	AbstractFilter

A new pure interface IFilter was extracted from the old IFilter (which had concrete methods and was therefore an ABC, not an interface).

Phase 6

Old Name	New Name
IGeometry	AbstractGeometry
IGridGeometry	AbstractGridGeometry
INodeGeometry0D	AbstractNodeGeometry0D
INodeGeometry1D	AbstractNodeGeometry1D
INodeGeometry2D	AbstractNodeGeometry2D
INodeGeometry3D	AbstractNodeGeometry3D

New pure interfaces IGeometry, IGridGeometry, INodeGeometry0D–3D were extracted from each.

Phase 10

Old Name	New Name
IParameter (near-pure)	AbstractParameter (base class portion)

IParameter was promoted to a true pure interface; concrete methods moved to AbstractParameter.

Phase 11

Old Name	New Name
IArray	AbstractArray
IDataArray	AbstractDataArray
INeighborList	AbstractNeighborList
IArrayThreshold	AbstractArrayThreshold
IJsonPipelineParser	AbstractJsonPipelineParser

New pure interfaces IArrayThreshold and IJsonPipelineParser were extracted from the old classes of the same name.

Phase 12

Old Name	New Name
IDataIOManager	AbstractDataIOManager

Phase 14

Old Name	New Name
DataObject	AbstractDataObject

A new pure interface IDataObject was extracted.

Phase 15

Old Name	New Name
IDataCreationAction	AbstractDataCreationAction
IDataIO	AbstractDataIO
IGeometryIO	AbstractGeometryIO
IGridGeometryIO	AbstractGridGeometryIO
INodeGeom0dIO	AbstractNodeGeom0dIO
INodeGeom1dIO	AbstractNodeGeom1dIO
INodeGeom2dIO	AbstractNodeGeom2dIO
INodeGeom3dIO	AbstractNodeGeom3dIO
AbstractStringStore	IStringStore

---

New Pure Interfaces Created

These are brand-new classes extracted during the refactoring:

Interface	Extracted From	Phase
IFilter	old IFilter (now AbstractFilter)	3
ISegmentFeatures	SegmentFeatures (now AbstractSegmentFeatures)	2
IPipelineNode	AbstractPipelineNode	4
IPlugin	AbstractPlugin	5
IGeometry	old IGeometry (now AbstractGeometry)	6
IGridGeometry	old IGridGeometry (now AbstractGridGeometry)	6
INodeGeometry0D	old INodeGeometry0D (now AbstractNodeGeometry0D)	6
INodeGeometry1D	old INodeGeometry1D (now AbstractNodeGeometry1D)	6
INodeGeometry2D	old INodeGeometry2D (now AbstractNodeGeometry2D)	6
INodeGeometry3D	old INodeGeometry3D (now AbstractNodeGeometry3D)	6
IDataStructure	DataStructure	7
IArrayThreshold	old IArrayThreshold (now AbstractArrayThreshold)	11
IJsonPipelineParser	old IJsonPipelineParser (now AbstractJsonPipelineParser)	11
IDataObject	DataObject (now AbstractDataObject)	14

IParameter, IStringStore, IDataStore, IListStore, and IDataFactory were existing classes promoted/confirmed as pure interfaces (Phases 9, 10, 15).

---

Python Backwards-Compatible Aliases

The following aliases were added to the Python bindings so existing scripts continue to work:

simplnx.DataObject         → simplnx.AbstractDataObject
simplnx.IArray             → simplnx.AbstractArray
simplnx.IDataArray         → simplnx.AbstractDataArray
simplnx.INeighborList      → simplnx.AbstractNeighborList
simplnx.IDataCreationAction → simplnx.AbstractDataCreationAction

---

Dead Code Removed

• src/simplnx/Utilities/Parsing/JSON.deprecated/ — 15 files, not compiled or referenced anywhere (Phase 13)

Serialization Compatibility

All renamed geometry classes preserve their original k_TypeName string values (e.g., AbstractGeometry::k_TypeName = "IGeometry") to maintain backward compatibility with existing .dream3d files.

[joeykleingers]

I think this is a really important PR and will be worth it in the long run, because it will be great to be able to tell at a glance which classes are interfaces and which are abstract, and it also just makes the whole codebase look more professional, just IMO.

[mmarineBlueQuartz]

I strongly agree with the renaming scheme, but a couple of the items listed under "potential concerns" sound like glaring red flags. Predominantly among them is the idea of forcing Qt into base simplnx. Things like nxrunner do not and should not require Qt to function. Forcing all of Qt in as a dependency just for easier plugin support seems a bit ham-fisted. The point on undefined behavior on destructor calls is also alarming, and I am not aware of any unit tests we might have that would check for that. The only classes that might trigger that off the top of my head would be in the DataStructure, so it could be important to check that it has detailed enough unit tests.

Although, this comment is based purely on the detailed description of the PR and will give a more complete review after looking over it more.

[imikejackson]

@mmarineBlueQuartz This PR is changing scope and is only about the renaming part.

To address your concerns about the original request, Qt's plugin loading was just being used as an example. In no-way-shape-or-form is Qt coming into simplnx. Been down that path once. Not going there again. :-)

[JDuffeyBQ]

I'm not necessarily opposed to the renaming though I am skeptical that it will actually aid us in readability/discoverability.

Some new classes were created that alter the existing object hierarchy. Particularly with the geometries having multiple inheritance. We may want to make larger changes to the hierarchy after, but I think it would require more discussion. Therefore I am against those changes. I think this PR should be just renaming.

For python there are some backwards compatibility aliases created but not for all. Additionally how long would we maintain those since this is a breaking change.

Additionally some new classes were created that don't seem to do anything specifically under json parsing?

[nyoungbq]

I poured over everything in the src/simplnx folder (aka the main infrastructure) and the renaming scheme looks good for the most part. A few things I noticed though:

• StringStore seems a little off compared to the other store counterparts. I think it needs to be split into an Abstract and I class rather than renaming it to I since it breaks the paradigm. I would also be okay leaving it as just an Abstract class too
• Many of the I implementation files (.cpp) need to be removed and destructor defaults moved to header to bring it inline with typical paradigm used around the project
• The comments in the Geometry folder need their comments updated to reflect the StatusCode -> Result<> changes

Edit: After seeing Jareds feedback I also want to offer that I absolutely agree with the statement about the geometry heirarchy. I think it is definitely worth discussing re-architecting the polymorphism. Multiple inheritance incurs a definitive cost with the runtime vtable look up, so we need to make sure that frequently called methods do not incur this cost. Ideally we remove the diamond problem entirely to ensure there is no runtime cost, but I understand this may not be possible and as such a wider discussion is needed.

[nyoungbq]

since implementation has all been moved to AbstractGeometry this file should be removed as it is functionally empty

[nyoungbq]

remove file, implementation moved to abstract class

[nyoungbq]

Suggested change

#include <optional>

unused include

[nyoungbq]

remove file, no implementation in I files. I files are pure virtual so no .cpp file needed

[nyoungbq]

remove file, no implementation in I files. I files are pure virtual so no .cpp file needed

[nyoungbq]

I think that the Abstract and I concept may be confused on this one

[nyoungbq]

destructor definition is default so move to header. remove file, no implementation in I files. I files are pure virtual so no .cpp file needed

[nyoungbq]

remove file, no implementation in I files. I files are pure virtual so no .cpp file needed

[nyoungbq]

move default destructor to header. remove file, no implementation in I files. I files are pure virtual so no .cpp file needed

[nyoungbq]

move default destructor to header. remove file, no implementation in I files. I files are pure virtual so no .cpp file needed