-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor/enhance Calculator class #26
Comments
In my opinion static methods/variables would be a nicer solution, which results in lesser function calls when reading calculator config options and would improve (or rather ease) the overall readability. Moreover using a private or protected constructor, instantiating this class is prohibited. |
Are your ideas based on the assumption that Calculator will be (and remain) the top-level class? I imagine that someday there will be a GUI and one of the valid workflows for experimentation should be to clone the currently visualized network, maybe do some minor adaptation and analyze it with another, potentially different calculator (configuration). All without closing the original calculator. |
Exactly, if more calculators can existin future then we cannot use a static class, we have to store calculator instances in a dispatcher. For this purpose static approach cannot be used. In that case I would now just remove getinstance and later introduce a dispatcher that can hold several Calculator instances identified by an id. |
Dispatching to identifiable calculators sound like the most future-proof solution to me. |
I tried to remember why there are separate configurations for the calculator and the analysis. That was not always the case, I introduced that a long time ago. The calculator configuration only has/had static member variables whereas the analysis configuration does/did not. The overall change was motivated by two aspects:
|
Did a look. We will also need a builder, to ensure that all mandatory parameters are set before using the class. So the builder will be static and will have a build method to create the instance. Also we need the dispatcher as the container for the Configuration but somehow also need to pass the id of the Configuration. Otherwise we will not be able to reach it from any classes. |
Sure, take the time needed for a good design. |
Calculator is a singleton at the moment, all methods can be used via getInstance. If we can agree that it will be always a singleton, we could change all methods and variables to static. Do a pheasability check first, also check whether in later releases we could you two different calculators paralelly ( in that case it cannot be a singleton anymore).
The text was updated successfully, but these errors were encountered: