Approach To Application Framework
Welcome everyone, this blog is about to provide in depth of Mern Stack technologies. Before we jump into the main topic directly, we should have a solid background about Application Frameworks. This post is here to give you that.
First of all, we have to figure out what is a Application Framework?
An Application Framework is a platform to build software applications. It acts as a skeleton to support development of applications. Adhering to the terms and guidance that provided by the team of developers who has developed the framework, we can develop software applications conveniently.
Three principles of Application Framework,
1. S.O.L.I.D
2. Approaching the solution
3. Implementing the solution
1. S.O.L.I.D
S - Single responsibility principle; A class should have one and only one reason to change, meaning that a class should have only one job. If there are more jobs, you should create classes for each job. This way, you can develop software applications easily. Hence there is lower coupling, modifications are easy and quickly. Fewer testing is another advantage.
O - Open closed principle; A class should be easily extendable without modifying the class itself. There is a restriction to modify existing class, because it can leads to new bugs. This enables loosely coupling.
L - Liskov substitution principle; Every sub class should be substitutable for their parent class. Simply mens that, objects of a sub class should behave in the same way as the objects of its super class.
I - Interface segregation principle; A client should never be forced to implement an interface that it does not use. This concept can be easily violate when the software grows eventually. Larger interfaces should be split into independent components those components only need to be concerned about the methods are of interests to them.
D - Dependency inversion principle; Entities must depend on abstractions not on concretions. It means that high level modules should not depend on low level module, but they should depend on abstraction. This can be achieved by following both Open/closed principle and Liskov substitutable principle. coupling will be reduced.
2. Approaching the solution
Before approaching the solution, you have to think through the problem. You should understand the problem that you are going to resolve thoroughly. Make clear the unclear parts and do not be afraid to ask any questions. You have to clear out all the requirements and needs before designing the solution, otherwise you will be in trouble.
After understanding the problem properly, you have to divide it into smaller problems, because it is manageable and more easily understandable. Later you can merge the solution of all smaller problems to obtain the solution of the main problem.
Keep the solution simple and stupid. Simple solution is better than a complex one, even if it looks like stupid. You have to learn from your mistakes. There is a saying "Experience is your best teacher", everyone do mistakes, but few of them are learning from those. Learning from mistakes is the best way to grow up. Always anticipate the changes, and you should embrace the change, because client's requirements are always changing. You should always keep in your mind that what is the main purpose of this software is. Loosing that might cause going on wrong path. Remember that, end-user is not that technically capable as same as you are and do not assume that user will understand the logic. Therefore, user friendliness and user experience matters. Always consider from the user perspective than the domain perspective.
3. Implementing the solution
YAGNI - You aren't gonna need it; A phrase extracted from Extreme Programming. It means, do not write code that is no use in present, but guessing that will come in handy in the future. Always implement things when you actually need them, because future requirements are always changing. Please avoid duplication in logic through abstraction. Always try to reuse the code that you write. Keep the code generalize and reusable. Abstraction is the most powerful concept in object oriented programming. It promotes the code quality, re-usability, modularity and maintainability.
Do not try to design a solution from scratch, when a solution already exists. Get the use of that. Extend the already implemented solution as your need. This can save your valuable time and effort. A method with just few lines of code is quite typical of well designed application. Spend less time trying to figure out what certain code segments actually do and more time on fixing, revising, extending, etc.
Remember that debugging is harder than writing the code. So, make it readable as much as possible. Readable code is better than compact code. When you found a bug, just not only fix it, but the code around it. Constantly ask team members to evaluate their own work, and to help review the work of their peers. Then teams tend to detect errors and shortcomings at the right time. Specially, you should do these things as best practices; Unit testing, code quality, code review, version controlling, continuous integration.
See you all in another post soon. Have a Good Day!!
An Application Framework is a platform to build software applications. It acts as a skeleton to support development of applications. Adhering to the terms and guidance that provided by the team of developers who has developed the framework, we can develop software applications conveniently.
Three principles of Application Framework,
1. S.O.L.I.D
2. Approaching the solution
3. Implementing the solution
1. S.O.L.I.D
S - Single responsibility principle; A class should have one and only one reason to change, meaning that a class should have only one job. If there are more jobs, you should create classes for each job. This way, you can develop software applications easily. Hence there is lower coupling, modifications are easy and quickly. Fewer testing is another advantage.
O - Open closed principle; A class should be easily extendable without modifying the class itself. There is a restriction to modify existing class, because it can leads to new bugs. This enables loosely coupling.
L - Liskov substitution principle; Every sub class should be substitutable for their parent class. Simply mens that, objects of a sub class should behave in the same way as the objects of its super class.
I - Interface segregation principle; A client should never be forced to implement an interface that it does not use. This concept can be easily violate when the software grows eventually. Larger interfaces should be split into independent components those components only need to be concerned about the methods are of interests to them.
D - Dependency inversion principle; Entities must depend on abstractions not on concretions. It means that high level modules should not depend on low level module, but they should depend on abstraction. This can be achieved by following both Open/closed principle and Liskov substitutable principle. coupling will be reduced.
2. Approaching the solution
Before approaching the solution, you have to think through the problem. You should understand the problem that you are going to resolve thoroughly. Make clear the unclear parts and do not be afraid to ask any questions. You have to clear out all the requirements and needs before designing the solution, otherwise you will be in trouble.
After understanding the problem properly, you have to divide it into smaller problems, because it is manageable and more easily understandable. Later you can merge the solution of all smaller problems to obtain the solution of the main problem.
Keep the solution simple and stupid. Simple solution is better than a complex one, even if it looks like stupid. You have to learn from your mistakes. There is a saying "Experience is your best teacher", everyone do mistakes, but few of them are learning from those. Learning from mistakes is the best way to grow up. Always anticipate the changes, and you should embrace the change, because client's requirements are always changing. You should always keep in your mind that what is the main purpose of this software is. Loosing that might cause going on wrong path. Remember that, end-user is not that technically capable as same as you are and do not assume that user will understand the logic. Therefore, user friendliness and user experience matters. Always consider from the user perspective than the domain perspective.
3. Implementing the solution
YAGNI - You aren't gonna need it; A phrase extracted from Extreme Programming. It means, do not write code that is no use in present, but guessing that will come in handy in the future. Always implement things when you actually need them, because future requirements are always changing. Please avoid duplication in logic through abstraction. Always try to reuse the code that you write. Keep the code generalize and reusable. Abstraction is the most powerful concept in object oriented programming. It promotes the code quality, re-usability, modularity and maintainability.
Do not try to design a solution from scratch, when a solution already exists. Get the use of that. Extend the already implemented solution as your need. This can save your valuable time and effort. A method with just few lines of code is quite typical of well designed application. Spend less time trying to figure out what certain code segments actually do and more time on fixing, revising, extending, etc.
Remember that debugging is harder than writing the code. So, make it readable as much as possible. Readable code is better than compact code. When you found a bug, just not only fix it, but the code around it. Constantly ask team members to evaluate their own work, and to help review the work of their peers. Then teams tend to detect errors and shortcomings at the right time. Specially, you should do these things as best practices; Unit testing, code quality, code review, version controlling, continuous integration.
See you all in another post soon. Have a Good Day!!
This comment has been removed by the author.
ReplyDelete