Information hiding. When it is security and when is software weighting?

Question

I'm implementing a Java application and I was wondering which is the balance between good security (information hiding) and software readability. For example, many ways I defined a public Constructor which had inside only a method for an object instance

public class myFrame extends JFrame
{
    /**
     *Constructor
     */
    public myFrame()
    {
        initialize();
    }

    private void initialize () 
    {
       //something that instance a myFrame object
    }

In this way an external class that call a myFrame constructor, can't know HOW myFrame instance its object, but receive only the wanted object. This idea could be applied to any myFrame method, but I see that it wouldn't be great for software readibility,risking making it stuffy.

So, in your opinion, which is the good way? Apply Information hiding to ever method or only for the important ones? What would you do?

I thank you, knowing that your developer experience will develop my mind!

Answer 1

The term "information hiding" is not very usually used. Personally, I have never heard of it and I am Computer Science major. That's why most of us got so confused and you why probably misunderstood it.

When there is a term similar to "information hiding" used, it actually is used in context of security. Information hiding in security usually means some form of security by obscurity - that means that it e.g. tries to hide admin login credential inside the application via some sort of encryption and/or obfuscation. This, however, is always a bad thing to do as it never works.

It turns out that the real meaning of "information hiding" is actually encapsulation (or very close to it). Now, that's a term we all understand. There are more terms related to the same mix of issues, namely abstraction and implementation hiding. There are many different definitons, all the words overlap each other somewhat and somebody even consider them the same.

One is sure, though. Information hiding, encapsulation, abstraction nor implementation hiding don't have anything to do with application security in any way. They all relate to application design and help you achieve a well designed application that is stable, extensible and bug-free.

Your example does not increase the application's security in any way (it's very easy to decompile the bytecode to the source code), neither uses encapsulation.

This is encapsulation:

public class MyClass {
    private String someText;

    public String getSomeText() {
        return someText;
    }

    public void setSomeText(String someText) {
        this.someText = someText;
    }
}

The private field someText is encapsulated, because it can't be accessed directly. It has to be accessed via a getter/setter. The direct access to the field is abstracted away. Now, while this might seem like a needless work, it is helpful in a number of ways:

• if, in the future, you decide that the string should only be non-null, you can change the setter to only accept non-nulls without breaking anyone's code
• if you decide to hand out the string trimmed, you can simply change the getter
• if we weren't talking about immutable String, but about a mutable List, for example, you could hand out defensive copies of your list so no one could alter your list
• if you don't want anyone to change your String, you can simply delete the setter

Etc. Etc. This tactic enables you to grant/restrict access to your fields. It enables you to change your class in the future without breaking the code of your class' users. It is the default way to declare accessors/mutators to a field.

There's much more to encapsulation, abstraction, information hiding etc. The most important topic after field abstraction would definitely be interfaces. Feel free to read about the topics.

Answer 2

Trying to hide or conceive information will give you no security. It can discourage only the weakest attackers and it will provide false sense of safety, which is the worst you can get.

Your example of class initialization is just wrong. First constructors are not inherited so moving your code to some private method won't make any difference. Second, if want to use the initialize() method in ever constructor of you class and nowhere else, use initializers (aka initialization blocks) - they're made for that.