Action-based objects

While designing object classes I often find myself in doubt about which object should handle which other object or responsibility. I’ve adopted a rule, I’m sure not a new one, from a far away context.
The article “Good tools have verb based interfaces”, dealing with interfaces as UIs, really spark something into me. The same principle I now use to make divisions among objects and model them.

Methods are the building blocks of objects

Objects are defined by properties, a stateful hook, and methods. The only way to interact with an object, and for an object to interact with another objects, is to call one of its methods. Methods can alter properties, do something epic or trivial, but still are the building block of objects: an object with many properties and no methods is a glorified array while an object with no properties and many methods is an entity to watch.

Batching actions is my level 0 refactoring

I will take the latest application of the above idea as an example: the Main class from the Theme framework I’m developing did, before the latest refactoring, the following actions

// Main class
locates the controllers
instances the controllers
sets and gets the controllers
locates the class extending it in file path terms
locates the class extending it in namespace terms
sets the root path
sets the root namespace

while the Controller class does the following

// Controller class 
locates the view
instances the view
sets and gets the view
locates the class extending it in file path terms
locates the class extending it in namespace terms

I will now batch the above sentences using the action as a link between the methods in place of the target of those actions:

// locate
locates the controllers
locates the class extending it in file path terms
locates the class extending it in namespace terms
locates the view
locates the class extending it in file path terms
locates the class extending it in namespace terms

// instance
instances the controllers
instances the view

// sets and gets
sets and gets the controllers
sets the root path
sets the root namespace
sets and gets the view

I can now think, and consider the convenience, of outsourcing any of the actions above to a third more specialized object to “Keep It Simple, Stupid” and keep the code DRY of repetitions.
Right now I did outsource the locate and the instance action to the Bot class. After a while I will scan my classes again to find batchable actions and, eventually, batch them.

I appreciate your input