gary9204
commented
4 years ago Work on AdaptText and AdaptValue revealed a defect in the organization of Factsheet code. At present, the code implements interfaces and adapters at the Factsheet class level (for example, AbstractOutline and AdaptTreeStore). This implementation couples Factsheet functions and GTK wrappers. Classes AdaptText and AdaptValue imply it would be better to implement an adapter for each GTK object used. The adapters would be collected in a package with a consolidated API. The package would depend on GTK and not Factsheet classes. Hence, the package could be imported by model, view, and control classes without circular imports. It seems the package would minimize the need for abstract interfaces. More coherent adapters would simplify defining generic classes and inheritance
Consequently, the next steps are to refactor adapters per-GTK object and update Factsheet model, view, and control classes.
Interface classes should be abstract definitions for interactions between model and view components. Adapter classes should encapsulate dependencies on GTK. Model classes should rely on adapter classes to hide GTK-specific implementation details.
Interface, adapter, and model classes have evolved. They do not match the separation of responsibilities The goal of this issue is to harmonize classes with the responsibilities above.