I'm going to talk about the value of encapsulation from a different perspective using a real example. Quite some time ago (early 80s) a game was written for the Radio Shack Color Computer called Dungeons of Daggorath. Some years ago, Richard Hunerlach ported it from a paper assembler listing to C/C++ (http://mspencer.net/daggorath/dodpcp.html). Some time later, I got the code and began to re-factor it to give better encapsulation, (http://dbp-consulting.com/stuff/).

The code was already factored into different objects to handle scheduling, video, user input, dungeon creation, monsters, etc. but you could definitely tell that it was ported from assembler. My biggest task was to increase encapsulation. By that I mean to get different parts of the code to get their noses out of each other's business. There were many places for example, that would change video variables directly to have some effect. Some did it with error checking, some not, some had subtly different ideas of what changing that thing meant. There was much duplication of code. Instead, the video section needed to have an interface to accomplish the desired tasks, and the code to do it could be all in one place, one idea, one place to debug. That sort of thing was rampant. Every object directly accessed every other object and code was duplicated everywhere.

As the code began to get teased apart, bugs that hadn't even been diagnosed went away. The code became higher quality. Each task became the responsibility of one place in the code and there was only one place to get it right. (I still find more every time I make another pass through the code.)

Everything that is visible about your code is your interface. Whether you mean it to be or not. If you limit visibility as much as possible then you won't be tempted to put code in the wrong place later. It makes it obvious what part of the code is responsible for which data. It makes for better, cleaner, simpler, more elegant design.

If you make an object responsible for its own data, and provide interfaces to everyone else that needs something to happen, your code gets a LOT simpler. It just falls out. You have small simple routines that do only one thing. Less complexity==less bugs.

What do you think?

I'm going to talk about the value of encapsulation from a different perspective using a real example. Quite some time ago (early 80s) a game was written for the Radio Shack Color Computer called Dungeons of Daggorath. Some years ago, Richard Hunerlach ported it from a paper assembler listing to C/C++ (http://mspencer.net/daggorath/dodpcp.html). Some time later, I got the code and began to re-factor it to give better encapsulation, (http://dbp-consulting.com/stuff/).

The code was already factored into different objects to handle scheduling, video, user input, dungeon creation, monsters, etc. but you could definitely tell that it was ported from assembler. My biggest task was to increase encapsulation. By that I mean to get different parts of the code to get their noses out of each other's business. There were many places for example, that would change video variables directly to have some effect. Some did it with error checking, some not, some had subtly different ideas of what changing that thing meant. There was much duplication of code. Instead, the video section needed to have an interface to accomplish the desired tasks, and the code to do it could be all in one place, one idea, one place to debug. That sort of thing was rampant. Every object directly accessed every other object and code was duplicated everywhere.

As the code began to get teased apart, bugs that hadn't even been diagnosed went away. The code became higher quality. Each task became the responsibility of one place in the code and there was only one place to get it right. (I still find more every time I make another pass through the code.)

Everything that is visible about your code is your interface. Whether you mean it to be or not. If you limit visibility as much as possible then you won't be tempted to put code in the wrong place later. It makes it obvious what part of the code is responsible for which data. It makes for better, cleaner, simpler, more elegant design.

If you make an object responsible for its own data, and provide interfaces to everyone else that needs something to happen, your code gets a LOT simpler. It just falls out. You have small simple routines that do only one thing. Less complexity==less bugs.