Common barriers to information hiding

A core tenet of software engineering is information hiding. OOP rose in popularity owing to how well it was able to implement the concept.

When you have information hiding working for you, an entire class of problems simply disappear. I have previously talked about the concept of complexity in software The heart of software engineering and how to manage dependencies Isolating change in software projects. Today we will be looking at some of the barriers that you will likely face in this endeavour.

Hard code

Yes code can in fact become hard. Or more precisely rigid. This happens when you have design that necessitates multiple edits to the codebase for simple changes.

An example I like to use is the case of the tax rate. Since it’s a figure that very rarely changes you will be tempted to simply use the value throughout with statements such as:

employee_net = employee_gross - employee_gross * 0.3

That statement does not seem dangerous at all, I mean at worst you could do a quick search and replace if need be. And that maybe true but what if you had reference to another 0.3?

expected_annual_return = last_year_value * 10.3

Issues like that line the path to programmer hell.

Circular dependencies

This is a nefarious one. It’s power comes from the fact that at the surface it looks like great engineering.

Lets say you have a code such as:


class User(){
  function getUserData($username){
    //fetch db data logic
  function changeSubscription($username){
    $login = new Login();
      //Upgrade subscription level
class Login(){
  function loginUser($username,$password){
    $user = new User();
    $data = $user->getUserData($username);
    if($data['password'] == Hash::value($password)){
      //user login logic
  function checkLoggedIn($username){
    //logic to check if user is online

Hidden in the code is a circular dependency. Now you have no way of testing the User class without having first written the Login class and vice versa.

Global data

So now you have moved your constants out and now save them as global information. But you have done more than just move the constants, you have also moved items you figure get used a lot by different classes out to the global space.

The challenge that this gives you is that you now have to consider what other methods that use the same global variable are doing to it as you are writing this method. You maybe the same developer that wrote both methods, but by forcing yourself to hold this information in your head, you have inadvertently created a fertile ground for bugs.

Instead consider making use of class level variables. While the dependency is still  there, now it is made explicit. You can see at a glance how exactly all the other routines interact with the data.

How do you hide information in your own projects? Reach out to me on twitter at @jchex or in the comment section below.


Published by


Software Project Manager