Do you write trustworthy objects?
Do you trust the objects that you create?
Do you write objects and call methods on them without worries?
The problem
I used to see (and I have to admin that sometimes I write) code that doesn’t trust another objects behavior or responses. This usually comes in the form of checking that a method response is not null or catch an exception “just in case there was something unexpected that the called class doesn’t handle”.
If you are doing Object Oriented Programming (OOP) and want to do it well, please trust in your objects and their responses. You must be writing trustworthy objects if you want to do OOP right.
What is the purpose of write a whole class if you’ll be checking that it behaves correctly just in case?
What to do?
Stop worrying about that and trust your objects. If you write good Object Oriented Code and test that it behaves as it is supposed to be, you should just use the code that you write without worries.
I’m not saying that you should trust that your classes will never fail, but if you’re going to check cases or rescue exceptions in the caller of a class method, why don’t do that in the class itself? There should no be a reason to do class-related things outside of a given class.
The next time that you write a class or method, think about its responsibility, because, most of the time, it should be only one. When a class have just one responsibility, it is easy to test it and rely that it will behave as expected.
When you create an object, you should have a well defined interface that defines what it does and how it interacts with your system. The scope of an object or a method should have as few responsibilities as possible because the more responsibilities an object haves, the more complex and bug-prone it will be.
Think of it this way: if you check the response that your methods are giving to you, then you’re trusting more a code that is just using a method instead of a method that was designed to do a given task. It does not makes sense, right?
In the worst case, if you’re going to catch every possible exception, at least put that logic in your object’s methods, so you will be able to at least trust that they do what they are supposed to.
For example, if you think that an HTTP call can fail in multiple ways (network error, timeout error, etc) and want to catch those exceptions, please do that in the class that is in charge of that. It makes way more sense than doing it outside, because you’ll have a single place to handle those cases and futures updates to it.
I have find very useful to use Response Objects to maintain a good communication between code layers (inclusively I write a gem to make them easier to use).
Is just a matter of get used to write trustworthy objects, but after not so long time you’ll be writing objects that interact between them without worries so they will be a lot simpler to read and work with.
Last words
Just give it a try. The next time that you write a class think what is its purpose, stick to it, and create a limited interface for it so other objects can use your methods without worries. You’ll notice how your code and your confidence on it improves.
