Refactor to use Plugin Architecture
Release V2.0.1 includes a refactor of the original library to leverage the object oriented programming (OOP) paradigm. Specifically this refactoring abstracted geospatial processing into a group of classes collected in the terrainengine subpackage.
While this moves the needle considerably towards having a set of extendible and flexible geospatial engine classes, the architectural pattern of the package can be improved. Specifically by additional refactoring to replace the current implementation of terrain engines with a plugin approach. See the plugin_arhitecture branch for a half-baked example implementation.
This branch makes the following changes.
- Replaces the hardcoded
NameToTerrainEngineDict
with afactory
design pattern that allows user to register additional engines to this dictionary dynamically - Updates
validator
decorator to utilize the factory to create new class instance of TerrainEngines - Moves two implemented terrainengine classes into subpackage called
engines
- Implements
loader
function which dynamically loads anynon __file.py
file (plugin) into the factory.
The use of this factor and plugin approach not only eliminates the hardcoded specification of engines in the dictionary referenced by the validator, but also opens up the ability for third parties to develop their own TerrianEngines that can be installed into FCPGTools from separate repositories without the need to directly modify this source code using python's namespace packages.
Additional work is needed on plugin_arhitecture branch before it would be ready to merge in.
- Recommend adding a TerrainEngine Abstract Base Class which would force new engines to subclass and implement required attributes like
d8_format
- Update code base to remove references to the removed
NameToTerrainEngineDict
dictionary. - Additional validation testing to ensure geospatial processes still function under new implementation