Why hide the implementation of a class?

Question

Why hide the implementation of a class?

Navigation

#1 by (7 votes)

6

This is the concept that I have tried hard to understand, but I have never fully achieved it.

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

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

I can not understand how it would be possible for the client to write code that depended on the implementation of the class, since the local variables of the method and the private fields of the class are inaccessible anyway.

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

In my view of lay people, I think it is more interesting to make implementations visible since the programmer may be curious about how such a method works, just as someone might want to know why pushing a radio button station changes, for example.

java classes encapsulamento

asked by anonymous 10.09.2017 / 16:30

1 answer

How does PostgreSQL inheritance work? What is the difference between halt, poweroff and reboot?

score 7 · Answer 1

This has to do with Open-Close principle of SOLID . Whenever you put public, or even protected, behavior in a class and allow this class to be inherited you have a responsibility to that, any change has to be well thought out so that the inherited classes are not affected by a change that you do it in the class.

In a way it has to do with the Liskov principle since you do not just have to respect the contract established in superclass , you need to ensure that the behavior is expected by whoever inherited it.

But if you change in a way that does not break anything, everything is ok.

So the fewer things put inside the larger class the chance of something breaking. One way is to put certain features in utility classes , another is to create static members in the class itself. One way that helps a bit is to have non-virtual members , so these members can not be inherited. But the most effective is to put it away because there is more freedom to move as you want.

One of the problems occurs when you add a new method. Imagine that the descendant class might have a method of it with a identical signature . What should it perform? Things are starting to get less predictable.

Note that everything that is private does not matter at all. Perhaps the doubt has arisen from there, what the book talks about is about 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 everything did not make sense so far because I was misreading the concept.

Making the source visible has nothing to do with leaving public. You want to leave the source open, leave, this has nothing to do with the visibility concept of the members of a type that is something internal of the code and not how you manage the project as a whole. Decrease visibility is not about protecting the font .