Analysis of JAVA object-oriented Ideology

Object, you can understand it as an entity with attributes and behaviors, which can provide external services. To use this object, you can ignore the internal details. You only need to know the "inputs" and "outputs" when using this service. Therefore, "High Cohesion and low coupling" is the basic idea of object-oriented programming.

For example, we usually need to delete a piece of data in our work. Generally, we do not really delete the data, but use a status icon. status is-1 to indicate deletion, you can write the deletion interface as follows:

Class UserService {

Private UserDao userDao;

Public void deleteUser (User user ){

User. setStatus (-1 );

UserDao. update (user );

}

}

This logic actually executes the update operation, but the interface name is still deleteUser, because it provides the deletion of the "service ", when calling an interface, I only need to know that the object will be deleted when I call this interface.

Pointer references are everywhere in Java. programmers who are used to using C-language pointers tend to use pointers indiscriminately, which breaks the object-oriented idea. For example, I want to query the password of a user, someone may write this:

Class UserService {

Private UserDao userDao;

Public void queryUserPasswd (int id, User user ){

String passwd = userdao. getUserPasswd (id)

User. setPasswd (passwd );

}

}

There is no syntax problem with this method, and the correct value can also be obtained, but it is not appropriate to pass in a user object. I want to get a password and pass a user password, you only need to give an id to return the password to the caller. Why should someone upload another object?

As a project manager, you may encounter an interface that is dumb during your work, just like the delete interface above. Some people will write it like this:

Class UserService {

Public void deleteUser (UserDao userDao, User user User ){

User. setStatus (-1 );

UserDao. update (user );

}

}

This interface is easy to understand. I will delete a user object and upload a userDao to you, which means you will provide services for me and I will give you a tool, this cannot be said!

Java is a pure object-oriented language. When writing Java programs, remember that when you provide services to others, you should not put forward too many additional requirements when providing services to others. This problem is even more serious when the MVC pattern layering is used. When using the MVC mode for development, the entire project is often divided into several layers: action layer, service layer, database processing layer (dao layer), and so on. Each layer is often written by different programmers, in this case, we should remind ourselves that we are providing services for others. A problem often occurs at the beginning of a new project: when adding a piece of data, you must verify the field of the data. The field cannot be blank or long, if there is no verification, it is easy to throw an error. When writing interfaces hierarchically, developers often think that this verification should be done at the upper or lower layers. The data obtained here is correct, at last, no verification was performed. As long as you remember the idea of providing "services", you should not ask others to give you correct data, but handle various abnormal problems, ensure that you can return any data that the user gives you. Of course, in actual projects, the project manager may require that data verification be performed at the service layer.