Design core task 2: Information Hiding

If we agree that the construction of software is a complicated process, the complexity of management requires some skills. To find out these skills, you need to first take a look at the basic structure of this complexity.

 

 

The construction process of software involves two basic elements: software, and construction software.

Suppose there is a standard person who has a constant level of intelligence, a constant ability to innovate, and a constant level of skills. The complexity of the software depends on its own, such as the business rules and computing level required by the software. An effective way to deal with such complexity is to optimize the method. For example, the efficiency of fast sorting is usually better than that of Bubble sorting.

 

When we begin to consider human variables, the source of complexity changes. People have many inherent characteristics. For example, people make mistakes and there are limits to what people can do at the same time. Because of these features, when dealing with the complexity of the software itself, people come up with occasional complexity related to personal traits. For example, the local variable name may happen to be the same as a global variable, and we mistakenly use this local variable as a global variable.

 

Information Hiding is an effective means to reduce this unexpected complexity.

For methods or functions, input and output parameters describe their boundaries.

For a class, public attributes and public methods describe its boundary.

Hidden information is contained within the boundary.

 

 

Assume that we use a class named mermermanager to manage the basic information of the customer, but while opening interfaces such as AddCustomer (), EditCustomer (), and DeleteCustomer, it also opens a collection class that stores customer information internally. The user who uses the CustomerManager class may directly obtain customer information through the collection class. Although this practice can be accepted by the compiler, it is actually misuse of the CustomerManager class. To avoid such misuse, the collection class that stores customer information should be hidden so that the user can only see the interface.

 

Information Hiding is a primary reason for the existence of abstract data types and classes. However, information hiding is not meaningful only when abstract data types and classes are used. This principle of information hiding can also be used when an interface is defined or even implemented.

For example, when method A is implemented, only two attributes of the class are actually required, but the entire class is defined as A parameter of this method, which violates the Information Hiding principle.

 

 

Another interesting case is that the purpose is to hide information, but it actually violates the Information Hiding principle.

For example, member variables are often used in class methods. Sometimes attributes that are not closely related to the class itself are added as member variables. For classes that characterize databases, such as databases, most of the time they do not need to be directly associated with classes that obtain data, such as Sensor class Sensor, however, sometimes the Sensor instance is added as the private member variable of the DataBase.

 

At the same time, most of the time, the methods in the class do not regard the member variables as their own parameters, but they are directly used. For example, because the Sensor instance is a private member variable of the DataBase, the DataBase :: gatherData () is used directly when the Sensor instance is used, instead of defining the interface. dataBase: GatherData (Sensor & sensor ). This usage hits the trend of excessive expansion of member variables, and interesting things happen.

 

From the external perspective, a member variable like a sensor is private and achieves information hiding.

However, for methods, the results are completely the opposite.

Every time one member variable is used, its own information is hidden and damaged.

 

If five or six member variables are used in the same method, this method becomes very difficult to understand. Because for methods in the class, the changes of these member variables are completely hidden, and each has its own independent context, such as: DataBase: SetInterval () the status of the Sensro instance may be adjusted, which affects the Sensor: GatherData. This leads to unclear boundary of the method. Not clear, it is impossible to compact. Not compact means that the information required by a method cannot be obtained immediately during reading. In the end, the program is hard to read, difficult to modify, and difficult to maintain.

 

This type of instance reminds us that information hiding is not achieved by placing many operations and data members in the class.

In fact, this limits the possible size of each class. In extreme cases, if a class is large and has 2000 SLOC, then all the 2000SLOC code is equivalent to bonding together through the member variables, this is equivalent to over-using global variables to a certain extent.

 

To the extent of information hiding, for methods, local variables are the best, class members or attributes are slightly different, and global variables are the worst.

Local variables hide information within the method, and members or attributes hide information within the class, while global variables do not hide information.

 

 

 

Information Hiding cannot be separated from the level problem mentioned above. According to the basic trend, the more information is hidden, the more layers there are. As mentioned above, the hierarchy itself has side effects.

 

From the perspective of minimizing the side effects of layers, we can use functions or methods to hide data and use methods similar to abstract data types to encapsulate data into classes. The cost is very small, almost always right. However, if Class A contains B, Class B contains C, and class C contains D, it is A blessing. It is true that B, C, and D are hidden, but they are not without cost.