Abstract, it is, but it is well thought and well explained. Your idea is interesting.

Some considerations:
- To my knowledge, an object with one method and one with one hundred methods use the same memory, since methods are static, shared by objects of same class. So they are not " cluttered with the other heavy methods". At least, not in the memory sense.
- The method of making an object depending on another is close of what is called dependency injection.

I did something like that in a maze generator (that I still need to advance a bit): I designed it so I can inject in the maze object a carver algorithm, a cell displayer and a wall displayer, depending on some settings:

1. GraphicalMaze maze;
   CarveAlgorithm carver;
   
     maze = new GraphicalMaze(MAZE_WIDTH, MAZE_HEIGHT);
2.   maze.setCellSize(CELL_SIZE);
3.   maze.setWallThickness(WALL_WIDTH);
4.   if (bDebug)
5.   {
6.     maze.setCellDisplayer(new ColoredCellDrawer(this, maze));
7.     maze.setWallDisplayer(new ColoredWallDrawer(this, maze));
8.   }
9.   else
10.   {
11.     maze.setCellDisplayer(new EmptyCellDrawer(this, maze));
12.     maze.setWallDisplayer(new SimpleWallDrawer(this, maze));
13.   }
14.   carver = new AlgoRecursiveBacktracker(maze.getMaze());

CarveAlgorithm is an interface, and so are CellDisplayer and WallDisplayer: they are blueprints, defining what method names, which what parameters, are defined in the classes implementing them, as a strict minimum.

So, you can define an interface Protagonist, with a couple of methods you expect to find, and define a bunch of classes implementing these methods in different ways.

Alternatively, you can use scripting: define the behavior in a scripting language, can be JavaScript, Lua, Groovy or whatever. You can make a bunch of small scripts defining these behaviors. A Protagonist can load a random script and follow its instructions. That's a method commonly used in the game industry (Lua is often used for such AI as it is small, fast and easy to learn).

Thanks for the input!

Awesome! Some great links you postet there, fiveagon.

I may be misunderstanding you, but this seems like a perfect candidate for an interface. The links given above are pretty good explanations; basically interfaces allow you write classes that all perform a certain set of tasks in different ways, which can be used interchangeably.
In your case you'd probably want something like this:

1. public interface Behavior {
2.     //This method, when implemented, will contain the behavior:
3.     public void doAction(BaseObject parent);
4. }

1. public class BaseObject {
2.    
3.     private Behavior action; //This can reference ANY object that implements Behavior
4.    
5.     //Constructor etc. here
6.    
7.     public void run() {
8.         action.doAction(this); //performs the action, whatever it may be
9.     }
10.    
11.     //Sets action to any class that implements the Behavior interface:
12.     public void setAction(Behavior action) {
13.         this.action = action;
14.     }
15. }

1. public class BehaviorOne implements Behavior {
2.    
3.     //Constructor and whatever else here
4.    
5.     //Implementation of Behavior's doAction() method stub:
6.     public void doAction(BaseObject parent) {
7.         //Perform whatever actions you want
8.         //Parent variable will let you access BaseObject's public members if you
9.         //  want Behaviors to be able to act directly on the BaseObject
10.     }
11. }

1. public class BehaviorTwo implements Behavior {
2.    
3.     public void doAction(BaseObject parent) {
4.         //Perform a completely different set of actions
5.         //Whether you're using BehaviorOne or BehaviorTwo will be completely
6.         //  transparent to BaseObject
7.     }
8. }

Additional note: interfaces are a means to guarantee that an object implementing an interface will have the wanted methods (with right parameters and return type). So any object implementing it, whatever its shape and size, can be used the way the interface defines it.
If, above that, you have some behavior which is common to all objects, you can define an abstract class implementing the interface. It allows to provide default implementations for some or all of the interface's methods, which can be dummy (like "ignore the parameters and return null") or doing real stuff. You can then make the classes to extend the abstract class, making them to implement the interface without having to declare all methods, only those they are interested in.
You can see that in Java, for example with the MouseListener interface defining various mouse callback methods, and the MouseAdapter abstract class defining dummy implementations, allowing classes extending it to only define the mouse callback they really need.

Wow, my head hurts. Thanks guys...

I felt the same when I went from imperative, procedural programming to OOP... Some concepts are hard to grasp, then feel natural when you master them! And just wait to learn functional programming or type theory, eg. with Scala...

Some example of use of interfaces with Processing (my own code, if you don't mind):
- The maze: http://bazaar.launchpad.net/~philho/+junk/Processing/files/head:/MazeGeneration/
- Fern generation: http://bazaar.launchpad.net/~philho/+junk/Processing/files/head:/Ferns/ (one of my first sketches)
- Seach words: http://bazaar.launchpad.net/~philho/+junk/Processing/files/head:/_SmallPrograms/SearchWordsClass/
- Drawing in sequence: http://bazaar.launchpad.net/~philho/+junk/Processing/files/head:/_SmallPrograms/DrawingInSequence/
and some others

True, what gives me confidence, is that I had a similar struggle grasping the basic concept of objects. And it took some time, until I got the hang of easily writing classes. But now I just wouldn't want to miss OOP. So yeah, probably I'll just have to fight through the confusion and eventually will untie the knot.

also really interesting and helpful --> design patterns:
http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29

here are some java code snippets for this topic:
http://www.allapplabs.com/java_design_patterns/java_design_patterns.htm