Object orientation does not need to be encapsulated.

Note: Here 'encapsulation 'refers to the language feature that restricts object access, also known as information hiding ). The original intention of translation is to look at some different ideas. The author's thinking is reasonable at a certain level, but it is completely correct. In short, there is a question of decision-making and angle.

No encapsulated oop?

Python supports object oriented programming, but it is not encapsulated (encapsulation).Many of them are puzzled, but after discussion, the final conclusion is that OO does not need to be encapsulated at all. In python, if two underscores are added before the member name, it indicates that it cannot be used externally, that is, it is not a member of the interface class. But there are also ways to use, of course, the risk is self-care. Python developers call it naming convention encapsulation rather than mandatory encapsulation. Essentially, this is not an encapsulation, nor is it hidden. Why?

Use a computer as a metaphor

I can open my computer, upgrade it, or change parts at any time, which is easy to do. If the hardware manufacturer also starts to use encapsulation, it may be difficult for us to open the chassis again. If we want to add a memory or change something, we can only send it back to the manufacturer.

The above encapsulation limits the use of implementation details. But when it is necessary, you can only do it yourself. There is no limit on the hardware to enable it. Why does the software do this?

Replace encapsulation with Abstraction

An abstract action definition says: 'The act of considering something as a general quality or characteristic, apart from concrete realities, specific objects, or actual instances.'.
In terms of programming, it means to provide an interface on top of the Implementation. You only need to know the interface layer (that is, the abstract layer) without worrying about the implementation details. The difference with encapsulation is that if you want to know the potential details, you can still do it. The vast majority of hardware uses abstraction instead of encapsulation, using a rarely changed interface while allowing advanced users to look at details.

When using abstraction instead of encapsulation, you can clearly see the interface, which is no different from the encapsulation method. We encourage users to use open interfaces, but not limited to them. For interfaces, the effects of abstraction and encapsulation are the same, except that the former allows access to the content behind the scenes. In this way, the user can fully understand the potential risks of his/her behavior.

One instance

Suppose I use a cross-platform GUI library to develop applications. The cross-platform GUI library is easy to use and maintains the same interface on different platforms, saving you a lot of trouble.

Suppose a Windows user wants to add a special feature. At this time, if you stick to encapsulation, you will face the following problems ::

• Implement a new library in the original GUI library, which includes other interfaces.
• It is unlikely that you can contact the vendor for special modification, even if it is feasible, it may not be too late!
• Discard the original library and use the new library on Windows. This is highly risky and costly!

What if you use abstraction instead??In addition to the above options, you can implement the library details, but consider several risks:

• Can other behaviors be damaged.
• The Database Upgrade may cause your modification to fail. Therefore, you must check whether its behavior is still normal during each upgrade.
• Of course, the database vendor may not be willing to provide technical support for you.

That is to say, when using abstraction instead of encapsulation, you must weigh the advantages and disadvantages on your own. I am not encouraging you to use the details, but in some cases, this may be the best solution.

How I do it

In the traditional OO language, I define interfaces as public, and other implementation details are defined in protected. The Gang of Four once said: "Because inheritance exposes the implementation details of the parent class to the subclass, it is often called 'inheritance destroys encapsulation ''".In fact, this is exactly what I want. My users can use the public interface. If needed, they can subclass their own classes.

This has saved me a lot of trouble. I don't have to worry about private, protected, or public. My example is:Keep it stupid simple.

Encapsulation is not secure

It is usually necessary to hide or protect data to prevent users from accessing it. But to discuss security, I think it is extremely bad to implement security through encapsulation.

Conclusion

Depending on the implementation of the details is by no means a good idea, so you can only use the public interface of the class. However, you may need to use some internal details if it doesn't make sense. In this case, you 'd better make the class design more useful, so that you can use it in some professional ways. Users are not idiots. Assuming they are experts, they can use your class properly to solve some problems. If they want to access some details, there is a natural reason for them, maybe there is no other way. Therefore, do not use encapsulation to deal with them.

Original address.

Reprinted please indicate the source: http://blog.csdn.net/horkychen