Develop perfectly with proper principles

Developers develop their software with great anticipation and curiosity. The main goal of every developer is to create high-quality simplest code that can deliver in less amount time. World-class Developers have already found easy ways to improve the internal quality of the code. Let’s talk about that in more detail now!

Why do we need proper principles?

When we are developing software, the code might become complex if the developer follows a bad design. Therefore, we should follow the proper principles to build well-designed applications. One of the proper principles that I found is the S.O.L.I.D principle. This might be a little hard to understand, but it is worth it.

S.O.L.I.D principles

S.O.L.I.D stands for,

S — Single responsibility

O — Open close

L — Liskov substitution

I — Interface segregation

D — Dependency inversion

Single responsibility principle

As the name suggests, this speaks to two main things.

1. There should be only one reason to change a class.
2. A class should have only one job.

Our class should not be like a Swiss knife wherein if one of them needs to be changed then the entire tool needs to be altered. It does not mean that your classes should only contain one method or property. There may be many members as long as they relate to a single responsibility.

The Single Responsibility Principle gives us a good way of identifying classes at the design phase of an application and it makes you think of all the ways a class can change. A good separation of responsibilities is done only when we have the full picture of how the application should work.

Open/Closed principle

The Open/closed Principle says, “A software module/class is open for extension and closed for modification”. Here “Open for extension” means, we need to design our module/class in such a way that the new functionality can be added only when new requirements are generated. “Closed for modification” means we have already developed a class and it has gone through unit testing. We should then not alter it until we find bugs. As it says, a class should be open for extensions, we can use inheritance to do this.

Liskov substitution principle

Oops! Don’t be scared of “Liskov” word let me explain this principle. This basically talks about the inheritance relationship that we call “parent-child relationship” but in derived classes prospect. This means you should be able to use any derived class instead of a parent class and have it behave in the same manner without modification. It ensures that a derived class does not affect the behavior of the parent class, in other words, a derived class must be substitutable for its base class.

This principle is just an extension of the Open-Closed Principle, and it means that we must ensure that new derived classes extend the base classes without changing their behavior. I will explain this with a real-world example that violates Liskov substitution principle.

A father is a doctor whereas his son wants to become a cricketer. So here the son can’t replace his father even though they both belong to the same family hierarchy.

Interface segregation principle

The Interface Segregation Principle states that clients should not be forced to implement methods they don’t use. Instead of one fat interface, many small interfaces are preferred based on groups of methods, each one serving one submodule.

We can define it in another way. An interface should be more closely related to the code that uses it than the code that implements it. So the methods on the interface are defined by which methods the client code needs rather than which methods the class implements. So clients should not be forced to depend upon interfaces that they don’t use.

Dependency inversion principle

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules. Both should depend upon abstractions. Secondly, abstractions should not depend upon details. Details should depend upon abstractions.

High-level modules implement business rules or logic in a system (application). Low-level modules deal with more detailed operations, in other words, they may deal with writing information to databases or passing messages to the operating system or services.

A high-level module that has a dependency on low-level modules or some other class and knows a lot about the other classes it interacts with is said to be tightly coupled. When a class knows explicitly about the design and implementation of another class, it raises the risk that changes to one class will break the other class. So we must keep these high-level and low-level modules loosely coupled as much as we can. To do that, we need to make both of them dependent on abstractions instead of knowing each other.

How to make solutions for problems?

Software engineers use problem-solving skills constantly. Because of that, if you want to become a better developer, one place to start might be becoming a better problem solver. But that’s easier said than done and it requires a deep understanding of what problem-solving is, why it matters, and what it actually takes to improve those skills. So, how can we reach the best solution for the problems in the most feasible way?

· Think throughout the problem: First of all try to understand the problem and business behind that correctly before approaching the solution.

· Divide and conquer: Divide the problem into smaller pieces as the object-oriented concepts tell us to do.

· KISS: Keep it simple and stupid. Do not overthink and make your program complex. Keep it simple.

· Learn from the mistakes: Never hesitate to learn from the mistakes you have made in your program. Mistakes are the best in the early stages because if you can identify mistakes correctly this will help in the long term to avoid them.

· Reason software exists: Imagine the big picture of why this software needs to exist. Having a big picture of the software will guide you along the correct path.

· You will not be using the software: Have a proper idea about the target audience of your software. Because non-technical people will use it. Therefore, try to make them more user friendly.

How to implement the solution after approaching the best solution

· You aren’t going to need it (YAGNI): Write the code that needs for the requirement.

· Don’t repeat yourself: Reuse the code

· Embrace the abstraction

· Don’t reinvent the wheel: Make use of the already solved problem.

· Write the code that does one thing well.

· Debug the code correctly to find errors.

· Kaizen (Leave it better than when you found it): Change the code for better use.

Best practices to make development better

· Unit test: A piece of code to verify the reliability of another piece of code. It will verify that the code runs as expected.

· Code quality: The quality of the code should be measured to make it less complex. Code quality can be achieved manually or with the use of tools like SonarQube.

· Code review: This is the best way to improve the code quality. Code review will increase the code quality with fewer errors.

· Version controlling: Let multiple developers collaborate in the same code. This can be achieved using the famous tool called GitHub.

· Continuous integration: The code should be integrated continuously to detect errors and fix them early. This is also can be achieved using GitHub.