The Idiomatic Way To Do OOP, Types and Methods in Julia

Question

As I'm learning Julia, I am wondering how to properly do things I might have done in Python, Java or C++ before. For example, previously I might have used an abstract base class (or interface) to define a family of models through classes. Each class might then have a method like calculate. So to call it I might have model.calculate(), where the model is an object from one of the inheriting classes.

I get that Julia uses multiple dispatch to overload functions with different signatures such as calculate(model). The question I have is how to create different models. Do I use the type system for that and create different types like:

abstract type Model end
type BlackScholes <: Model end
type Heston <: Model end

where BlackScholes and Heston are different types of model? If so, then I can overload different calculate methods:

function calculate(model::BlackScholes)
    # code
end

function calculate(model::Heston)
    # code
end

But I'm not sure if this is a proper and idiomatic use of types in Julia. I will greatly appreciate your guidance!

Answer 1

This is a hard question to answer. Julia offers a wide range of tools to solve any given problem, and it would be hard for even a core developer of the language to assert that one particular approach is "right" or even "idiomatic".

For example, in the realm of simulating and solving stochastic differential equations, you could look at the approach taken by Chris Rackauckas (and many others) in the suite of packages under the JuliaDiffEq umbrella. However, many of these people are extremely experienced Julia coders, and what they do may be somewhat out of reach for less experienced Julia coders who just want to model something in a manner that is reasonably sensible and attainable for a mere mortal.

It is is possible that the only "right" answer to this question is to direct users to the Performance Tips section of the docs, and then assert that as long as you aren't violating any of the recommendations there, then what you are doing is probably okay.

I think the best way I can answer this question from my own personal experience is to provide an example of how I (a mere mortal) would approach the problem of simulating different Ito processes. It is actually not too far off what you have put in the question, although with one additional layer. To be clear, I make no claim that this is the "right" way to do things, merely that it is one approach that utilizes multiple dispatch and Julia's type system in a reasonably sensible fashion.

I start off with an abstract type, for nesting specific subtypes that represent specific models.

abstract type ItoProcess ; end

Now I define some specific model subtypes, e.g.

struct GeometricBrownianMotion <: ItoProcess
    mu::Float64
    sigma::Float64
end
struct Heston <: ItoProcess
    mu::Float64
    kappa::Float64
    theta::Float64
    xi::Float64
end 

Note, in this case I don't need to add constructors that convert arguments to Float64, since Julia does this automatically, e.g. GeometricBrownianMotion(1, 2.0) will work out-of-the-box, as Julia will automatically convert 1 to 1.0 when constructing the type.

However, I might want to add some constructors for common parameterizations, e.g.

GeometricBrownianMotion() = GeometricBrownianMotion(0.0, 1.0)

I might also want some functions that return useful information about my models, e.g.

number_parameter(model::GeometricBrownianMotion) = 2
number_parameter(model::Heston) = 4

In fact, given how I've defined the models above, I could actually be a bit sneaky and define a method that works for all subtypes:

number_parameter(model::T) where {T<:ItoProcess} = length(fieldnames(typeof(model)))

Now I want to add some code that allows me to simulate my models:

function simulate(model::T, numobs::Int, stval) where {T<:ItoProcess}
   # code here that is common to all subtypes of ItoProcess
   simulate_inner(model, somethingelse)
   # maybe more code that is common to all subtypes of ItoProcess
end
function simulate_inner(model::GeometricBrownianMotion, somethingelse)
   # code here that is specific to GeometricBrownianMotion
end
function simulate_inner(model::Heston, somethingelse)
   # code here that is specific to Heston
end

Note that I have used the abstract type to allow me to group all code that is common to all subtypes of ItoProcess in the simulate function. I then use multiple dispatch and simulate_inner to run any code that needs to be specific to a particular subtype of ItoProcess. For the aforementioned reasons, I hesitate to use the phrase "idiomatic", but let me instead say that the above is quite a common pattern in typical Julia code.

The one thing to be careful of in the above code is to ensure that the output type of the simulate function is type-stable, that is, the output type can be uniquely determined by the input types. Type stability is usually an important factor in ensuring performant Julia code. An easy way in this case to ensure type-stability is to always return Matrix{Float64} (if the output type is fixed for all subtypes of ItoProcess then obviously it is uniquely determined). I examine a case where the output type depends on input types below for my estimate example. Anyway, for simulate I might always return Matrix{Float64} since for GeometricBrownianMotion I only need one column, but for Heston I will need two (the first for price of the asset, the second for the volatility process).

In fact, depending on how the code is used, type-stability is not always necessary for performant code (see eg using function barriers to prevent type-instability from flowing through to other parts of your program), but it is a good habit to be in (for Julia code).

I might also want routines to estimate these models. Again, I can follow the same approach (but with a small twist):

function estimate(modeltype::Type{T}, data)::T where {T<:ItoProcess}
    # again, code common to all subtypes of ItoProcess
    estimate_inner(modeltype, data)
    # more common code
    return T(some stuff generated from function that can be used to construct T)
end
function estimate_inner(modeltype::Type{GeometricBrownianMotion}, data)
    # code specific to GeometricBrownianMotion
end
function estimate_inner(modeltype::Type{Heston}, data)
    # code specific to Heston
end

There are a few differences from the simulate case. Instead of inputting an instance of GeometricBrownianMotion or Heston, I instead input the type itself. This is because I don't actually need an instance of the type with defined values for the fields. In fact, the values of those fields is the very thing I am attempting to estimate! But I still want to use multiple dispatch, hence the ::Type{T} construct. Note also I have specified an output type for estimate. This output type is dependent on the ::Type{T} input, and so the function is type-stable (output type can be uniquely determined by input types). But common with the simulate case, I have structured the code so that code that is common to all subtypes of ItoProcess only needs to be written once, and code that is specific to the subtypes is separted out.

This answer is turning into an essay, so I should tie it off here. Hopefully this is useful to the OP, as well as anyone else getting into Julia. I just want to finish by emphasizing that what I have done above is only one approach, there are others that will be just as performant, but I have personally found the above to be useful from a structural perspective, as well as reasonably common across the Julia ecosystem.