If someone wants to see all the code, here it is:

 Motor motor1 = new Motor();  Motor motor2 = new Motor();
 PVector boatPos = new PVector(400,400);
 Boat boat = new Boat();
 BoatBrain boatBrain = new BoatBrain(motor1, motor2, boat);
 boat = new Boat(motor1, motor2, boatBrain, boatPos);

void setup() {
 size(800,800);
}
void draw() {
 boat.boatBrain.navigate();  //pure peacocking - not used until navigation algoritm is in place..
 
}

class Sea {}

class Boat {
 private Motor motor1, motor2;
 private BoatBrain boatBrain;
 private int movementState;
 private PVector position;
 Boat() {};  //simple constructor
 Boat(Motor motor1, Motor motor2, BoatBrain boatBrain, PVector boatPos) {
   this.motor1=motor1; this.motor2=motor2; this.boatBrain=boatBrain; this.movementState=0; this.position.x=boatPos.x; this.position.y=boatPos.y; }
 private void reactToAppliedForces() {}
 
}
class Motor {
 private boolean On;
 private boolean Forward;
 Motor() {this.On = false; this.Forward = false;}
 private void setOnOff() {this.On = !this.On;}
 private void setForwardBackward() {this.Forward = !this.Forward;}

}
class BoatBrain {
 private Motor motor1, motor2;
 private Boat boat;
 private boolean On;
 BoatBrain(Motor motor1, Motor motor2, Boat boat) {this.motor1=motor1; this.motor2=motor2; this.boat=boat; On=true; }
 public void navigate() {

 }
}

void keyPressed() {
 println("");
 println("a key got pressed");
 if(key=='0') { boat.motor1.setOnOff(); }
 if(key=='1') { boat.motor1.setForwardBackward(); }
 if(key=='2') { boat.motor2.setOnOff(); }
 if(key=='3') { boat.motor2.setForwardBackward(); }
}

Nice - thank you.
If I were to take a better Object Oriented Design-approach I guess I should put the stuff that right now resides in the top and in the Setup-method in a main-method in one of the classes. However, I can't see how that main-method would ever be called, if I don't explicit make it happen myself by calling it from eg. the Setup-method.

Ah, right.  I had that rule lodged in my mind without thinking exactly *why* I shouldn't do it.

Hi

My thoughts on it is that I always avoid, where possible, to instantiate variables in the global scope or in the constructor.
When instantiating in the global scope these objects will take up memory even before they are used and the same goes for putting things in the constructor.

I will often have an init() method and lots of getters and setters below my constructor, so that I can instantiate an object(being "empty"), but wait to later on to actually fill it with data. This goes for my external classes, setup is different...
Design patterns and use of private/public methods like getters and setters will simplify both the way you design classes and the memory footprint you use up.
A local variable will only take up memory when the method gets called, a global will not release memory when you are done with it.

I think of the setup() as the constructor of a sketch, but a constructor that you must run, a sort of main(). So I will define the fields I need as this:

PImage i1, i2;
PVector v1, v2;

setup()
{
i1 = new PImage();
v1 = new PVector();
}

just the way sw01 does it.
As PhiLho writes: some methods and fields are not available before setup has been executed. So MyObject mo = new MyObject() before setup() can be suspicious as we dont know what the constructor of MyObject() will utilize? will it access frameCount(), width or other fields and methods not currently available?
The error messages you will get when doing instantiating before setup(), when something goes wrong, are also crazy and not the least bit helpful (an important subject that is often left out is how to code to help the debugger help you :) ).

I don't have a deep understanding of how the processing environment works, so the above is just from my experience and what I believe to be good coding conventions in general.

When doing the boatBrain -> boat and boat -> boatBrain you are sending references all over the place and coupling these object strongly, this means that later on you can not have a boat or boatBrain exist without the other. Probably not an issue....for now :)
Maybe something like at "composite pattern" or "strategy pattern" if more algorithms are involved, would simplify things.

Yep, it makes more sense now. I think I'm going for this book:
http://www.amazon.co.uk/Thinking-Java-Bruce-Eckel/dp/0131872486/ref=wl_it_dp?ie=UTF8&coliid=IIX2505OBML6Z&colid=1JIEED1XOWCIH

it sounds like the thing I need.

to RickiG:

So instead of letting each object have a HAS-A relation to each other you want met to do something like this:

myClass1 myObject1;
myClass2 myObject2;

void setup() {
myObject1 = new myClass1();
myObject2 = new myClass2();
myObject2.wreakHavocOn_myObject1(-1);
}

class myClass1 {
 private int variableToBeAlteredBy_myObject2;
 myClass1() {}  //constructor
 public void setVariable(int newValue) {
   variableToBeAlteredBy_myObject2 = newValue;
 }
}

class myClass2 {
 myClass2() {}  //constructor
 private void wreakHavocOn_myObject1(int newValue) {
   myObject1.setVariable(newValue);
 }
}