I'm stuck on this concept.

This is part of an explanation I saw on a site:

> 
> Hiding the Implementation
> 
> 
> A primary consideration in object-oriented design is separating the things that change from the things that stay the same.
> This is particularly important for libraries. Users (client programmers) of that library must be able to rely on the part they use, and know that they won't need to rewrite code if a new version of the library comes out. On the flip side, the library creator must have the freedom to make modifications and improvements with the certainty that the client code won't be affected by those changes.
> This can be achieved through convention. For example, the library programmer must agree to not remove existing methods when modifying a class in the library, since that would break the client programmer's code. The reverse situation is thornier, however. In the case of a field, how can the library creator know which fields have been accessed by client programmers? This is also true with methods that are only part of the implementation of a class, and not meant to be used directly by the client programmer. But what if the library creator wants to rip out an old implementation and put in a new one? Changing any of those members might break a client programmer's code. Thus the library creator is in a strait jacket and can't change anything.
> 
> 
> 

But I can't imagine a real situation where this can happen.

Can someone show me a practical example of this in real life?

This is how I imagine this:

```
public void print(String message)
{
     System.out.println(message);
}

```

What difference does it make if a library client knows this implementation or not?