Why can't the subclass access the private Members of the base class? Why is it designed like this?

Many of my friends asked"Why can't the subclass access the private member of the base class?"? Then many of my friends answered "this is a standard" and "this is a encapsulated feature. I think everyone is right. However, sometimes you need to focus onWhy? Why does Java design private in this way? Or why does object oriented design such a mechanism like this?

 

• Encapsulation: first, private Members have good encapsulation ). This nature is an important element for good design. Because good encapsulation reduces coupling. Service Code can define public functions for customer code. In this way, the customer code can be developed in parallel with the service code. More importantly, if you modify the internal implementation of the Service Code, you do not need to change the customer code.

 

• Subclass is also the Customer Code: the most direct understanding of the Customer Code is to call the code of this class, this is a good understanding. With a deeper understanding, we can extend the customer code to the subclass of this class. Sub-classes are the customer code of the base class. You define a class, write some general methods in it, and even declare that the abstract method requires others to inherit. At this time, the protect member in the base class is the external API, because these methods are visible to the subclass and cannot be modified at will. At this time, if this member is public or protected, it may cause trouble. You cannot change the API at will. Can you imagine some API changes in JDK? At least I will be crazy :)

 

• Principle of expanding access permissions: to extend the topic, there is also Java's restriction on access permissions during override. We all know that Java's access permissions are from small to large:Private-> default-> protected-> Public. If you want to override a method in a base class, the permission of this method of the subclass cannot be smaller than that of the function of the override. This leads to an implicit problem: If your base class has a public method, its subclass contains the public attribute of this method. You cannot private this method of the base class. In other words, once a public function is defined, its subclass must maintain this public method. Therefore, you must be careful to set the method to public.

 

Of course, if you maintain the base class to the final subclass, or the class itself is a non-public class, the principle can be relaxed.

 

By the way, eclipse has the ability to automatically generate standard get/set functions, so it is easy to generate get/set functions. Do not change all Members to public for convenience.

 

For example, if a base class base is written, then someone inherits the base class:

Public class Base {<br/> public String [] data; <br/>}< br/> class Sub extends Base {<br/> public void show () {<br/> System. out. println (Arrays. toString (this. getData (); <br/>}< br/>} 

But one day you find thatArrayListBetter, you can change base:

Public class base {<br/> // Public String [] data; <br/> Public arraylist data; <br/>} 

Then, all base subclasses cannot be compiled, and classes that directly call the data domain of the subclass cannot be compiled. This is a nightmare. Client programmers will pursue you with their eyes :)

Looking back, if the data field of the base is private and accessed by get/set, you can easily modify the base without modifying the subclass:

Public class base {<br/> // Private string [] data; <br/> private arraylist <string> data; </P> <p> Public String [] getdata () {<br/> return (string []) data. toarray (); <br/>}</P> <p> Public void setdata (string [] data) {<br/> This. data = new arraylist <string> (arrays. aslist (data); <br/>}< br/>}Author: Lu Shengyuan <michaellufhl@yahoo.com.cn>