2.private类继承和访问控制问题

The truth about private

Mr. Happy Object returns to teach a lesson about how Java handles inheritance and aclearcase/" target="_blank" >ccess control

Summary
-->-->



After I read your earlier Java Q&A, "," I tried this code out. Surprisingly, it compiled:


class Top   
{   
  public Top()    {}

  private void toplevel()  
  {
    int i = 2;
  }
}
class Bottom extends Top    
{
  public Bottom() {}

  private void toplevel()  
  {
    int j = 3;
  }
}
public class RunIt  
{
  public static void main(String[] args)  
  {
    Bottom b = new Bottom();
    Top T = new Top();
    System.out.println("working");
  }
}

Am I missing something here?
Yes, something is missing here: a deep understanding of inheritance and Java@#s access-control rules. Don@#t feel bad, though; many people new to Java or object-oriented programming in general fall into this same trap. In a way, everyone "inherits" the same confusion. That@#s why I am here: to fix confusion wherever it may lurk!
In my answer to "," I claimed that a subclass couldn@#t override a superclass@#s private methods. And indeed, a subclass cannot override a superclass@#s private methods.
Oh, sure, you can define a method in the subclass that has the same name as a private method in the superclass. It will compile and it will even run. However, if you@#re trying to override some behavior defined in the superclass, the subclass will not behave in the way that you might expect.
Let@#s take a look at your example:


class Top   
{   
  public Top()    {}

  private void toplevel()  
  {
    int i = 2;
  }
}
class Bottom extends Top    
{
  public Bottom() {}

  private void toplevel()  
  {
    int j = 3;
  }
}

Here we see two classes: Top and Bottom. Top defines a method private void toplevel() and Bottom defines a method private void toplevel(). This code compiles and runs. However, Bottom::toplevel() has not overridden Top::toplevel(). Unfortunately, it is difficult to explain why given this example. So, let@#s consider another example.
First, let@#s define MrHappyObject. He@#s happy:


public class MrHappyObject
{
  private String getMood()
  {
    return "happy";
  }
  public String howDoYouFeel()
  {
    return "I feel " + getMood() + "!";
  }
}

Next, let@#s define MrSadObject. He@#s sad:


public class MrSadObject
  extends MrHappyObject
{
  private String getMood()
  {
    return "sad";
  }
}

Here we have two classes. The superclass defines a public method howDoYouFeel() and a private method getMood(). The subclass inherits the howDoYouFeel() method from MrHappyObject. Likewise, the subclass defines a private method getMood().
Now, if a subclass could truly override a superclass@#s private methods, we would expect to hear MrHappyObject tell us that he is happy and MrSadObject tell us that he is sad. Let@#s define a PsychiatristObject that will ask each object how it feels:


public class PsychiatristObject
{
  public static void main(String[] args)
  {
    MrHappyObject mho = new MrHappyObject();
    MrSadObject   mso = new MrSadObject();

    System.out.println("How do you feel, Mr. Happy Object?");
    System.out.println(mho.howDoYouFeel());
    System.out.println("");
    System.out.println("How do you feel, Mr. Sad Object?");
    System.out.println(mso.howDoYouFeel());
    System.out.println("Thank you, objects. That will be $200 for your consultation.");
  }
}

Upon executing the PsychiatristObject, we get:


How do you feel, Mr. Happy Object?
I feel happy!

How do you feel, Mr. Sad Object?
I feel happy!
Thank you, objects. That will be $200 for your consultation.

As you can see, even though we defined a method named getMood in the subclass, we didn@#t really override anything.
Overriding getMood() fails since the JVM won@#t check to see if getMood() is overridden when howDoYouFeel() calls it. The JVM won@#t make the check since we defined getMood() as private.
Let@#s fix MrHappyObject so that we can override the mood:


public class MrHappyObject
{
  protected String getMood()
  {
    return "happy";
  }
  public String howDoYouFeel()
  {
    return "I feel " + getMood() + "!";
  }
}

Now upon execution of the PsychiatristObject we get:


How do you feel, Mr. Happy Object?
I feel happy!

How do you feel, Mr. Sad Object?
I feel sad!
Thank you, objects. That will be $200 for your consultation.

Because we@#ve now declared getMood() as protected, it is visible to the subclass and we may override it.
When you extend an object, the subclass can only see its superclass@#s protected and public methods. The access control prevents the subclass from having access to anything declared as private. However, as the reader@#s example illustrates, the subclass can have a member or method that matches the definition of some private method or member in the superclass. This naming clash is possible since the superclass@#s private member or method is invisible to the subclass.
Since the access control of getMood() has changed from private to protected, you must also change the access control to at least protected in all subclasses. Remember, subclasses may only widen control access to overridden methods. They may not limit access beyond what the superclass defines. With that in mind, here@#s the new MrSadObject:


public class MrSadObject
  extends MrHappyObject
{
  protected String getMood()
  {
    return "sad";
  }
}

One more thing, before I get a million and one emails -- MrHappyObject and MrSadObject comprise a crummy inheritance hierarchy. This is a contrived example meant to illustrate the fact that you cannot override private methods. It is not meant to teach good class/inheritance design. 

原文转自：http://www.ltesting.net