Solid principles that we need to know to become a good software developer - Flutter Interview Questions

SOLID is one of the most common Software Development patterns, and in nearly every Interview, you will get at least asked once about it. Therefore SOLID is an essential part of Software Developing, and everyone should have an apparent picture of it.

Solid Management - Flutter




There are 5 SOLID Principles you should learn to avoid Bad Software Patterns. they are:
  • S - Single Responsibility Principle
  • O - Open Closed Principle
  • L - Liskov Substitution Principle
  • I - Interface Segregation Principle
  • D - Dependency Inversion Principle

Single Responsibility Principle

A Class/Function/method should have only one reason to change, meaning that a class should have only one job.

For Example:

    A class like Car should only take care of the problems of a Car, if you have a method that makes an HTTP request it should know and understand how this HTTP request works so for example you have a try-catch and down in the catch you would do something like logging that is not really the work for this HTTP request method so you should u like understand how you can create a logger or something can make this possible so that you can abstract these different parts and you have one responsible for your Function, Class and other things, this practice will improve a lot of your code and make it way more readable and because other developers will understand how it works.

Single Responsibility Principle belongs out of two different things:

    1.  Reason to change -> Only one reason to change 
    2. A Single Responsibility - >  Ex. if we have a Data classes that should be responsible for data of a specific type not for the handling of how the register is working or anything like that


Open Closed Principle

An Open Closed Principle states that the Objects or entities should be open for extension but closed for modification which means that a class should be extendable without modifying the class itself.

For Example:

Let's try to give a real-world example:-  let's assume you have a power plug you put on the wall and you can't do anything on it like you can't move it around, you can't modify it or you can't change how it works. Now you have another plug or multiple plugs but what you can do is you can take a power board and connect it to it now you have an extended plug and works the same as before.

Liskov Substitution Principle

Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T which means that every subclass or derived class should be substitutable for their base or parent class.

For Example:

The Coffee Machine - Let's assume, you have a basic coffee machine as a user you want coffee so you press a button and it will call a method to make coffee and then you get a coffee. Now we are replacing the old coffee machine with a new premium one with a grinder that makes a special coffee inside it knows way smarter and it knows the exact temperature that needs but in the end as a user still just a call to make a coffee you don't really care how to make a coffee right you don't want to take care of all these pieces of stuff so you can replace both of them very easily and this makes it possible with the list of principle.

Interface Segregation Principle

A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on Methods/ Functions they do not use.

Dependency Inversion Principle

Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions.

For Example:


We want to copy something with our printer, the copy function will have two dependency 
  1. keyboard 
  2. Printer 
It gets input from the Keyboard and send it to the printer these both are low level dependencies if we would connect our copy function right away to these two things then in order to change something in the lower layers if we want to change our printer how it behaves, if you want to change how the other stuffs behaves we would to have to replace and change something in all three classes maybe and these would mean that we have to change the copy function on top of it even through that down there has something changed and we don't want that so far that we create an abstraction layer that these things can connect each other and this has been done with the dependency inversion principle.

Comments

Popular posts from this blog

Error Handling in Flutter - Gradle issue

How to Make a Dynamic and Trending ListView with Flutter Widgets?

Understanding API integration with Getx State management