Refactoring #162

Refactoring: investigate removal of ISingleton classes

Added by pospelov almost 8 years ago. Updated over 7 years ago.

Status:ArchivedStart date:28 Jan 2013
Priority:NormalDue date:
Assignee:herck% Done:


Target version:Sprint 13


Discuss if we really need singletons in our library and if not, remove them.


#1 Updated by herck over 7 years ago

  • Subject changed from Refactoring: get rid from MaterialManager singleton to Refactoring: investigate removal of ISingleton classes
  • Description updated (diff)
  • Status changed from New to Sprint
  • Assignee set to herck
  • Target version set to Sprint 13

#2 Updated by herck over 7 years ago

After analysis of the evilness of singletons, its alternatives and the specific places where we use them, I suggest the following refactorings:
  • FunctionalTestFactory and SampleFactory are ordinary factories (not Abstract Factories); this means we can easily replace the current Singleton implementation with just a static class implementation (or namespace with global factory functions).
  • MaterialManager: here it seems that an instance of the manager should only be unique with respect to a single 'working environment' (which is not yet present in the current framework, but these would resemble the workspaces of LAMB for example); enforcing the uniqueness with Singleton is thus not really a good idea; my suggestion is to put a MaterialManager object inside a SystemComponent object; such a SystemComponent object would encapsulate the system state for an application instance (or workspace) (note: the use of such a SystemComponent enables the removal of any state in the application's components)

A final remark: in none of the above situations was there any polymorphism in play; so certainly no need for singletons then...

#3 Updated by herck over 7 years ago

Actually, FunctionalTestFactory is better seen as a registry, which is initialized in main() of App and only passed to AppOptionsDescription. In this sense, users could create different sets of functional tests they want to run.
The use of SampleFactory as a globally accessible registry for some standard samples is left untouched for now. It only seems to be used for some non-IsGISAXS functional tests.
MaterialManager refactoring is also delayed to a new backlog item.

#4 Updated by herck over 7 years ago

  • Status changed from Sprint to Resolved

#5 Updated by herck over 7 years ago

  • Status changed from Resolved to Archived

Also available in: Atom PDF