Java Magazine, July/August 2016
The Problem of Writing Small Classes The highly recommended best practice presents a series of challenges that its advocates rarely address There are few coding practices that when followed conscientiously deliver as much benefit as writing small classes Take almost any desirable metric simplicity testability debugability and small classes score high Take almost any undesirable metric complexity error density brittleness and small classes score low In addition various programming rules of thumb point directly toward smaller classes the singleresponsibility principle in particular as well as many fundamental refactorings With all these benefits it seems that if you want to write good code small classes should represent a fundamental implementation goal and class size should be a metric that is constantly kept in mind as code is written If you work this way though youll find that for all the advice available on how to write good ORACLE COM JAVAMAGAZINE JULY AUGUST 2016 04 from the editor PHOTOGRAPH BY BOB ADLER GETTY IMAGES code and the wisdom of consultants there is little guidance on how to manage the issues that small classes present Small classes have been a favorite concern of mine for a long time Ive written about how to tease small ones from larger ones how to think in terms of small code units and so on But over the years I have found that small classes while delivering the promised benefits create problems whose solutions are largely unexplored Lets begin by defining a small class I define it as fewer than 60 lines of code LOCs The number appears arbitrary but it works in delivering classes that can be seen in their entirety with a single page up or page down keystroke in the IDE This same logic drives NASAs Power of Ten rule that limits functions also to 60 lines Classes this size can be read and under
You must have JavaScript enabled to view digital editions.
