Encapsulation of object-oriented family

This is the fourth day of my participation in Gwen Challenge

Encapsulation is based on abstraction to decide whether information is to be disclosed, as well as the level of disclosure, and what information is to be exposed in what way.

Abstract is to find the commonness between members and behaviors, members are the basic means of production of behaviors, with a certain sensitivity, can not be directly exposed. The main task of encapsulation is to hide members, data, and some internal sensitive behaviors.

Access to and modification of members must be done by defining common interfaces, and some sensitive methods or external complex logic processing that does not need to be perceived are generally encapsulated.

Like smart speakers, the only interface with the user is voice input, which encapsulates the internal implementation details and related data.

Demeter’s Law, one of the seven principles of design pattern, also explains the requirements of encapsulation: Interface A uses interface B and knows as little as possible about B.

package

The name package clearly reflects the meaning of encapsulation. It can package a module together and open it to users by several interfaces. Users can only see the interface information, not the interface implementation. In addition, packages solve the problem of the same name, the same class name is not allowed in the same path, switch package path can be given the same class name.

Access control

We write programs that allow users to see some information and not others, and that involves information hiding.

Information hiding is one of the most important features of object-oriented programming. It prevents users of a class from accidentally corrupting data. Changes to any implementation details do not affect other code that uses the class and make the class easier to use.

Then in Java, the realization of information hiding is access control mechanism. Java access control has four access modifiers: public, protected, private, and default. You can use these four access modifiers to modify members of a class, and their accessibility at different locations is shown in the table below.

Location \ access modifier	public	protected	The default	private
This class	can	can	can	can
This package	can	can	can	Can not be
A subclass	can	can	Can not be	Can not be
all	can	Can not be	Can not be	Can not be

You’ll find that public is unrestricted and can be accessed arbitrarily (globally friendly) by both classes and non-classes. Protected This class and its subclasses are accessible (parent-child friendly), as are other classes in the same package (in-package friendly). By default, only classes in the same package are accessible (package-friendly). Private Only this class can be accessed, the rest can not (class friendly).

In addition to adding access control for class members, you can also add access modifiers to control the access of a class when defining it. However, there are only two access modifiers for classes, public and default, and the access scope is global friendly and package friendly, respectively.

Getter and setter

To keep class members from being exposed directly, we often make access to member variables private and access and modify member values using the corresponding getter/setter methods. Instead of reading and modifying members of public.

package cn.java4u.oo.packagedemo;

/** * getter and setter demo *@authorThe snail *@fromPublic number: snail Internet */
public class GetterSetterDemo {

    /** * Privatize member variables */
    private String name;

    /** * Public method to get member variable value **@returnName * /
    public String getName(a) {
        return name;
    }

    /** * Exposes the method to set the member variable value **@paramName the name * /
    public void setName(String name) {
        this.name = name; }}Copy the code