Suggestion for improving the organization of the proyect folders and classes

[JoseLu2121]

After reviewing the folder and class organization of this project, I have noticed that there is a large number of classes included solely in the core, without belonging to any specific folder, which often makes it difficult to efficiently locate classes while using the software.
As a suggestion, I propose implementing a cleaner organization by creating new folders for trade, position, strategy, etc. Additionally, including classes such as Indicator or Analysis Criterion in their respective folders.

Implementing a model folder would also be a good proposal for this project, where all information related to the classes can be included.

[gelhaimer]

I think it's been already discussed within pr #1008.

What's been shared as a concern is the breaking aspect of such a change. The PR was then dropped because of that.

As you're the second one to bring that on the table, would it be interesting to consider this suggestion for the next major version ?

[TheCookieLab]

Yes, whenever we make breaking changes we need to do a cost benefit analysis of sorts to determine if the improvement outweighs the cost. While updating references isn't a big deal, multiply it by 1000 users and in aggregate it becomes a not insignificant cost.

That said we should not let breaking changes become an anchor on progress and dismiss changes out of hand. What kind of structure/organization are you proposing?

[sgflt]

"multiply it by 1000 users and in aggregate it becomes a not insignificant cost"

But cost per user is still insignificant. I would not block evolution in 0.** beta phase, where whole concept/architecture of library is still being profiled. And on other side cost of usage unfriendly API may be far more significant than breaking changes that improves usability.

As a newcomer I have strugled with UX and flow of creating real trading bot. It is easy to misconfigure indicators and use differentBar series than intended.

   new Indicator(barseries1) instead of  new Indicator(barseries2)

I'd like to hide as much implementation details as possible, so implementor of trading bot or backtesting does not need to know how all things wire together to work correctly.

The possible way that I'd like is to enforce usage of builders and hide public constructors from outer world usage:

interface BarSerie {
   IndicatorFactory indicatorFactory();
}


var barSerie  = BarSerie.buider()
  .duration(xxx)
  .name(xxx)
  ...
  .build()

// this facade hides serie reference transfer to indicator and eliminates space for mistakes
var indicatorFactory = barSerie.indicatorFactory()
var sma = indicatorFactory.sma(50);
var macd = indicatorFactory.macd(12, 26);

new Indicator(xxx) // compile error, use Factory please.

Another proposal of structure change is related to parsing helpers.
Why CsvBarSeriesParser is in example? :) It is useful easy implementation of backtests.
Why not create ta4j-csv module for CSV parsing? ta4j-json for json parsing?

It is easier to fetch data from yfinance and write csv in expected format than fetch data from yfinance to some own csv and then write own parser. Provision of basic parser would save me some time.

[sgflt]

TODO look closely at NumericIndicator, which I have found just now.