I am trying to make my first project that can be unit tested. And it is amazing how I have to rewire my brain of some vicious coding styles.
This article got me the attention that Singletons are pathological liars
I am not trying to be radical on that, but I am used to an artifact that I am not sure how can i get rid of it
initialization ModelFactory.RegisterFactoryMethod('standard.contasmovimento', function(AParam: Variant) : TModel begin result := TModelContasMovimento.Create(AParam); end); end.
ModelFactory is a singleton, defined on its unit and part of the uses clause of this unit.
In my MVP structure I define each of the Models, Views and Presenters in its own unit (1 class 1 unit). All these units are available to be used, according the needs of each project. So, I use it like a parts catalog, according the project I add the units to the project and it gets automatically registered and ready to be used from the factories.
To solve the singleton problem i was thinking in move them to a framework class, so I could create the object at one point and then could use dependency injection to pass the framework object. All the factories and other environment stuff are sit there:
TMyFramework = class FModelFactory: IModelFactory; FViewFactory: IViewFactory; FPresenterFactory: IPresenterFactory; property ModeFactory: IModelFactory read FModelFactory; ...
My ideia is remove the singletons in a way that I can mock them in a test unit. With singletons in place I cant remove them easily for testing.
But that will make me loose the automatic initialization of each unit, an I rely on that to add the units. I don't want to manually create a list of available classes.
Is there a way to solve this situation?