You probably know different formal principles related to programming paradigms.
For example, in object-oriented programming, we have abstraction, encapsulation, inheritance, and polymorphism. In functional programming, on the other hand, we have purity, immutability, referential transparency, type systems, first-class functions, high order functions, and disciplined state.
But what about general software development principles? Some of them were created having one specific paradigm in mind, but they can be adapted to be used with any programming paradigm.
Here are 6 to take into account when coding.
This principle arose from XP (eXtreme Programming), and it means that you should not add a functionally until you are sure it is needed. Never before that.
The United States Navy noted this principle in the 1960s, but all developers can benefit from applying it. In practice, you should not write unnecessarily complex code that is hard to understand. Instead, simplicity should be your key goal.
This principle means that you should avoid redundant, repeated code. If you need a snippet of code in more than one place, write it in the form of a function or factory and refer to it whenever you need it.
This principle refers to your code’s knowledge about other pieces of code. For example, the less a class knows about the class it depends on, the better.
This principle focuses on assigning separate responsibilities to each function, class, or component in your code. We know it’s tempting to have a single function handling more than one task, but the idea here is that one function = one job. The same is valid for all your code components.
This principle is the most complex one since it consists of 5 principles in itself:
- Single-responsibility principle - is similar to the SOC principle, where every module, class, or function should have only one responsibility in terms of functionality.
- Open-closed principle - software entities should be “open” for extension but “closed” for modification. This means that an entity can have its behavior extended without modifying its source code.
- Liskov substitution principle - functions that use references or pointers to other classes must be able to use objects of derived classes without knowing it. For example, a class and a subclass must be interchangeable.
- Interface segregation principle - having several client-specific interfaces is better than having only one general-purpose interface. You should split larger interfaces into smaller and more specific ones.
- Depedency inversion principle - high-level models should not import anything from low-level ones, and both depend on abstractions (like interfaces).
Do you apply any of these principles?
Do you think they can be helpful while coding?