Lots of little pieces

“Good code invariably has small methods and small objects. Only by factoring the system into many small pieces of state and function can you hope to satisfy the ‘once and only once’ rule.” — Kent Beck, Smalltalk Best Practice Patterns, 1997.

This, for me, was the defining moment in software development’s evolution toward everything agile. The twin ideas of “lots of tiny pieces” and “once and only once” were game-changers. I’ve tried to live up to these simple words ever since, and I’m still learning today how to do it better and better.

Advertisements

One thought on “Lots of little pieces

  1. In the same book, another important section:

    There are a few things I look for that are good predictors of whether a project is in good shape. These are also properties I strive for in my own code.

    * Once and only once – If I only have one minute to describe good style, I reduce it to a simple rule: In a program written with good style, everything is said once and only once. This isn’t much help in creating good code, but it’s a darned good analytic tool. If I see several methods with the same logic, several objects with the same methods, or several systems with similar objects, I know this rule isn’t satisfied. This leads us to the second property:

    * Lots of little pieces – Good code invariably has small methods and small objects. Only by factoring the system into many small pieces of state and function can you hope to satisfy the “once and only once” rule. I get lots of resistance to this idea, especially from experienced developers, but no one thing I do to systems provides as much help as breaking it into more pieces. When you are doing this, however, you must always be certain that you communicate the big picture effectively. Otherwise, you’ll find yourself in a big bowl of “Pasta a la Smalltalk,” which is every bit as nasty as a dish of “Fettuccine a la C.”

    * Replacing objects – Good style leads to easily replaceable objects. In a really good system, every time the user says “I want to do this radically different thing,” the developer says, “Oh, I’ll have to make a new kind of X and plug it in.” When you can extend a system solely by adding new objects without modifying any existing objects, then you have a system that is flexible and cheap to maintain. You can’t do this if you don’t have lots of little pieces.

    * Moving Objects – Another property of systems with good style is that their objects can be easily moved to new contexts. You should be able to say. “This object in this system does the same job in that system. … Then, if you have a system built with lots of little pieces, you will be able to make the necessary modifications and generalizations fairly easily.

    * Rates of Change – A simple criterion I use all the time is checking rates of change. I learned this criterion from something Brad Cox said a long time ago. I’ve since generalized it to – don’t put two rates of change together. Don’t have part of a method that changes in every subclass with parts that don’t change. Don’t have some instance variables whose value changes every second in the same object with instance variables whose values change once a month. Don’t have a collection where some elements are added and removed every second and some elements are added and removed once a month. Don’t have code in an object that has to change for every piece of hardware, and code that has to change for every operating system. How do you avoid this problem? You got it, lots of little pieces.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s