Posts

@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
Post a Comment
Read more

Open-Closed Principle

'A class should be open for extension closed for modification.' The above principle explains that a class once defined should not be changed(closed for modification). This is because it may impact other parts of application. Hence, if modification is needed, that class behaviour should be extended and modification should be done. (open for extension) Consider a scenario where area of a shape(like rectangle, square, circle) is calculated within Main class. Now addition of any new shape will lead to change in Main class. This concludes that the Shape is tightly coupled with Main class. In order to avoid this Shape should be inherited by diff Shape classes like Rect, Triangle, Circle implementing the behaviour of calculating area() and Main class should be loosely coupled by using Shape.area() (as Triangle, Rectangle are Shape). Hence, Shape interface is contract between its concrete classes and Main class. This allows us to add new shape class without any impact on exi
Post a Comment
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
Post a Comment
Read more

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) 
Post a Comment
Read more

Single Responsibility Principle

The class should have only one reason to change. This principle overcomes the below drawbacks- If the class has more than one reason to change, Change in one area impacts the other. This makes the code more fragile (easily to break). Difficult to test and maintain. Tight coupling. Less cohesive (a class has many action) and hence not focusing on what it is suppose to do. Hence, Single responsibility boils down to high cohesion i.e. a class focus on what it should be doing (methods related to the intention of class)  
Post a Comment
Read more

Dependency Injection Principle

Suppose there are two classes - A.java and B.java where A.java consumes B.java as below- class A{    B b = new B(); }  The above code shows that the two classes are tightly coupled and hence have following drawback- In case class A wishes to switch to another class instead of B, say class C then we need to make changes in class A which is not desireable. If A is further inherited by other classes, then change mentioned in point 1 will affect ALL the child classes.  Testing of class A will be difficult because its directly using B hence, mocking of class B is not possible.  One solution to above problem is -    class A{       B b;    } But here, we are asking the calling class to initialize class B for A, which is not a good practise. Also, it still holds above concerns. The above issue is resolved by 'Dependency Injection Princple' which states that - Two classes should be loosely coupled. This can be achieved by an interface or abstract class defining
Post a Comment
Read more

S.O.L.I.D. Class Design Principles

Abbreviation Full Form Definition Reason S Single Responsibility Principle A class should have only one reason to change i.e. should have only one purpose to serve.  - loosely coupled - less change lead to less break down of application - helps to change identity of object without affecting other modules O Open-Closed Principle A class should be open for extension closed for modification. - Anyone need to make change in your class has to inherit the class and change. This allows the existing functionality to stay intact. L Liskov Substitution Principle Derived types should always be substitutable by its parent class (base type). Derived types should be compatible with its base type. For e.g.: Square is a Rectangle i.e. Square represents a Rectangle. In case, if we try to set dimension of a Rectangle reference pointing to Square instance, the flow will be weird as it will always override the dimension of rectangle. I Interface Segrega
Post a Comment
Read more