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.
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.
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
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.