@Overrride annotation introduced in Java1.5

Whenever we have a subclass that implements parent method it is marked with annotation as @Override. This is to make compiler know that the child overrides the method defined or declared in parent.

If @Overrride annotation is commented, the subclass will work as it was.
But if in future, the signature of parent class changes, the compiler wont ask to implement the method instead it will think subclass has overloaded the method present in base class.

If you uncomment @Override annotation, the compiler will throw compile time error as method signature in parent class has changed.

Annotation should be used as standard as-

  • It ensures that for any change in method signature of parent class, compiler will ask to change it for the subclasses.   
  • Also it is better to resolve issue in compile time rather than runtime

Comments

Post a Comment

Popular posts from this blog

Liskov Substitution Principle (LSP)

Subtypes must be substitutable for their base types. This principle supports the below scenario-    Suppose a method takes parent type and perform some operation on it.    And the subtype is not of type - parent but still wrongly inherits the parent.        If the above subtype object is passed to such method, the operation performed will be weird as the method assumes it is suppose to be parent type. Hence, a class should inherit parent only if its of that type. (eg: Square is not Rectangle programmatically as the area is always side^2) 
Read more

Interface Segregation Principle

'Clients should not be forced to depend upon interfaces having methods that client do not need.' This principle is closely related to Single Responsibility Principle as it supports the idea of having a specific interface than a generic purpose interface (known as 'Fat Interface' or 'Polluted Interface'). If we have a single interface having various functionality, a child implementing that interface will implement desired method along with all the other unwanted methods of that interface for no reason. An interface declaring much more work should be break down to small interfaces that specifies its purpose. This allows the child class to inherit the interface it wants, to achieve a purpose. For eg:    public interface DocumentGenerator{       public void abstract generateWordDoc( );       public void abstract generatePdf( );       public void abstract generateTxt( );    }    class OutBound implements DocumentGenerator {       pub
Read more