Plugin Interface for Trading Strategies | Toss Auto-Trading Dev Journal #12 (Phase 2-3)

🌐 한국어로 보기

For readers new to this series: this bot trades through Toss Securities’ brokerage API — think of it as a Korean-market equivalent of Alpaca or Interactive Brokers. The first two items in Phase 2 were already done: a standalone strategy.py module, and support for watching several symbols at once. The last piece was making room for future strategies — moving averages, RSI, whatever comes next — without everyone reinventing the class structure each time.

Defining a shared contract with ABC

I built TradingStrategy on top of Python’s abc.ABC, with exactly one abstract method: should_buy(current_price). Implement that one method, and a strategy can plug straight into the engine.

from abc import ABC, abstractmethod
from collections import deque

class TradingStrategy(ABC):
    @abstractmethod
    def should_buy(self, current_price: float) -> bool:
        ...

Refactoring ThresholdBuyStrategy — behavior untouched

The existing ThresholdBuyStrategy now inherits from TradingStrategy. The one rule I held myself to: not a single line of the actual buy logic changes. It still fires when the current price (against a placeholder symbol like 005930) drops to or below the target — only the inheritance changed.

A demo MovingAverageStrategy

To prove the interface actually generalizes, I added a demo MovingAverageStrategy based on a simple moving average. It uses deque(maxlen=window) so old prices past the window size fall off automatically.

class MovingAverageStrategy(TradingStrategy):
    def __init__(self, window: int = 5):
        self.window = window
        self.prices = deque(maxlen=window)

    def should_buy(self, current_price: float) -> bool:
        self.prices.append(current_price)
        if len(self.prices) < self.window:
            return False
        avg = sum(self.prices) / len(self.prices)
        return current_price < avg

A trading-strategy plugin interface means defining an abstract class like TradingStrategy with Python’s ABC, so any strategy that implements one shared method — should_buy(current_price) — can plug into the engine the same way, whether it’s ThresholdBuyStrategy or MovingAverageStrategy.

This demo strategy is strictly for proving the interface — its parameters haven’t been validated by backtesting (that’s Phase 4), so I kept the live monitoring loop in auto_trader.py pointed at the already-verified ThresholdBuyStrategy only.

Verification: interface compliance plus behavior

I added two kinds of tests to test_strategy.py: one confirming TradingStrategy can’t be instantiated directly and that both implementations subclass it correctly, and eight more checking that MovingAverageStrategy holds off when there isn’t enough data yet, fires correctly above/below the moving average, and that deque properly drops old prices once the window fills up. Re-running the full suite gave the existing 38 plus these 8 — 46 passed — and I double-checked that auto_trader.py‘s safety values, DRY_RUN=True and TARGET_BUY_PRICE=1, hadn’t moved.

FAQ

Q. Why not build a full indicator-based strategy in the same pass?
Bundling in a real strategy with heavier calculation logic would’ve made verification more complex and riskier, so I scoped this session to the interface design only.

Q. Does the demo strategy ever trade for real?
No — auto_trader.py still only runs the verified ThresholdBuyStrategy; MovingAverageStrategy exists purely to prove the interface works.

Q. What does adding a new strategy look like now?
Subclass TradingStrategy, implement should_buy(current_price), and it drops right into the existing monitoring loop.