dns icon indicating copy to clipboard operation
dns copied to clipboard

Expose Executer via factory class

Open skydiablo opened this issue 3 years ago • 6 comments

this allows to extend the give classes and more flexible for own use.

skydiablo avatar Mar 01 '22 14:03 skydiablo

my motivation is to benefit from the existing Resolver-Factory and also have access to the underlying executor, in detail to the query function. in the current implementation there is no way to get this in one shut, i have to copy-paste the complete factory class and inject my requirements. with this changes, i can just extend the factory class and override the points to met my requirements.

skydiablo avatar Mar 02 '22 07:03 skydiablo

my motivation is to benefit from the existing Resolver-Factory and also have access to the underlying executor, in detail to the query function. in the current implementation there is no way to get this in one shut […]

@skydiablo Very true, completely agree that this is needlessly complicated. Perhaps we can simplify this by simply exposing the ExecutorInterface from the Factory somehow? The ExecutorInterface can still be passed to the Resolver if you need to work with the ResolverInterfaec. This way, you should be able to invoke all methods using the same ExecutorInterface. WDYT?

clue avatar Mar 02 '22 08:03 clue

@clue just expose an function like createExecuter for internal and external use in the Factory-Class? Or What about an new Factory-Class still for the Executer itself and Resolver-Factory can use this Factory internal itself or just extends the Executer-Factory?

skydiablo avatar Mar 02 '22 09:03 skydiablo

just expose an function like createExecuter for internal and external use in the Factory-Class?

Sounds about right, but just an idea at this point and we'd have to take a look at this more in-depth.

Or What about an new Factory-Class still for the Executer itself and Resolver-Factory can use this Factory internal itself or just extends the Executer-Factory?

Extending implies an "is a" relationship, not sure "ResolverFactory is a ExecutorFactory" is reasonable. Composition over inheritance?

Not sure a dedicated ExecutorFactory is worth the effort, especially since we've started moving away from factory classes where possible to improve DX. I agree that adding this as a method to the ResolverFactory might not be perfect, but perhaps might make sense from a KISS perspective?

clue avatar Mar 03 '22 06:03 clue

divide the two section should the best case and the last change does not have any BC breaks. in case of DI, nobody say you have to use a factory-class, it will just create for you the "best" case of composition.

skydiablo avatar Mar 03 '22 09:03 skydiablo

push :P

skydiablo avatar Jun 08 '22 08:06 skydiablo