Support for Futures markets

Currently the central key point of the XChange API is the CurrencyPair, which is passed as parameter for almost all methods. This works fine so far for spot markets. But if we want to support futures markets the CurrencyPair is not enough, for example see Deribit Instruments, there we have three “products” with the same pair BTC/USD. To support this we would need to replace the CurrencyPair by Product class, which could look like this:

public class Product {
  private String base;
  private String counter;
  private String symbol;	// this can be null, ie for spot products
  private ProductType productType;
}

public enum ProductType {
  spot, perpetual, future;
}

To stay with the deribit example, we would have three instances for products:

{base: BTC, counter: USD, symbol: BTC-27SEP19, productType: future}
{base: BTC, counter: USD, symbol: BTC-27DEC19, productType: future}
{base: BTC, counter: USD, symbol: BTC-PERPETUAL, productType: perpetual}

So like already said, inside the interface methods we could replace the CurrencyPair by Product (or Instrument or what ever name). The old methods could actually stay for a while and be marked as deprecated. This way we would be still compatible with older versions.

if the majority thinks it could make sense, i will create a PR

[mdvx]

If we think to the definition of a Future contract, it is an obligation to Buy/Sell and asset at a future date (BTC). Sometimes these contracts are settled in the quoted fiat (USD), other times these contracts are settled for ‘physical’ delivery, which would mean in actual BTC. In which case, the USD part is just a reference, and this very same contract could be quoted in JPY, EUR, or even ETH.

As such a futures contract is not a currency pair, but depends on a single underlying asset.

[timmolter]

There are so many ways this could be done, which makes it hard to decide. We could add new DTOs, Services and methods. We could add new DTOs and methods to existing services. We could add new and/or extended DTOs to existing Services and existing methods.

I always tried to lean towards making it easy for the end user (a programmer using the library, not the developers of the library) to understand the API so if we continue with this goal in mind, adding new DTOs and methods would make the most sense. Otherwise newbies will have to deal with complex “wrapper” classes for method arguments and return values. If someone comes and just want to place a limit order for a plain old “spot”, they can easily find it by searching the methods and it is relatively easy then to understand what arguments are required and what is returned. As a compromise we could forgo adding new service classes but add more methods within the existing ones. By default the new methods will just throw a NotImplementedYetException as it always has worked.

I think this would warrant a version bump to 4.5.0.

As far as extending Order or CurrencyPair or not I’d say yes if there is significant overlap of class members, but I’d say no if the members were completely or mostly orthogonal. Just take it by a case to case basis.

@mdvx If you think extending the Order class is not ideal, in which way do you think things could be improved?