A remark concerning software design and the get_leaves() function
It is probably a question of taste, but every time I need the leaves of a hierarchy, my intuitive guess is to write mh.get_leaves() instead of IMP.core.get_leaves(mh). So I wonder if there are gory reasons for this function to be outside the class…
--Ben
Late response.
The motivation is the "principle of least privilege". Basically, since the get_leaves() method doesn't need to do anything other than call a bunch of public methods on Hierarchy (eg get_children() until we reach the leaves), it doesn't need to be a member. And since it doesn't need to be a member, we don't make it one. The benefit is that doing this reduces the amount of code that is tied to the implementation of the Hierarchy class (that is, if we change how Hierarchy is implemented internally, we know we don't have to change get_leaves()).
The other advantage is that people who don't have access to Hierarchy code can add methods that act similarly (eg, get_leaves() and get_my_special_nodes() are both used the same way).
But yes, it does add a bit more to remember over having everything being a member method, and so isn't strictly better than having it as a method.
On Jul 22, 2010, at 8:01 AM, Benjamin SCHWARZ wrote:
> It is probably a question of taste, but every time I need the leaves of a hierarchy, my intuitive guess is to write mh.get_leaves() instead of IMP.core.get_leaves(mh). So I wonder if there are gory reasons for this function to be outside the class… > > --Ben > _______________________________________________ > IMP-users mailing list > IMP-users@salilab.org > https://salilab.org/mailman/listinfo/imp-users
It perfectly makes sense to me now, thanks for your answer.
--Ben
> The motivation is the "principle of least privilege". Basically, since the get_leaves() method doesn't need to do anything other than call a bunch of public methods on Hierarchy (eg get_children() until we reach the leaves), it doesn't need to be a member. And since it doesn't need to be a member, we don't make it one. The benefit is that doing this reduces the amount of code that is tied to the implementation of the Hierarchy class (that is, if we change how Hierarchy is implemented internally, we know we don't have to change get_leaves()). > > The other advantage is that people who don't have access to Hierarchy code can add methods that act similarly (eg, get_leaves() and get_my_special_nodes() are both used the same way). > > But yes, it does add a bit more to remember over having everything being a member method, and so isn't strictly better than having it as a method.
participants (3)
-
Benjamin SCHWARZ -
Benjamin schwarz -
Daniel Russel