Jaybaz writes about a programming concept that intrigued me: no private methods. If you ever need to encapsulate something into a private method, you should make it an object instead with a public interface. He describes it as performing Extract Class until there are only public methods left. Private fields are okay, but methods must be public.
It's intriguing.... It would be a little bit of overhead, extra work, sure, but it leads to some cool ideas. It pushes the idea of design encapsulation. It should lead to better code reuse. And better reuse means less bugs over time: you fix it in one spot and everything that uses that object is fixed, too.
Of course if you define your object boundaries poorly, refactoring might become a nightmare. But if they're defined well, refactoring might become a breeze.
I haven't made up my mind on this yet. I want to try it and see if I like it. Will I stick with it? Will the overhead and extra work be outweighed by the encapsulation and reusability prospects in that code? Will it be an end to or a cause for refactoring?
No comments:
Post a Comment