The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
Encapsulation vs Abstraction, a blog post I wrote a few years ago, is the most popular post on this blog. So I decided to revisit the subject. This time, I want to focus more on encapsulation.
Encapsulation = Information Hiding
Did you get that?
Don’t worry. By the end of this post, you’ll get it. 
If you did, you can probably stop reading this post. You already know what encapsulation is. Good for you!
I know McConnell in Code Complete 2 has a great focus on Object Oriented coding, so I turned to his book initially. And I found a great analogy for abstraction and encapsulation.
|
Encapsulation is a stronger concept than abstraction. Abstraction helps to manage complexity by providing models that allow you to ignore implementation details. Encapsulation is the enforcer that prevents you from looking at the details even if you want to.
–Steve McConnell in Code Complete
|
This might sound confusing initially. Don’t worry. One thing to take away from it, though, is that encapsulation goes together with abstraction. In fact, McConnell says you cannot have just one, either you have both or you have none. I totally agree. There is no middle ground.
But this post is more about encapsulation…
|
|
The single most important factor that distinguishes a well-designed module from a poorly designed one is the degree to which the module hides its internal data and other implementation details from other modules.
–Joshua Bloch
|
Now we’re talking. 
Mr. Bloch, another influential author, is basically telling you what encapsulation is: information hiding.
Once again, it’s a good analogy to have in your mind: Encapsulation = Information Hiding. That’s how you want to remember what encapsulation is.
On a practical level, how do you accomplish encapsulation? Steve McConnell, in in section 6.2 has some very good points:
It’s also important that encapsulation not only applies to classes. It’s easy to only think of classes. But if also applies to object, package, namespace, class or interface.
Real World Example
I found another great definition in the book I started reading, Design Patterns by Lasater.
“Think of encapsulation like your mortgage company,” recommends Lasater. You send of your mortgage payment every month and you get a statement back showing your loan data. Your mortgage company is hiding from you the accounting details. And you don’t really care, as long as your principle is decreasing after your payment is applied.
To take this a step further, here’s a class definition for the Mortgage payment. The idea of encapsulation is to only expose the necessary methods. Not more.
// taken from Design Patterns
class CustomerPayment {
public double postPayment(int loanId, double payment) {
// posts a payment
}
public List getAmortizedSchedule(int loanId) {
// return a schedule in array
}
There would be many more methods in the class. But they’re hidden. Hidden from the class interface. You cannot access them outside the class code. That’s in fact, a definition of encapsulation. Only exposing the required methods, in this case post payment and get schedule.
To take McConnell’s definition I mentioned earlier and apply it to the above example, proper abstraction allows you talk on a higher “abstract” level, about Customer Payment and not worrying about too many details. Encapsulation, like McConnell said, is “the enforcer,” and it is not allowing you to look at the details. How? By only exposing these 2 methods.
Just one more thing: encapsulation = information hiding.
If you just remember one thing about encapsulation, remember that. I hope I helped you.
Related
Encapsulation vs Abstraction – my related blog post
Reference
Design Patterns by Christopher G. Lasater
Code Complete 2 Steve McConnell — one of the best programming books that I recommend/sk
I hesitated posting this… The last thing I want is more red tape. However, after reading about code reviews in several sources, I am convinced that the reward is worth the price. The bottom line, code reviews improve code quality. While no silver bullet, they force us to write better code — knowing that somebody else will evaluate it makes us do it.
I have never been part of a company where code reviews worked effectively, but at the same time, if implemented properly into the development process, they have the potential to improve the quality code in a significant way.
What’s more, they enable cross-training programmers, mentoring, and enforcement of code conventions. Code reviews allow us to make sure that new people are “adopting” to “our” way of doing things, if there are any. They’re the extra guard to protect the most-valued property: code.
A lot of the prominent IT gurus, like Grady Booch, Jerry Weinberg, Cedric Otaku (those are sitting on top of my mind now), are big proponents of code reivews. I believe Weigers even wrote a book on the subject.
What prompted me to write this is an excellent blog entry by Cedric Beaust, Why Code Reviews Are Good For You, http://beust.com/weblog/archives/000393.html. He explains why it’s good and the different types of reviews. The following sums it up nicely:
“I strongly believe that projects that work without any peer review will end up with code of significantly worse quality, regardless of how talented or experienced the developers are. It doesn’t matter how good you are, you can’t produce top quality code all the time. We all get sloppy at time, and code reviews are here to address these times.”
I think we should consider implementing non-blocking code reviews. Let’s be honest, we all check in code that is sometimes sloppy, we could all use a little incentive to do better, and a lot of times we write code that only we can understand. Code reviews would be an improvement in this area.
How do we implement it? Good question. I believe that there should be some communication system in place. But the bottom line, each line of code should be looked at by somebody else and suggestions how to make it better should be requested of each reviewer (no heart feelings).
At my current job we have JIRA and SVN integrated, doing code reviews would be simple. Every SVN check in has to have a ticket ID. Before a ticket can be closed and the project released, every change has to be reviewed by somebody else and commented on. Before it can be closed, the reviewer would have to approve that the changes have actually been implemented.
We all strive to write good quality code whether we do code reviews or not, but it does not always happen. Knowing that our code would be reviewed would force us to do it every time.
ReferenceWhy Code Reviews Are Good For You, Cedric Otaku
RelatedCode Reviews, very good java.net article
How to adopt XP? Here’s how, from Extreme Programming Explained.
1. Pick your worst problem.2. Solve it the XP way.3. When it’s no longer your worst problem, repeat.
I think the above is not only for adopting XP, but a good way to solve any development process issue. It is a good way to improve your process.
Here’s how I think you can solve any process issue (a modified version of the above):
Where else can this be applicable? I think this is also a good way to work on your individual problems.
You are not going to fix anything right away, start making small, step-by-step changes and you will get there sooner than you think.
RelatedGood XP Practices, my recent entry
Extreme Programming has been around for years now. From what I hear, it has been successful. I like the process, but I don’t think I could withstand all of the practices on a continual basis. Having to pair program on a continual basis is just a pain (bathroom, personal calls, taking breaks, etc). I think it could be done at times, for instance, fixing a critical issue, but on a day to day basis, I dont’ think I would be able to do it.
Here are the practices of XP, taken from Extreme Programming Explained book, which I’m currently reading.
Based on these practices, I think a good agile process should have the following practices (from the XP process).
All in all, XP brought a lot of good practices to the development world. It was, and still is, a disruptive force. And that’s a good thing. Whatever your process is, make sure it is agile, and exposes problems early.
