Showing posts with label java design principals. Show all posts
Showing posts with label java design principals. 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


Monday, August 5

Delegation Design Pattern

Delegation design pattern is used by multiple classes to work collaboratively. Java emphasizes on principal of single responsibility i.e. One class should maintain code only for one specific business responsibility For example An Customer class should be responsible only for managing customer data If it starts managing the customer Orders as well It violates the principal of single responsibility. 

So we tend to segregate our overall business logic in multiple classes . Now to work in network of classes All classes need to talk to each other . If customer has to place an order it needs help of Oder class . 

Now one way to attain the capability of using Order class features in Customer class is  inheritance . Customer class may extend Order class. But Orders is not the only class Customer class is dependent on ,there are many other features that customer require , It will ask for billing of the orders. So there would be a BillManager class. Now java supports only single inheritance So you can not extend more than one class. 

What could be the other way of achieving this . You could use multiple inheritance through interface. Implementing multiple interfaces and writing their corresponding implementation classes might help in achieving the same. But would it be possible in every case to write an interface for every class Customer class is dependent on. While writing code from scratch you might provide this implementation But most of the time people have to work on existing code and there you might not have the scope of redesigning the overall class collaboration. 

So what option is left with us which we can use quite flexibly in new and well as existing code. 

Delegation design pattern provides a way of of managing this collaboration. Delegation says One class should not do everything. Customer class should use Order class code by delegating that responsibility to Order class. Customer class will create an instance of Order class to provide required object state and then on that instance will invoke methods written in Order class. Now there is no direct dependence among classes the way it was required in case of inheritance  This is very clean and loosely coupled way of achieving collaborative functionality. So sharing responsibility to other classes is Delegation and this is one of the java programming design principal .