connect tech banner2
connect tech banner1

The 5 most important principles in software development

software design principles

There are several software design principles that we can take into account. But when designing software, it is good to consider at least some of them to avoid making mistakes and hindering the designing process.

In this article, we will first discuss the importance of learning principles: What they are, what advantages they have and how to apply them. Let us see:

  1. What is the meaning of “Don’t repeat yourself”?
  2. How can we use the “KIS” principle?
  3. What is the “YAGNI” principle?
  4. SOLID Principles: What are they?
  5. How does the “Boy Scout” rule work?
  6. What can we say about these software design principles at Connect Tech?

1. What is the meaning of “don’t repeat yourself”?

This principle (DRY) is self-explanatory: you should avoid code repetition as much as possible. Based on this principle, exist many ways to reuse what we have already programmed. Think about it: functions, modules, libraries, classes, prototypes, inheritance, composition, macros, jumps (goto). It is a pretty useful software design principle.

Duplicate code is error-prone and difficult to maintain. If you are repeating code, extract that code into a function to encapsulate it. If we have to make a change, we will focus it on a single point, and not scattered throughout the source code. And it is also a very simple principle to understand. You do not have to write duplicate codes.

It makes the code more maintainable. Avoiding code repetition allows that if you ever change the functionality you are repeating. You do not have to do it everywhere you repeated it. Save time. By having chunks of code available for reuse, in the future, you get better prepared to accomplish the same thing in less time.

It reduces the size of the code. This makes it more readable and understandable because there is less code to comprehend. These are just a few ways to avoid repetition. Each of the strategies achieves in its own way and adds other advantages and disadvantages. When the DRY principle applies effectively, changes in any part of the process require changes in only one place.

2. How can we use the “KIS” principle?

This principle states that the code, the design, the documentation, everything related to the software, should be as simple as possible. The design of a program should be simple. The simpler the better. Complexity should be avoided as a general rule, but especially unnecessary complexity.

Our software in general should have as few components (and therefore lines) as possible. Programmers tend to complicate things. They ask for a simple form and usually want to make a form generator that will support this and all forms in the future. We must avoid these unnecessary things.

We should not have functionalities that are not currently occupied “in case they are occupied in the future”. Documentation should have only the information that is strictly necessary. The code should be as obvious and simple as possible. Lines that only serve to show off how smart you are should be avoided. The design should keep the structure simple, whenever possible.

This is one of the most difficult software design principles to apply, if not the most difficult. Doing something simple for others requires thinking things through long enough. Having the technical expertise to avoid trying to kill a fly with a cannon (or researching and having the ability to learn). In the end, simplicity is the most advanced sophistication.

3. What is the “YAGNI” principle?

YAGNI (You are not going to need it). This means that you only develop what you are going to use at the moment, that you think about whether you are going to use the functionality and whether you are going to need it in the immediate future. Do not develop something that you will not use soon, even if you know for sure that you will have to implement it in the future.

Implementing a feature that is similar to another one that has just been developed is easier than something completely different. If you develop two similar features one after the other you know better how to develop the second one. This is easier than developing the first one, then doing something different and finally developing the second one.

If the feature needs to work, but it is not exactly what you need, you have to change it to make it fit. This means that the time spent making it is not entirely wasted, but you have to spend more time modifying it. Time that would save if you had waited to make it at the right time, knowing the final behavior.

Even if a required functionality has been properly developed, if it does not provide any benefit, the costs associated with its premature development cannot take place. Since it has increased the complexity of testing and maintaining the code, and may have caused a delay in other previously needed functionality.

3.1 When do we use “YAGNI”?

The case in which this principle seems to apply most profitably occurs when one feature is developed that will need another, and it is needed but will be useless when the second is finished.

For example, you need a functionality (Functionality_1) and also have it without developing another functionality (Functionality_2). As Functionality_1 needs auxiliary code we create it, knowing that when (Functionality_2) finishes. This auxiliary functionality will be useless and will have to be discarded.

We may think that developing functionality to be “thrown away” is a bad software design principle. Then we decide that we need to modify the auxiliary functionality so that when Functionality_2 is finished it can be used in it as well.

Is not that what YAGNI wanted to avoid? No, it is not. YAGNI says not to implement functionality that is not necessary. Not to not implement functionality that is necessary at one time even if it is later discarded.

4.  SOLID Principles: What are they?

SOLID consists of a set of software design principles and best practices that should serve as a basis before proposing a software architecture for the development of applications.

This principles allow us to manage most software design problems, and if we follow them, we will be able to develop cleaner, more maintainable, more scalable code in the future and less prone to errors.

These principles are the basis of much of the literature you will find around software development. Many architectures rely on them to provide flexibility, testing needs to rely on them to be able to validate parts of code independently, and refactoring processes will be much easier if these rules are followed.

4.1 Which are the SOLID principles?

In software design principles, SOLID is an acronym that encompasses the name of 5 principles, aimed at object-oriented programming. The 5 principles consist of:

  • “Single Responsibility”. A software entity should have a single responsibility.
  • “Open/Closed”. A software entity, should be open to extension but closed to modification.
  • “Liskov Substitution”. The Liskov substitution principle speaks of interfaces: if a software entity uses a class, it must be able to use classes derived from it. This is very similar to contract programming, where interfaces get established prior to implementation.
  • “Interface Segregation”. Clients (software entities) that use a software entity (a class, originally), should not be forced to rely on methods that they do not use. To solve this, large interfaces must be segregated, i.e. broken, into smaller ones.
  • “Dependency Inversion”. The principle of Dependency Inversion states that high-level modules, i.e., those closest to human ideas of what the software should do, should not depend on low-level ones (those closest to implementing the details for the computer). Both should depend on the abstractions of the problem (interfaces).

4.2 What are the benefits of using SOLID Principles?

The advantages of using the SOLID Principles are innumerable since they provide us with all those characteristics that we always want to see in quality software. They provide more flexible software and improve cohesion by reducing coupling.

Broadly speaking, what we are looking for in a good code is that its classes can work independently and that the change of one affects the rest as little as possible. They will make you understand the architectures much better, besides simplifying the creation of tests. If you have your code decoupled and good architecture, the tests will be much easier.

If you apply the principles well, you organize your code better. This allows you to define an architecture that will make testing easier. You could say that the SOLID Principles are part of the foundation of quality code.

4.3 What do we mean by coupling and cohesion?

These are two very relevant concepts when designing and developing software. On the one hand, Coupling is the way in which various components relate to each other. If there are many relationships between components, with many dependencies between them, we will have a high degree of coupling.

If the components are independent of each other, the coupling will be low. As with cohesion, we can see coupling at different levels and there is coupling between methods of the same class, between different classes or between different packages. In addition, there are several types of coupling, ranging from coupling through common data and temporal coupling.

And on the other hand, we could define software cohesion as the tightness of the relationship between the components of something. If we talk about classes, a class will have a high cohesion if its methods are related to each other, they have a common “theme”.

If we move on to larger components, such as packages or libraries, we would have high cohesion when the classes that form it are closely related to each other, with a clear and focused objective.

5. How does the “Boy Scout” rule work?

This is a very simple rule, it simply consists of doing the same thing that the Boy Scouts do every time they go out into the field, and that is to leave the area a little better than they found it when they arrived.

According to this rule, we should act in the same way, and every time we touch a method, a class, or in general any module we should leave it a little better than we found it so that it does not rust.

Of course, we will achieve this by following the principles we have seen in the code we wrote, but what makes the Boy Scout rule interesting is that it involves more than just cleaning up our area, we should pick up and clean up some of the garbage we find wherever we go. This will not only prevent our software from rusting but will also make our software look much better.

6. What can we say about these software design principles at Connect Tech?

There exist more software design principles that we do not talk about at the moment, but these are the basics that every programmer should know because they make life easier. For this reason, we at Connect Tech decided to recommend these to you.

By following these principles, we can make software that is maintainable, easy to update, understand, share, explain and prove in the future. At Connect Tech, we take software design seriously. That said, we recommend that you take into account the principles outlined in this article.

Want to know more about software design and development? At Connect Tech, we are your best choice when it comes to software-related and security solutions. You can write us an email at CONTACT@CONNECTECH.DEV.

Remember also, if you want to send your resume you can do it at thetalentpoint.com. No resume sent to contact@thetalentpoint.com will be stored.

Related Posts

Leave a comment

You must be logged in to post a comment.