Why Amibroker CBT mode use object oriented programing paradigm?


Firstly let me clarify you that I’m not a computer scientist by education but someone who learned to write a code to get a better result for my investing process.

Now I’m trying to teach some of my friends about how to code in Amibroker custom backtester coding (CBT). And Yes some of them can do that. They understand how to code in CBT right now.

But the problem that I’ve found so far is that it’s quite hard to getting started to explain the reason why we have to use object oriented programming (OOP) such as objects, methods and properties in CBT instead of simple variables and functions like procedural programming style in AFL standard mode. So I’m trying to get more clear answer about it.

I’m not sure is it because it’s the way that is easier for Amibroker Team to develop a software or it’s because of it is easier to code from a user’s point of view? or because the backtesting infrastructure in CBT mode is different from a standard mode? or because there many more data types & functions to handle than that in standard mode (which is based on historical data). There’re many more hypothesis in my head right now but that’s just a guess.

So for this question, I think it should be best to ask the original Amibroker developer to get the best answer, Could you please explain to my why is that in CBT mode we have to adopt OOP paradigm to write a code and what is the beginning reason that makes Amibroker team decide to build CBT mode in an object oriented programming paradigm, So that when I get this more clearly I can tell the others more clearly and effectively about this topic. Because when people get the “Why” they can understand the reason of the “How”.

Thank you very much.

1 Like

Good question!

Object model was chosen for one reason - it fits the problem naturally.

Let me explain: during first phase of backtest, AmiBroker runs user’s formula to generate entry and exit signals for various symbols.
Each signal has the information about bar/datetime, symbol, price, size, fx rate, positions score and such things - these are properties of the signal.
The signals are sorted bar by bar using position score. When second phase of backtest starts and you are in custom backtest code you for each bar you have list of signals sorted by position score. So you can get them using GetFirstSignal/GetNextSignal calls.

The fact that this function returns object is very handy, because you have single entity with connected properties (name, size, price, etc) that can be manipulated further, passed to user function and so on.If you did not use object model, you would end up having hundreds of functions, like GetFirstSignalName, GetFirstSignalPrice, GetFirstSignalSize, GetFirstSignalScore. That would made formulas much longer and less clear.

In similar fashion, Trade is also an object with properties like symbol, entry date, exit date, position size, profit, commission, etc. And again GetFirstTrade/GetNextTrade functions return object that can be manipulated further and passed to functions as a single entity. It is very comfortable and brings clarity to the code.

People sometimes are afraid of objects and OOP. But objects exist in everyday life. A car is an object with methods accelerate, brake, gear up, gear down, turn left, turn right. It has properties like velocity, direction, weight, etc. They work together so if you call accelerate() method velocity increases.


Thank you for clarify my doubt Thomasz. It’s clear out many questions in my head :smiley:

I love the car example, this helps :slight_smile:

1 Like