In a previous article I wrote about the first rule of East-oriented Code.
Here again are the rules I set forth in my presentation at RubyConf:
- Always return self
- Objects may query themselves
- Factories are exempt
- Break the rules sparingly
The second rule, that "Objects may query themselves", allows the design of objects to work with their own attributes.
When we design our systems of interacting objects we can use the Tell, Don't Ask approach to limit the decisions in the code to objects which are responsible for the data used to make them.
The Tell, Don't Ask article begins by quoting Alec Sharp:
Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.
In order for objects to do things, they may need to ask questions about their own data. Though the first rule of East-oriented Code says that you should return
self, internal private methods don't need to follow this rule. We can and might need to create query methods to allow the object to make decisions.
It's easy to begin designing an object by specifying what it's attributes are:
class Person attr_reader :name, :nickname, :gender end
When we do that, we also implicitly allow other objects to use these attributes and make decisions:
if person.nickname =~ /^DJ/ person.setup_playlist_preferences('house') else person.setup_playlist_preferences('classical') end
In the sample code above we're using a method
setup_playlist_preferences which accepts a single argument. The decision about what value to set is made outside of the
person object. As additional options are added to the system, this
if may have
elsif clauses added to it or it may turn into a
case statement. With public attributes, those changes can appear in multiple places in your system, which can lead to headaches when the structures of your objects change.
Alternatively, we could command the object to do what we want:
Any decision about what to do to setup preferences can be made inside the
Here's a summary from the C2 wiki
Very very short summary: It is okay to use accessors to get the state of an object, as long as you don't use the result to make decisions outside the object. Any decisions based entirely upon the state of one object should be made 'inside' the object itself.
One way to prevent decisions about an object from being made outside that object is to limit the public information:
class Person private attr_reader :name, :nickname, :gender end
If you like this, check out the new book I'm writing: Ruby DSL Handbook which is currently half-off the final price. It's designed to be a guide to help you make decisions about how to build your own DSL and compressions of concepts.