Showing posts with label OOPS. Show all posts
Showing posts with label OOPS. Show all posts

Wednesday, September 18

OO design principals and fundamentals , Java design principals





Rigidity

Tendency to change is very difficult. Any change will trigger many cascading change. Software modules are tightly coupled So very little flexibility.


Fragility

Tendency to break easily. Any change can trigger a lot of defects in lot of features. Creates unexpected problems . Hard to regress and write a proper test plan . Hard to cover all unit test cases. Bad design


Immobility

Movement is very hard. It requires lot of effort in moving a part of software from one section to other . Refactoring is not easy . A part of system that could be useful somewhere else could not be moved.







Viscosity

A system where doing right things is easy. Smallest change can trigger huge risk. When system becomes more dependent on hacks than actual design refinement Its viscosity is high . When System starts performing poorly and developers have no clue Where is the issue and they are forced to try and apply dangerous quick fixes and workarounds , Viscosity is high

Needless repetition

DRY design principal says Do Not repeat. Repetition makes a code difficult to manage and maintain . Software should be designed in a way that code repetition is avoided.


Opacity

A code having so particular pattern . Tough to understand . Very tough to read it .


SOLID design principals

SRS - single responsibility principal . A class or interface should take care of only one feature and should not mix many. For multiple features multiple classes/interface should be written. If a class has to be changed there should be only one reason of change. Class should never have multiple responsibilities

OPEN CLOSED Principal : A software should be open to extension but closed to modification. Behavior of class ,method ,interface should be extensible but should be available for internal modification. Abstraction is the way to apply this . Subclass of abstract class should be free to extend the features of abstract class But should be restricted to modify existing method or behavior.

LSP -Liskov substitution principal : A variable expected as argument in method should be replaceable by sub class of the argument type.

ISP - Interface segregation principal . Interfaces should be segregated intelligently and should not contain methods related to multiple features . Interface should be written in such a way that tit does not force any of it's client to implement a method forcefully .

DIP - dependency inversion principal . Basically push approach instead of Pull. Instead of a client ask for it's dependencies , those dependencies are plugged in in to the objects at the time of instantiation. Abstraction should not depend upon details instead details should depend upon abstraction


Sunday, July 28

Item 16 : Favor composition ovr inheritance


                 Favor composition over inheritance


How inheritance can be dangerous ?

 
Lets take an example

 public class X{

   public void do(){

    }

}

Public Class Y extends X{


   public void work(){

do();

}

}


1. As clear in above code , Class Y has very strong coupling with class X. If anything changes in superclass X , Y may break dramatically. Suppose In future class X implements a method work with below signature

public int work(){
}


Change is done in class X but it will make class Y uncompilable. SO this kind of dependency can go up to any level and it can be vary dangerous. Every time superclass might not have full visibility to code inside all its subclasses and subclass may be keep noticing what is happening in suerclass all the time. So we need to avoid this strong and unnecessary coupling.


How does composition solves this issue?

Lets see by revising the same example

public class X{

public void do(){

}

}

Public Class Y{
X x=new X();

public void work(){

x.do();

}

}


Here we are creating reference of X class in Y class and invoking method of X class by creating an instance of X class.
Now all that strong coupling is gone. Superclass and subclass are highly independent of each other now. Classes can freely make changes which were dangerous in inheritance situation.


2. Second very good advantage of composition in that It provides method calling flexibility For example

class X implements R
{}
class Y implements R
{}

public class Test{

R r;

}


In Test class using r reference I can invoke methods of X class as well as Y class. This flexibility was never there in inheritance

3. Another great advantage : Unit testing

public class X{

public void do(){

}

}

Public Class Y{
X x=new X();

public void work(){

x.do();

}

}


In above example If state of x instance is not known ,it can easily be mocked up by using some test data and all methods can be easily tested. This was not possible at all in inheritance As you were heavily dependent on superclass to get the state of instance and execute any method.

4. Another good reason why we should avoid inheritance is that Java does not support multiple inheritance.

Lets take an example to understand this :


Class Deposit implements Banking{

 boolean deposit(){
}
}

class Credit implements Banking{
boolean credit(){
}
}
Public class Transaction {

}


In class Transaction , for complete transaction I have to invoke both deposit as well as credit method. I can't inherit both the classes to achieve this . But I can easily use composition to make it happen simply by doing this :

Public class Transaction {
Banking b;
public static void main(String a[])

{

  b=new Deposit();

   if(b.deposit()){

     b=new Credit();
     c.credit();

    }
 }
}




Good to know : 

        1. composition is easily achieved at runtime while inheritance provides its features at                      compile time 

        2. composition is also know as HAS-A relation and inheritance is also known as IS-A                     relation


So make it a habit of always preferring composition over inheritance for various above reasons.