As we go in Companies we need to make sure that our code is as maintainable as possible and the readability of code should be very high.
code distribution
code structure
unlike HLD LLD is very closely related to the final coding implementation
Design Pattern
→ It is some coding solution to a kind of readability, maintainability & extendibility problem..
<aside> 💡
One thing to keep in mind LLD implementation is both LANGUAGE & ALGORITHM agnostic
</aside>
Now, before we study, design principle/pattern we need to study it’s building blocks and which comes out to be SOLID Principle..
S.O.L.I.D
Single resource Principle(SRP)
Every class should have only one reason to change..{ Theoretically }
Now the issue with this code is that, when the logic of salary or performance Calculation changes there is a need to change the existing implementation of the class employee
if you have too many things in the same piece of code you have too many reasons to change that code
When working on a larger codebase it is very important to keep SRP in mind as there are very high chances that your class can become a “monster Class”
lesser merge conflicts
having multiple files helps
Also point to be noted that SRP is subjective what is a better class to me might not be to you
as there is no hard and fast rule to it
if you look at a file I/O module of any language you would find, both read and the write functions are in the same class
<aside> 💡
<iostream> class in cpp has both cin and cout // HTML converter class will be converted to 2 diffrent classes // 1. Test processor // 2. File Processor -> both read and write file</aside>
OCP - Open closed Principle
The code should be open for extension but closed for modification..
Farsightedness
<aside> 💡
Now a good question to ask is why can’t we use inheritance to solve it ?
it wont be useful everywhere but will be used somewhere
</aside>
Hence we use polymorphism for this..
we will have an interface for it, implementing the core common function of any payment service for eg: process()
then we will have different payment ways have there own classes and basically have their own implementation of processing payments
overriding the process function
and last but not the least we will have the main Payments Service class
which will have a key ( for letting it know if the payment type is upi , credit card , debit card , cash etc. and the process function tamed according to it..
so then in future if we have to add some other method it could follow the same set of rules led by that first developer so that nothing breaks no need to write test again and all..
think of it as define the pr rules of you r repo
<aside> 💡
it is a good idea to be dependent upon abstractions rather then depending on concrete classes
</aside>
The IF-ELSE is not a problem
Liskov Substitution Principle(LSP)
now you may not it but you have either seen it many times or yourself must have implemented it you have coding for sometime
Objects of a superclass shall be replaceable with the objects of its subclass without breaking any thing.
Consider we have a abstract class called creditCard and there are generally
Interface Segregation Principle (ISP)
If there is an interface which has a lot of methods to implement and those methods will not be relevant for every class using that , so then it is better to break it into multiple interfaces and swaad anusaar use karen
and if you don’t have interface and have a class then you can’t even achieve it using inheritance polymorphism saves us form it..
there should be not any kind of forceful behavior imposed on a class which does not require that
<aside> 💡
we still have some code duplication
and if later the logic is changed (both switched to the same algo)
These kind of code duplication problems are solved by design patterns precisely strategic design pattern here.
</aside>
Dependency Inversion Principle ( DIP )
High level modules should not depend on concrete implementations of low level modules directly instead, they should depend on abstractions
service classes are the main algorithm driven classes
here the problem is tight coupling..
→ To improve
there should be an interface ( it defines the blueprint )
so all they now do is just override the pre-written functions (you have to comply the interface )
eg: here order service will have a composition relationship (string has - a ) and thus abstraction will be followed it will be now decided on runtime which whether we will use MYSQL or Mongo
this passing of information and what values are they gonna get during abstraction is what we call DEPENDENCY INJECTION
what objects they are going to be created with
