The Pragmatic Craftsman :: Simplicity from complexity : by Stanley Kubasek ::

Archive for the 'Software Engineering' Category

More on Encapsulation June 20th, 2010
Code Reviews Are Good August 21st, 2006
Improving Your Process March 17th, 2006
Good XP Practices March 3rd, 2006

More on Encapsulation

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:

  • Minimize accessibility of classes and members
  • Don’t expose member data in public
  • Avoid putting private implementation details into a class’s interface
  • Don’t make assumptions about the class’s users
  • Avoid friend classes
  • Watch for coupling that’s too tight

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.

Encapsulation vs Abstraction – my related blog post

Design Patterns by Christopher G. Lasater
Code Complete 2 Steve McConnell — one of the best programming books that I recommend/sk

Code Reviews Are Good

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, 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 article

Improving Your Process

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):

  1. Start with your worst problem.
  2. Try to continously solve it. Don’t try to solve anything else; keep working on the individual problem until you see improvement.
  3. Once you made it better, repeat.

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

Good XP Practices

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.

  • The Planning Game — Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan.
  • Small releases — Put a simple system into production quickly, then release new versions on a very short cycle.
  • Metaphor — Guide all development with a simple shared story of how the whole system works.
  • Simple design — The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered.
  • Testing — Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished.
  • Refactoring — Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility.
  • Pair programming — All production code is written with two programmers at one machine.
  • Collective ownership — Anyone can change any code anywhere in the system at any time.
  • Continuous integration — Integrate and build the system many times a day, every time a task is completed.
  • 40 hour week — Work no more than 40 hours a week as a rule. Never work overtime a second week in a row.
  • On-site customer — Include a real, live user on the team, available full-time to answer questions.
  • Coding standards — Programmers write all code in accordance with rules emphasizing communication through the code.

Based on these practices, I think a good agile process should have the following practices (from the XP process).

  • Small releases. A small release lets you find problems quickly and correct them right away.
  • Simple design. There is no point on spending too much time designing for the future; nonetheless, some time should be spent on creating a good design, as a bad one can kill or seriously slow down development. No you cannot really refactor a bad design, you would have to rewrite it.
  • Testing and Refactoring. We all say we do it, but I think we should be doing more of it. This is essential.
  • Continuous integration. It’s critical, as a lot of problems are exposed by integrating.
  • 40-hour week. This is very important. I don’t know about you, but I’m tired after work. I noticed that when I stay overtime from time to time, I enbug the system. Really. I put a lot more bugs into the system than normal. Plus, programmers have a life (we do).

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.

Favorite Quote




Currently Reading


© 2001-2024 Stanley Kubasek About me :: Contact me

Me on Twitter

»see more

Recent Entries