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
Is your feature request related to a problem? Please describe.
Interface changes made in 1d36ab3
in my opinion break single responsibility principle and cause performance issues, circa 5% slow down.
These methods are not related to BarSerie, but number type used in BarSerie, which should not leak to interface, because it is implementation detail.
/** * @return the related bar series */BarSeriesgetBarSeries();
/** * @return the Num of 0 */defaultNumzero() {
returngetBarSeries().zero();
}
/** * @return the Num of 1 */defaultNumone() {
returngetBarSeries().one();
}
/** * @return the Num of 100 */defaultNumhundred() {
returngetBarSeries().hundred();
}
/** * @return the {@link Num Num extending class} for the given {@link Number} */defaultNumnumOf(Numbernumber) {
returngetBarSeries().numOf(number);
}
Describe the solution you'd like
Remove these methods form Indicator nad BarSerie interfaces and provide closer encapsulation for used datatype,
which may provide constants ZERO, HUNDRED, ONE etc. in specific data type and save about 5 % of runtime.
BarSerie and Indicator may provide method NumFactory numFactory() for parsing nonconstant values.
From my perspective this proposal also cleans internal implementation flow. From barSerie.giveMeNumber to barSerie.giveMeFactory.giveMeYourNumberWhichMayBeCached.
From User perspective it elimitatest question "Why BarSerie returns numbers?".
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Interface changes made in 1d36ab3
in my opinion break single responsibility principle and cause performance issues, circa 5% slow down.
These methods are not related to BarSerie, but number type used in BarSerie, which should not leak to interface, because it is implementation detail.
Describe the solution you'd like
Remove these methods form Indicator nad BarSerie interfaces and provide closer encapsulation for used datatype,
which may provide constants ZERO, HUNDRED, ONE etc. in specific data type and save about 5 % of runtime.
BarSerie and Indicator may provide method
NumFactory numFactory()
for parsing nonconstant values.From my perspective this proposal also cleans internal implementation flow. From barSerie.giveMeNumber to barSerie.giveMeFactory.giveMeYourNumberWhichMayBeCached.
From User perspective it elimitatest question "Why BarSerie returns numbers?".
The text was updated successfully, but these errors were encountered: