I split the gcode package into three internal sections.
The gcode package, define a series of interfaces to implement an unaddressable gcoder and an addressable gcoder. This last, in the form of the generic using an AddressType to define the data types, allows generating an addressable gcoder.
At the same time, the gcode package defines an interface to implement a factory struct. This way, the users can create a struct that implements the factory interface and inject him where it is needed.
The other two sections are packages that depend on the gcode package and implement the interfaces to generate gcode structs.
The unaddressable gcode package contains the model to handle a gcode without an address element. It includes a constructor New.
The addressable gcode package contains the generic model to handle a gcode that contains an address element. It includes a constructor New.
Both consume the interfaces defined in the gcode package.
This division allows:
implement DI using pattern factory with GcoderFactory interface
improve separation of responsibilities
reimplement self gcode struct using the interfaces providers to gcode package
centralize interfaces into a simple package
using a simple package constructor or DI
decouple dependencies of the implementations
Improve the design of options recommended by the community
However, I found that this pattern contains some features that might carry issues when a programmer tries to implement them.
I will write about most detail that in another occasion, but I can resume on a series of topics:
Passing a reference to the object that we want to instance and configure allows the caller can be access to this instance before that is terminated.
The package export the configuration functions that only are used during the construction or update of the object. That generates noise in the package.
The set of callbacks does not handle errors by default.
The version that allows restoring configuration only works whit the last config established.
So, I create a sketch that allows for improving the first and second topics. The proposal achieves wrapping the reference to the object that we want to instance (protecting him from any modification out context) and exposes only the specific methods to configure only properties that I considered from an interface customizable. At the same time that improves the experience of the coder to consume this library.
Going to apply some changes. There are two that are most important.
gcode package with DI and flex
the new focus of the gcode package only defines interfaces. It allows combining DI and factory patterns
I split the gcode package into three internal sections.
The gcode package, define a series of interfaces to implement an unaddressable gcoder and an addressable gcoder. This last, in the form of the generic using an AddressType to define the data types, allows generating an addressable gcoder. At the same time, the gcode package defines an interface to implement a factory struct. This way, the users can create a struct that implements the factory interface and inject him where it is needed.
The other two sections are packages that depend on the gcode package and implement the interfaces to generate gcode structs.
The unaddressable gcode package contains the model to handle a gcode without an address element. It includes a constructor New.
The addressable gcode package contains the generic model to handle a gcode that contains an address element. It includes a constructor New.
Both consume the interfaces defined in the gcode package.
This division allows:
Improve the design of options recommended by the community
i use and improve the design of options recomend with wraping and protecting the new instance that i wish to config
The block package requires constructors that implement optionally some values. So, I need a pattern to handle configurations.
I found Self-referential functions to design options And many articles related.
However, I found that this pattern contains some features that might carry issues when a programmer tries to implement them.
I will write about most detail that in another occasion, but I can resume on a series of topics:
So, I create a sketch that allows for improving the first and second topics. The proposal achieves wrapping the reference to the object that we want to instance (protecting him from any modification out context) and exposes only the specific methods to configure only properties that I considered from an interface customizable. At the same time that improves the experience of the coder to consume this library.