We shall first create a module called Vehicle. The purpose of this module is to implement our space-travel logic. As we want to keep this module generic, we will design an interface that any object can implement in order to participate in our space-travel program.

The structure of the module consists of four sections, as indicated by the following embedded comments:

module Vehicle
# 1. Export/Imports
# 2. Interface documentation
# 3. Generic definitions for the interface
# 4. Game logic 
end # module

Let's see how the code is actually written in the module:

1. The first section exports a single function called go!:

# 1. Export/Imports
export go!

2. The second code segment is merely documentation:

# 2. Interface documentation
# A vehicle (v) must implement the following functions:
#
# power_on!(v) - turn on the vehicle's engine
# power_off!(v) - turn off the vehicle's engine
# turn!(v, direction) - steer the vehicle to the specified direction 
# move!(v, distance) - move the vehicle by the specified distance
# position(v) - returns the (x,y) position of the vehicle

3. The third code segment contains generic definitions of the functions:

# 3. Generic definitions for the interface
function power_on! end
function power_off! end
function turn! end
function move! end
function position end

4. Finally, the last code segment contains the space-travel logic:

# 4. Game logic 

# Returns a travel plan from current position to destination
function travel_path(position, destination)
    return round(π/6, digits=2), 1000 # just a test
end

# Space travel logic
function go!(vehicle, destination) 
    power_on!(vehicle)
    direction, distance = travel_path(position(vehicle), destination)
    turn!(vehicle, direction)
    move!(vehicle, distance)
    power_off!(vehicle)
    nothing
end

The travel_path function calculates the direction and distance to travel from the current position to the final destination. It is expected to return a tuple. For testing purposes, we are just returning hardcoded values.

The go! function expects that the vehicle object being passed in the first argument is some kind of space vehicle. Furthermore, the logic also expects the vehicle to exhibit certain behavior, such as being able to turn on the engine, steer in the right direction, move a certain distance, and so on. 

If a client program wants to call the go! function, it must pass a type that implements the expected interface as assumed by this logic. But how does one know what functions to implement? Well, it is defined as part of the documentation as spelled out in the comment from the Interface Documentation code segment:

# A vehicle must implement the following functions:

# power_on!(v) - turn on the vehicle's engine
# power_off!(v) - turn off the vehicle's engine
# turn!(v, direction) - steer the vehicle to the specified direction 
# move!(v, distance) - move the vehicle by the specified distance
# position(v) - returns the (x,y) position of the vehicle

Another clue is that the required functions are defined in the previous code as empty generic functions—that is, functions without any signature or body:

function power_on! end
function power_off! end
function turn! end
function move! end
function position end

So far, we have written the interface's contractual requirements as comments in the code. It is generally better to do this as Julia doc strings so that the requirements can be generated and published to an online website or printed as hard copy. We could do something like this for every function specified in the interface:

"""
Power on the vehicle so it is ready to go.
"""
function power_on! end

The Vehicle module is now completed, and as part of the source code, we have set certain expectations. If any object wants to participate in our space-travel program, it must implement the five functions—power_on!, power_off!, turn!, move!, and position.

Next, we will design a new fighter jet line for the space-travel program!