Why hide the implementation of a class?

Question

This is the concept I’ve worked hard to understand, but I’ve never fully achieved.

I’ll take this excerpt from a Deitel book to illustrate:

It is a better software engineering define member functions outside the class definition. This practice ensures that programmers do not write a client code that depends on your class implementation. If they needed to do that, the client code probably 'would break' if the class implementation were changed.

I cannot understand how it would be possible for the client to write a code that depends on the class implementation, since the local variables of the method and the fields private of the class are inaccessible in any way.

Could someone illustrate a practical example of code in which this could happen? An example library method exposed in which the user would use something specific to the implementation of this method in his code and then a possible change to that implementation by the creator of the library that would break client code. I need an example to understand. I’ve seen millions of conceptual explanations, but none made sense to me.

I find it even, in my layman’s view, more interesting to make implementations visible since the programmer may be curious to know how such a method works, just as one might wonder why when pressing a radio button, the station changes, for example.

Answer 1

This is about the open-close of SOLID. Whenever you put a public behavior, or even protected in a class and allow this class to be inherited you have a responsibility with that, any change has to be very well thought out so that the inherited classes are not affected by a change you make in the class.

In a way, it has to do with liskov principle since you do not only need to respect the contract established in superclass, needs to ensure that the behavior is as expected by those who inherited it.

But if you change in a way that doesn’t break something then it’s okay.

So the fewer things you put into the class the greater the chance of something breaking. One way is to put certain features into utility classes, another is to create static members in the class itself. One way that helps a little is to have nonvirtual members, so at least these members can not be inherited. But the most effective is to put out because there is more freedom to move as you want.

One of the problems occurs when you add a new method. Imagine that the descending class may have a method of it with a identical signature. Which one should it perform? Things begin to get less predictable.

Note that everything private is of no importance. Perhaps the doubt has arisen from this, what the book talks about is the public members only. In the private part do as you wish, the only responsibility is with the class itself that you must have full control. So it all didn’t make sense until now because I was misinterpreting the concept.

Making the source visible has nothing to do with making it public. Want to leave the source open, let it, this has nothing to do with the concept of visibility of members of a kind that is something internal to the code and not how you manage the project as a whole. Decrease visibility is not about protecting the source.