SOLID Software Design Principles in Java

Code Fragility:
Fragility is the tendency of the software to break in many places every time it is changed.
- Robert C. Martin

Code Rigidity:
Rigidity is the tendency for software to be difficult to change, even in simple ways. Every change causes a cascade of subsequent changes in dependent modules.
- Robert C. Martin

The choice you have to make is
Fast Delivery
Easiest fix/change
Fast
Poor written code
Low Customer Responsiveness over the time
High cost of implementing change

Vs

Code quality
Takes more time
Adds a bit of complexity
Maintainable
High Customer Responsiveness over the time.
Avg cost of implementing change

Technical Debt: The cost of prioritizing fast delivery over code quality over longer period of time.

No matter how good the team is, technical debt will accumulate over time. If it is left uncontrolled, it will kill your project. The key is to keep it under control.
How to pay technical debt: write code and pay debt(refactor) then write some more code and refactor again.

Benefits of SOLID code:
- Easy to understand
- Changes are faster and have a minimum risk level.
- Highly maintainable over long periods of time.

Other ways to keep your architecture clean
- Constant refactoring
- Design patterns
- Unit Testing (TDD)

SOLID Principles:
Single Responsibility Principle
Open Closed Principle
Liskovs Substitution Principle
Interface Segregation Principle
Dependency Injection Principle



Single Responsibility Principle:
A class or function or Module should have only one reason for change. reason meaning responsibility here, beyond specific responsibility assigned to one function/class/module we should not make any other changes to it.

Name of the Single Responsibility Principle class is expressive and name of functions with in the class need to be inline with the purpose of the class.

Advantages of single responsibility principle:
- It makes code easier to understand, code and design.
- Classes are less coupled and more resilient to change.
- More testable design.




SRP Example:
While reading class or component name we need to feel name is implicit with purpose and methods also inline with purpose.

class ConsoleLogger {
void logInfo(String msg) {
    System.out.println(msg);
    }
void logError(String msg, Exception e) {...}
}

Symptoms of Not Using SRP
- Code is more difficult to read and reason about.
- Decreased quality due to testing difficulty.
- Side effects.
-  High coupling : the level of inter - dependency between various software components.

Open Closed Principle:
Classes functions and Modules should be closed for modification but open for extension.

Closed for Modification meaning, new feature should not change/modify existing source code. Open for extension meaning, a component should be extendable to behave it in new ways.

Advantages of OCP: 
- new features can be added with minimal cost.
- minimizes regression bugs.
- enforce decoupling by isolating changes in some components, works along with SRP.

Best Practices for changing APIs
-do not change existing public contracts: data classes, signatures
-expose abstractions to your customers, let them add new features on top of your framework. 
- if breaking change is inevitable, give your customers time to adapt.

Liskov Substitution Principle: 
Any object of a type must be substitutable by object of derived type without altering correctness of the program.

Ex:
Honda Amaze is a Kind of Car
Peacock is a kind of Bird

Bird class is substitutable by Peacock
Car is substitutable by Honda Amaze 

Interface segregation principle:

States that no client is forced to use methods it does not use. Imagine a scenario where there is an interface with lot many number of methods and the implementing classes of this interface need to implement only some of the methods.