You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The __init__ methods of the various model classes show quite a bit of dublication once the econ_type parameter is integrated. In my opinion, the parameter could be included in the params dictionary. This would already make a lot of things much easier.
On top of that, there are parts of the code (e.g. setup of the self.nw attribute), that is shared for every model and is not affected by any specification. These parts should be included in the HeatPumpBase.__init__ method. Parts, that are individual to other classes should be added in their __init__ method, but only after calling the super().__init__ method. For this purpose it may also be useful. to create an "in-between" level of abstraction, e.g. a TwoWorkingFluidsHeatPump. which has a different __init__ compared to the SingleWorkingFluidHeatPump. These classes do not have any purpose other than the in-between level of abstraction.
The text was updated successfully, but these errors were encountered:
You are right, that there is a lot of duplication (even beyond the __init__ methods) that stems from the historical growth of the model collection. We were planning to add a HeatPumpCascadeBase class at some point, because their __init__ as well as the generate_state_diagram methods and likely more are pretty redundant, too.
The
__init__
methods of the various model classes show quite a bit of dublication once theecon_type
parameter is integrated. In my opinion, the parameter could be included in the params dictionary. This would already make a lot of things much easier.On top of that, there are parts of the code (e.g. setup of the
self.nw
attribute), that is shared for every model and is not affected by any specification. These parts should be included in theHeatPumpBase.__init__
method. Parts, that are individual to other classes should be added in their__init__
method, but only after calling thesuper().__init__
method. For this purpose it may also be useful. to create an "in-between" level of abstraction, e.g. aTwoWorkingFluidsHeatPump
. which has a different__init__
compared to theSingleWorkingFluidHeatPump
. These classes do not have any purpose other than the in-between level of abstraction.The text was updated successfully, but these errors were encountered: