Basic skills for Java programmers: Development and Implementation class hiding and Application

Reproduced from: http://www.cn-java.com/www1? Action-viewnews-itemid-68459

More exciting!

I. Basic Recommendations for class hiding

Although it is very easy to hide classes in Java, you only need to use three keywords. But in most cases, the Java programmer is wondering when to hide classes. Indeed, on the Java development language platform, there are usually no strict requirements for classes to be hidden and classes to be hidden. For this reason, developers need to judge based on their own work experience. Even employees with some development experience may not be able to give a good answer to this question. It is difficult to have a unified standard. The following suggestions are also a summary of my Java development work over the past few years. I hope these suggestions can help you solve your problem.

1. Classes of different modules must be hidden from each other. Many application systems have put forward modular design concepts to improve development efficiency. For example, for the recently popular ERP system, if it is designed by module, different personnel can be responsible for their respective modules during development without interfering with each other. When the ERP system is sold, it can also be sold by module, because the functions of each module are relatively independent. Of course, this is just the importance of modular design at the management level, but it is not the focus of our discussion today. Today, we want to talk about how to hide the modules of an application system based on modularity? It is actually very simple. For example, maintenance of basic supplier information, supplier import orders, and accounts payable belong to three different modules: procurement management, inventory management, and receivables and payables management. Now, when designing the accounts receivable and payables module, there is a class that generates accounts payable, which needs to use the supplier information (payment conditions, etc.) in the procurement management module) the supplier purchase documents (product number, quantity, date of arrival, etc.) in the warehouse management module can then generate accurate accounts payable. So how should we implement it during application design? Is this information directly queried from the database in the class corresponding to the Account Payable job, or is it implemented by modifying the corresponding class in the purchase module? Although this can achieve the intended purpose, it is not the best strategy. In my opinion, the best way is that the program developer first designs a class (such as the vender class), which will return information such as the supplier number and payment conditions. Then, the class in the Account Payable job directly calls this class to obtain the required information. On the one hand, this information may be used in many places. If you use SQL code to obtain this information every time you need it, the amount of code will be large. On the contrary, directly calling classes to implement such information is more important. On the other hand, this vender class is hidden from other classes. That is to say, other classes can only pass parameters to this class through predefined interfaces and directly reference the returned results, without modifying the elements inside the class. Even if more than a dozen other classes or applications need to call this class, the returned results will be the same as long as the input parameters are the same. Other classes do not have to worry about incompatibility When referencing the returned results. Therefore, the modular design of applications promotes Java programs to hide between classes. At the same time, the hidden features between Java classes also facilitate the modular design of applications.

2. Data Type classes must be hidden from other classes. In any application development process, you need to design some targeted data types according to the needs of the enterprise. Because the data types provided by applications cannot meet the needs of program developers. For example, you need to design data types such as arrays and records. However, when designing these data types, programmers need a challenge. For example, when developing an ERP system, multiple modules (each module is under the responsibility of different programmers) need to use the same record data type. So is Each programmer designing a data type of record type, or sharing the same data type? If you have different data types, you need to create multiple data types, which is difficult to manage and will also encounter obstacles for subsequent upgrades. If you share a data type of the record type, you are worried that other programmers may be troubled by the accidental modification of the data type. Is there no peaceful coexistence between them? In fact, the application developers can be considered as data creators and business logic developers during application development. Then, data type developers can create classes that define data types according to the needs of other developers. These classes are hidden for the classes developed by other developers. That is to say, other classes cannot modify this data type. This improves the utilization of these data types, and ensures that other classes can reference these classes in a fixed format.

3. classes between the business layer and the presentation layer must be hidden from each other. Those who have used the J2EE development platform certainly know that when developing applications, the business logic layer and the presentation layer are mutually independent. The business logic layer mainly implements some operations, such as material demand planning operations. The presentation layer is only responsible for specific display. For example, you can use the browser client to display the results or the software window to display the calculation results. Although the client uses different methods, its internal operations are the same. In this case, it is best to hide the classes that implement the business logic layer and the classes that implement the presentation layer. Because in the actual development process, they are often completed by different program developers. In order to avoid mutual interference between different program developers and prevent the presentation layer developers from accidentally modifying the Java class at the business logic layer, the class at the business logic layer must be hidden. That is to say, the presentation layer developers only need to know the parameters required by the business logic layer class and the form in which results can be returned. Then, when the class in the presentation layer calls the class in the business logic layer, you only need to enter parameters as required and obtain results according to rules, instead of paying attention to the internal implementation mechanism of the business logic layer class, this reduces the workload of the presentation layer developers. At the same time, developers at the business layer should not modify this class, so that other application developers can reference these classes in the same way.

4. If a business logic is not well-developed, hide it. During application development, some business logic may not have good solutions for the moment, but the required parameters or returned results are correct. In this case, you can create a class for the business logic and hide other classes. In this case, you can directly change the business logic in this class after a better solution is available. Because the class members are hidden from other program personnel, changes to the processing mechanism in the class will not affect the applications developed by other personnel. They only care that you can get accurate results in the shortest time. In this case, it is best to hide the class execution from other classes.

It can be seen that the classes that need to be hidden may be complicated to judge. However, there is a general principle that should be referenced if a class has different programmers. For example, if user a designs a class to calculate the balance of accounts receivable, user B and user C, including user a, need to call this class. It is better to hide this class. Prevent other classes from accidentally modifying their internal implementation methods when calling this class. This will adversely affect the calls of this class by other users.

2. implement three keywords hidden in the Java class

To implement Java class hiding, it is mainly to make it impossible for any program developer to touch the initial part that they should not (such as internal operations of business logic or data types ). Although the project administrator may warn the team members not to directly operate on the Members in the classes designed by other developers many times during the program development process. However, if there is a lack of control measures, these things may happen intentionally or unintentionally. Therefore, some mandatory measures are required to prevent such situations. In addition, the current method of these things must be simple and cannot be too complicated. On the Java platform, three keywords, public, private, and protected, are provided to hide and control classes.

These keywords determine whether the members of a class or class are hidden from other classes and whether they can be operated and modified by other classes. For example, the Public keyword indicates that the following element is available to anyone and can be modified by anyone. The keyword private indicates that no one except the class creator and the internal method of this type can access the service. The key role of protected is similar to private, but it only plays a role in inheritance.

It can be seen that in Java program development, it is very easy to hide classes and a basic skill that Java programmers must master. The difficulty lies in implementing Member hiding in classes and classes as appropriate. This requires programmers to think about it in the Process of program development. The suggestions mentioned above are for your reference.