Best Practices in Programming Based on KISS and SOLID.

On a day today basis, the guidelines a programmer should follow are just as relevant as they are in any area. It will initially seem repetitive and time-consuming to apply these concepts, but over time, the benefits will not go unnoticed. In the later stages of a project, shortcuts, which can save time, can also lead to a number of issues.

KISS Principle.

The principle was coined by the American engineer Kelly Johnson. Literally translated, KISS means “keep it simple and stupid”. This principle is about striving for simplicity. It states that a solution is better when is uses less inheritance, less polymorphism and fewer classes.

Benefits from KISS.

· You will be able to solve more problems, faster.

· You will be able to produce code to solve complex problems in fewer lines of code.

· You will be able to produce higher quality code.

· You will be able to build larger systems, easier to maintain.

· Your code base will be more flexible, easier to extend, modify or refactor when new requirements arrive.

· You will be able to achieve more than ever imagined.

· You will be able to work in large development groups and large projects since all the code is stupid simple.

This does not mean that features like inheritance and polymorphism should not be used at all. Rather they should only be used when they are necessary or there is some substantial advantage in using them.

SOLID Principles.

Robert C. Martin is responsible for establishing the five rules of Solid. In OOP, SOLID is a mnemonic acronym for five design principles intended to make software designs more flexible, understandable and maintainable. Adopting these practices an also contribute to avoiding code smells, refactoring code, and agile or adaptive software development.

1. S — Single Responsibility principle — a class should only have a single responsibility, that is, only changes to one part of the software’s specification should be able to affect the specification of the class.

Benefits

· If your code adheres to this one, it is easier to be followed, understood, debugged, removed, and refactored.

· You can make more courageous changes. After some years you might want to change things, and respecting this principle is going to be a vital key for easier changes.

· Also, if you break something, you break one thing or fewer, not an entire system.

2. O — Open — Closed principle — software entities should be open for extension, but closed for modification. This means that a class should be extendable without modifying the class itself.

Benefits

· By following it, changes and usage of objects become cheap in matter of time and risks.

· Objects can evolve with the possibility of working on them step by step, when needed.

· Changes and usage of objects become cheaper not always feeling like you have to rewrite everything.

· When you can’t rewrite, just leave the past behind to be rewritten in small step.

3. L — Liskov Substitution principle — objects in a program should be replaceable with instances of their sub-types without altering the correctness of that program.

Benefits

· It is about many objects which can be easily replaced by objects of the same nature.

· New features around an existing one and changes are subjects of this principle.

· Integrate new objects fast.

4. I — Interface Segregation principle — many client-specific interfaces are better than one — general purpose interface. A client should never be forced to implement an interface that it does not use, or client should not be forced to depend on methods they do not use.

In practice, this means that the interfaces created should be dedicated to only one functionality.

Benefits

· The developer will have a clear way to use exactly what they need, instead of being forced to interact with functionalities they do not need.

· Less code.

· Fewer problems.

· Closer deadlines.

5. D — Dependency Inversion principle — depend upon abstractions, not concretions. This principle allows for decoupling. This principle essentially makes the code universal. It says that all dependencies should depend as much as possible on abstraction, not on a particular type.

Benefits

· By sending dependencies from the outside world, you can change them more easily.

· We can test our units of code.

Projects that adhere to SOLID principles can be shared with collaborators, extended, modified, tested, and refactored with fewer complications.

From my own experience, I know that code written with best practices from the beginning is much easier to develop.