Skip to main content

Encapsulate Field Blues

There is no other computing book that I regard as high as Martin Fowler's Refactoring - Improving the Design of Existing Code. I am therefore thrilled to have seen refactorings take a major leap into mainstream development during the last couple of years. For the uninitiated, refactoring deals with how to make computer code beautiful, maintainable and easier to read, without changing functionality.

One of the most common refactorings there are is Encapsulate Field, which tells us to make a member variable private and wrap it in public set and get methods. The rationale behind this is to separate data from behavior and allowing us to change the implementation without having to change all callers.

I hate it.

It's not that the refactoring is bad per se, it's just that it's being misused right and left. Why would you want to bloat your code with trivial get/set accessors instead of just making the member public? Also, most modern languages have constructs for making a public member read-only, if you only want to allow get, without set.

If you want to implement a non-trivial accessor function, it is very likely that you would want the accessor to be a method instead, whose name will better describe the implementation.

While the argument that it would be easier to change the implementation in one place rather than in several is true, I'd much better hold that refactoring/code bloat off for now, and run my IDE's "Find references" and make the necessary refactorings later if need be.

Anyway, if you want to rename the member variable, you will have to rename the accessor, as well as all callees, or you will have an bad code smell.

Do yourself a favor, hold off the Encapsulate Field next time and just DTSTTCPW! My guesstimate says that it is only preferable to use this refactoring in 5% of the cases where you have a member variable you want to expose.

The only real reason where I constantly see the benefit of designing members encapsulated are in published interfaces which you don't want to or cannot modify.
Labels:

Comments

Post a Comment

Popular posts from this blog

HOWTO: Fix a Broken Laptop Lid for $1

A few months ago my laptop lid's hinges gave up and my lid kept falling over. I will show you how I fixed the problem in five minutes by using materials for $1. But first some background info. At first, I assumed there would be a quick and simple fix to this common laptop problem. My laptop is an Evo N800v. HP has bought Compaq since I purchased the computer so that's where I'm supposed to turn for help. I was kind of startled to hear that HP support wanted $500 for fixing the broken hinges - presumably they intended to replace the entire lid. Obviously, shelling out $500 for fixing a 6 year old laptop is not the way to go, so I started to look for alternative solutions. First, I disassembled the laptop numerous times, trying to make the hinges more sturdy (that's spelled S-U-P-E-R-G-L-U-E). Anyway, that didn't help. Option number two was to do something similar to what user xrobevansx did on instructables.com . Basically he bought a lid support in a hardware store...
19 comments
Read more

HOWTO: GTD with Google Docs & PocketMod

Take control of your unwieldy to do-list by combining Google Docs and PocketMod. With the system described here you will always be ready to take notes, and never run the risk of losing an idea! Update (July 30, 2009): Now using a Google Docs template. I use a subset of GTD (" Getting Things Done ") by having a digital copy of my next actions, sorted by context (@Home, @Office, @Shopping, @Computer, etc.). This lets me easily look up what I need to do, depending on where I am. However, a digital copy is not very useful by itself, since it is not accessible when I am offline. Putting it in my PDA is not ideal either, since the overhead of adding a new note is too big (turning on the device, opening the right application, having it recognize my handwriting). That's why I print out my to-do list on paper once a week and carry it in my pocket. It's the ideal way of accessing and editing tasks. Before I print out a new list I spend a minute or two copying the edits from my...
5 comments
Read more

Reading on Paper vs. on Screen

One of the basic premises behind FeedJournal is that it's better to read text on paper than on a screen. While it might not sound like a bold assumption, it still is an assumption and as such worth to examine deeper. Today, office workers and many other professionals are required to focus their eyes on a computer screen during most of their work day. Many of them continue to use the computer at home. FeedJournal was created with many goals in mind; one of them is to release you from the screen while enabling you to read the content you love. You shouldn't have to spend more time reading off a screen, just because you want to access fresh and relevant content. Recent research has found that reading a longer text on paper is 25% faster than reading the same text on a computer screen. At the same time, reading comprehension and article overview are improved. Although screen resolutions have increased and font rendering technologies such as ClearType make it much easier to rea...
11 comments
Read more