Encapsulation, one of the three characteristics of object-oriented

The program itself covers two characteristics: high cohesion and low coupling

High cohesion is the internal method of the class, which we complete ourselves

Low coupling low coupling means that only a small number of methods are exposed for use

The design idea of packaging is:

Encapsulate the characteristics and behavior of an object into a class, and encapsulate the specific business logic functions into a class

Method to hide the internal complexity of the object and only provide a simple interface for external use

High system scalability and maintainability

Example: the washing machine only provides us with external buttons, which can complete complex operations

Embodiment: privatize the attributes of the class, and provide public methods to obtain (getxxx) and set (setXXX)

Encapsulation is no longer encapsulation if there are no four modifiers: private, default, protected and public…

Modifier classes can only be public and default (optional)

Encapsulation is the best understood of the three object-oriented features. What does it mean? To put it bluntly, it is to seal the key logic and familiarity that are not necessary to be seen by others, and install them so that they will not be seen by others.

How did you do it? Yes, yes, it’s private!

After private is added to the front of methods and properties, some properties and methods are encapsulated, and they will not be exposed to the public.

Let’s start with the benefits:

1. Reduce the time for others to see your class and make it easier for callers to see your code

2. Because properties and some methods are encapsulated, it makes your code logic safer!

Then we have many questions. First of all, we question the above two benefits:

1. If I want to know the logic in the code I write, such as the person class, I can’t just open it directly. I can also see the private code. How can the time be reduced and how can the caller see the code easily?

2. I don’t think it’s easy after packaging? I can still see the code, and so can my colleagues who work with me? Where is safety?

If these two questions are normal, it shows that everyone is still distracted.

Encapsulation, one of the three characteristics of object-oriented

Let me answer the first question:

The first scenario: in actual work, the amount of code we write is much larger than that of person. A class will have hundreds or even thousands of lines, and there will even be dozens of methods. Maybe this class completes several simple functions, but there are dozens of methods to work together, so we only need to expose these simple functions.

For example, the age of a person increases every year. There is no need to let others see the logic of how to increase the age. Because there are too many codes, he may just need to use this class to obtain the age of the person. Therefore, encapsulate the logic of increasing the age (private modifier) and only provide a method to obtain the age (public modifier).

Is it OK to call your class colleagues just to see what methods you expose that can be used? General methods are annotated. Remember the annotation rules I mentioned earlier. The annotation usually says what this method is used for. When you use your class, is it enough to just look at the public methods and properties and their annotations? There is no need to read the whole class. After all, everyone is very busy and needs to race against time to complete the task.

The second scenario: in actual work, many logics are not written by themselves. How to say? For example, the file reading operation uses the class libraries of system IO operation. These class libraries can be used directly by importing classes. There are more codes of these classes, thousands of lines. Can you read them through? Obviously, it is difficult to do, so they encapsulate many operations and provide dozens of public methods, so you can look at the public methods and Javadoc (/ * *)*/ The document generated by annotation in this way is Javadoc, which was mentioned earlier when talking about annotation)

The third scenario: if we write code for a long time and find that some things are often used, such as the tool class of time and date, we can also make it into a class library (in the form of jar or AAR). We are used to calling it SDK, that is, software development kit. These class libraries are provided to your colleagues or other partners, They also don’t care about how you implement it. They just need to know whether the relationship has the functions they need. These functions can be made public. Other things are private encapsulated, so they can read it much easier.

After talking about so many scenes, I don’t know if you understand it. Let me give another example in life to help you understand: for example, the weather is very hot recently, you use the air conditioner, and the remote control is public. You can see it, and there are instructions (Javadoc), so you can use it directly, and you don’t need to care about how to increase and reduce the temperature Air volume control these!

Encapsulation, one of the three characteristics of object-oriented

Answer the second question:

In terms of security, such as humans, which are often used by your company, you should package them into a general SDK. If you write the age field as public, or you disclose a set method

public void setAge(int age) {

this.age = age;

}

It is likely that setage was called by others or person. Name = 12 directly, which modifies the age! In fact, age should follow your algorithm and increase every year. For example, if you suddenly set it to 12 years old last year and 2 years old this year, there will be a problem with the person’s age! So do encapsulation, so that the data will be safe!

This is only the most basic security. If multithreading is mentioned later, it will also involve the problem of data security. It can also reduce the data problems caused by some threads through private.

Leave a Reply

Your email address will not be published. Required fields are marked *