@Override

The @Override will show an error if you are not over riding anything from the parent class. So while everything you said above is true, this is the purpose of it. Take this code for example:

public class Solution {
    public static void main(String[] args) {
        Solution test = new myClass();
        test.doSomething();
    }

    /*private */void doSomething() {
        System.out.println("Some basic code");
    }
}

class myClass extends Solution {
        /*@Override*/
        void doSomething() {
        System.out.println("Code that adds better functionality to doSomething()");
    }
}

Run this code and it will output the doSomething() from the MyClass class. Change the doSomething() in Solution to private, meaning it can't be over ridden, and run the code and the output changes to the output from the Solution.doSomething(). At this point if you add @Override to the MyClass.doSomething() it will show an error alerting you that the method doesn't over ride anything from the parent class. This would prevent a very easy mistake to make in OOP.

It's very interesting! But a few questions: 1) Why we can not override the doSomething() method in the child class if the method is private in the parent class? 2) >>If we change the doSomething() in Solution to private, then the output will change to the output from the Solution.doSomething().<< So, the private doSomething() method is not inherited by the child? The object has the type myClass, so why doesn't JVM perform the method of the myClass? In the topic of "inheritance of static methods" already i met similar phenomenon. Static methods can not been inherited. The same-name static method in the child class just make cover over the same-name static variable from the parent class. The execution depends on where goes the method-calling from (from which class)*, and not on what is the type of the object. * = what is the type of the reference-variable. But the case above is not about static methods!... They are instance-methods.

1) Private means that the method, or field, is hidden and can't be used except by the class that it is in. It wouldn't make sense to be able to override methods that are not supposed to be used in the first place. This restriction is in place so that, as a class designer, you can ensure the integrity of your code. Lets say you make a method that is only to affect the state of your class internally, say something really important and could break your class if it doesn't do its work, and then some random programmer creates their own class that inherits yours, over rides that method. Your inbox could potentially be filled with bug request help and people blaming your code for not working when they went and over rid very important things. 1a) it is important to remember that private means that classes outside the class can't use the private methods/fields in the class. Internal classes have no such restriction. An Iterator object is an example of a class that can access the private members of the object it is created from. 2) In this code I made the variable a Solution variable and the object a MyClass object. Because doSomething() is not over ridden when the Solutions method is private, it defaults to the object types doSomething(). If you were to copy and paste the main method from the Solution class to the MyClass class like this:

public class Solution {
    private void doSomething() {
        System.out.println("Some basic code");
    }
}

class myClass extends Solution {
    public static void main(String[] args) {
        Solution test = new myClass();
        test.doSomething(); //ERROR
    }
        void doSomething() {
        System.out.println("Code that adds better functionality to doSomething()");
    }
}

The test.doSomething() line will now be red because the Solution.doSomething() is private and this code is trying to access it from outside the class.

With static method's objects don't matter. You can call any static method accessible: private ones from inside the class, protected ones from inside the package, and public ones from anywhere; by just using the class name and method name. So if the doSomething() methods were static you would call which one you want by either:

Solution.doSomething();
MyClass.doSomething();

You can use objects, but that just adds confusion in that it will call the variable type's doSomthing() and not specifically the object types:

public class Solution {
    static void doSomething() {
        System.out.println("Solution.doSomething");
    }
}

class myClass extends Solution {
    public static void main(String[] args) {
        Solution test = new myClass();
        test.doSomething();
    }
    static void doSomething() {
        System.out.println("MyClass.doSomething()");
    }
}

Here i just made the methods static. The variable is still of type Solution while the object is type MyClass. When run it outputs "Solution.doSomething()". Of course, it could be easier still just not to have a whole bunch of classes with the same static method names.

Thank You! I think i understand the static method topic. But unfortunatelly i don't quite understand the behavior of a private method in the inheritance-chain. It seems (based on these above examples) can the private method not been inherited? In the child class we can't override it and we can't use it -- so i think in the child class this method doesn't exist! It would be easier to declare: the private method can not been inherited. This is strange for me, because till now i thought this way: the child get everything from the parent class by inheritance, without any exception. Of course, I may have misunderstood something.

A private method is still part of the child class, it just can't be seen, used, or over ridden by the programmer. Take HashSet, for example. Inside the class there are plenty of private fields and methods that you couldn't see or use just by creating a HashSet object. Even if you created a class that extended Hashset you still would not have access to its private members.

After that I was still thinking and experimenting with it a lot, but already the picture has come together:) Thanks!