Good coding practices – Information hiding

I was reading code complete 2, which is an excellent book and I would recommend all CRM developer read it, you will learn lots of things.

The book mentions information hiding, this may be a new concept to some CRM developers because it’s not a term you hear very often.

Steve McConnell the author of Code Complete 2 has a great article on it called Missing in Action: Information Hiding

Information hiding would be a by product of code using the S.O.L.I.D principles

What is information hiding

I find it helpful to use multiple definitions, design principles it can be difficult to understand and different perspectives can be beneficial.

Programming Practices

Information hiding focuses on hiding the non-essential details of functions and code in a program so that they are inaccessible to other components of the software. A software developer applies information hiding in software design and coding to hide unnecessary details from the rest of the program. The objective of information hiding is to minimize complexities among different modules of the software. Note that complexities arise when one program or module in software is dependent on several other programs and modules.

Information Hiding

The basic idea is that if code chunk A doesn’t really need to know something about how code chunk B (which it calls) does its job, don’t make it know it. Then, when that part of B changes, you don’t have to go back and change A.

Hosk Definition of Information hiding

Information hiding is not just about hiding data but hiding how it implements those behaviours. Classes have public methods but hides the private methods and variables which implement the logic behind the public methods

Why is information hiding important

Information hiding reduces dependency on class variables, allowing classes/methods to act like black boxes, hiding logic from the consumers of the class. Hiding variables reduces potential coupling and dependant classes, which will reduce the effect of change on your code.

Information hiding is not just hiding variables but the methods and internal logic. Hiding information results in less code being dependant on concrete classes/implementation, allowing internal workings of classes without needing to change any other classes.

This blog post highlights some good points about information hiding

Why you should care about information hiding

Information hiding makes methods and variables private, hiding the internal logic from other classes. Developers can change the internal logic without changing dependent code.

Methods should only accessed is via the public methods, hiding the internal workings of the class. CRM developer can change the internal workings of the class and not effect any of the classes which call those methods.

If classes have public variables, public variables might be used by other classes creating a dependency, if you change a public variable you need to check the calling classes still work.

Changing the logic of public variables/methods can effect any dependent classes which will result in more code changed, more testing and an increased chance of creating a bug.

To help understand information hiding it’s helpful to think the CRM SDK. When we call IOrganisationService.Update(Entity). We don’t have access to any fields, we have no idea how the code updates the CRM database or what steps it does.

Microsoft could change the IOrganisationService.Update(Entity) to use a different language but because I only consume the public method none of my code would need to change (assuming it works the same way). Code calling the CRM SDK is loosely coupled.

How you use Information hiding outside of coding

Information hiding and Encapsulation in OOP has a great definition of information hiding

“Showing only those details to the outside world which are necessary for the outside world and hiding all other details from the outside world.”

Real life examples

Facebook

You can hide private information from certain people to stop them using it and only show your name.

Computer operating system

Windows/Linux give you a nice GUI operating system to manage your computers but underneath there are lots of private files and programs.

The article Information hiding and Encapsulation in OOP has a good example

Your name and other personal information is stored in your brain we can’t access this information directly. For getting this information we need to ask you about it and it will be up to you how much details you would like to share with us.

Encapsulation

Information hiding isn’t the same as encapsulation but I’m not entirely sure of the difference. Encapsulation and Information hiding share a common goal in hiding business logic.

Wiki quote

Hiding the internals of the object protects its integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state. A supposed benefit of encapsulation is that it can reduce system complexity, and thus increase robustness, by allowing the developer to limit the inter-dependencies between software components^{[citation needed]}.

The benefit of encapsulation, hiding business logic by using private methods and interfaces/abstract classes. Encapsulation limits the effects of change. Encapsulation hides/removes dependency on the concrete code behind your public methods

Information Hiding helps reduce the effects of change

Code changes all the time and there are lots of things which can result in code change

Change in requirements
Fixing a bug
Refactoring
Extension

Developers cannot control change but they can control how the code will be affecting by change. Good code design using the S.O.L.I.D principles will reduce the effect of code changes in the code.

Information hiding is one of the tools developers have to reduce the effect of change, hiding the information will create loosing coupling/low dependency and using interfaces/abstract classes will isolate your concrete implementation code from the rest of the system and create loose coupling.

This design principle is described in the Law of Demeter, which described excellent in this article SOLID Design principles

I find it useful to refer to these principles when writing code because it helps to create

Information hiding helps reduce the complexity of code by creating loosely coupled code and more modular code. Information hiding reduces the dependencies on classes, a class coupled with multiple classes in a system, it’s difficult to understand and change the code because you need to understand how the change would effect all the dependent classes.

Information hiding helps reduce coupling by hiding concrete logic which helps mitigate the effects of changing the concrete logic.

The more independent/loosely coupled code you have the more code reuse you will have.

Benefits of Information hiding