The current structure of SLSim introduces a large amount of dependency between different classes "under the hood", with multiple classes sharing responsibilities. This reduces legibility for new contributors and makes extension / contribution harder.
Proposed Solution
Refactor SLSim, focusing on composition and dependency injection. The aim is to reduce dependence on specific class implementations and instead introduce "contracts" or "interfaces" between classes, i.e we initiliaze object A by passing an instance of object B, with object B providing certain methods and attributes that object A expects, thus filling the contract expected by object A.
This design pattern allows for drop-in replacements for different objects as long as they provide the expected behaviour. This makes tasks such as including new catalogs, simulation pipelines etc. easier, as one simply needs to include an adaptation from the relevant input to the format expected by an already existing part of SLSim.
The overall refactor is visualized in the UML diagram below.
To-Do List
[ ] Simplify LensPop via dependency injection of DeflectorBase and SourcePopBase. See #224 .
[ ] Merge DeflectorBase and SourcePopBase into singular Population class. The responsibilty of this class is to provide a draw of galaxy properties and transient metadata, with an end-goal of constructing Galaxy objects. See #225.
[ ] Create Catalog class to ingest catalogs or simulation outputs. May contain transient metadata. Used for Population instantiation. See #226.
[ ] Create Galaxy class that merges parts of Deflector, Lens and SourceBase covering the properties of a singular galaxy. Represents a singular galaxy with an optional transient. See #227.
[ ] Modify Lens to be composed of two Galaxy objects representing the lens and source, with the source Galaxy object having ownership over the transient, compared to current behaviour. See #228.
[ ] Extend LensPop to take a Sampler object at initialization, allowing for other sampling schemes besides the current uniform sampling from the lens and source populations. See #229.
Current Status
The current structure of
SLSimintroduces a large amount of dependency between different classes "under the hood", with multiple classes sharing responsibilities. This reduces legibility for new contributors and makes extension / contribution harder.Proposed Solution
Refactor
SLSim, focusing on composition and dependency injection. The aim is to reduce dependence on specific class implementations and instead introduce "contracts" or "interfaces" between classes, i.e we initiliaze object A by passing an instance of object B, with object B providing certain methods and attributes that object A expects, thus filling the contract expected by object A.This design pattern allows for drop-in replacements for different objects as long as they provide the expected behaviour. This makes tasks such as including new catalogs, simulation pipelines etc. easier, as one simply needs to include an adaptation from the relevant input to the format expected by an already existing part of
SLSim.The overall refactor is visualized in the UML diagram below.
To-Do List
LensPopvia dependency injection ofDeflectorBaseandSourcePopBase. See #224 .DeflectorBaseandSourcePopBaseinto singularPopulationclass. The responsibilty of this class is to provide a draw of galaxy properties and transient metadata, with an end-goal of constructingGalaxyobjects. See #225.Catalogclass to ingest catalogs or simulation outputs. May contain transient metadata. Used forPopulationinstantiation. See #226.Galaxyclass that merges parts ofDeflector,LensandSourceBasecovering the properties of a singular galaxy. Represents a singular galaxy with an optional transient. See #227.Lensto be composed of twoGalaxyobjects representing the lens and source, with the sourceGalaxyobject having ownership over the transient, compared to current behaviour. See #228.LensPopto take aSamplerobject at initialization, allowing for other sampling schemes besides the current uniform sampling from the lens and source populations. See #229.