Just as a small addition to my previous article on abstract classes vs interfaces.
Wneh we declare an interface, we can’t tell how to create an object, implementing that interface. E. g., we can not define even a default constructor.
Thus, when we need to have at least one constructor of a defined signature, we must use abstract classes.
Check it out:
and compare it to this:
Feb 9, 2015
Found these on HabraHabr today. Here are some tricks I found usefull.
Private methods are not actually private
Let us have class:
Here, class method foo is not private:
Instance with params
Oftenly there is a need to create a class instance and set it some params (or, maybe, call some methods on it). It's done usually like this:
This can be shortened with the use of `tap` method:
Yet, it is more ruby-convenient and ruby-style to do it with the initialization block:
Or even like this:
When you have your migrations using your code, for example, like this:
you then have a problem when updating your code. In our example, if you remove the constant Data::VOLUMES, you will have to either manually search for all the usages of this constant, or have a really intelliJent IDE ;)
Rather than using your existing code, stub it and copy-and-paste all migration-dependent code to the stubbing class:
Example with constant is rather stupid, whilst you may have some more critical code.