Understanding the SOLID Principles

The article of this week emphasizes again how to improve our code, to make it more efficient, ease maintenance and reuse it. Five principles are mentioned, which we should follow to improve our practices when developing code. These five principles were first identified by Robert "Uncle Bob" Martin, but the acronym SOLID (by the initials of each principle) was introduced later by Michael Feathers.

Each of these principles establish certain rules to follow, below they mention each of them with its brief explanation.

1. Single Responsability Principle

It states that you must give only simple responsibilities to the classes, thus avoiding dependence between them. It also specifies that can be assigned to a class the responsibility of a group of classes, all to facilitate future modification of code without affecting the other classes.

2. Open/Closed Principle

It states that classes should be open for extension, but closed for modification. It is recommended to control the behavior of each of the classes through inheritance. The main objective is to avoid making modifications to classes, it is better to have an extension that controls everything and make the change directly on it.

3. Liskov Substituiton Principle

This principle is similar to the previous, except that it focuses on maintaining a good relationship between classes and functions. Also recommended not to make changes in base classes.

4. Interface Segregation Principle

It states that we should avoid writing large interfaces. To improve recommends creating collections that contain these interfaces discreetly and smaller, through dividing into groups depending on what interfaces do.

5. Dependency Inversion Principle

The last principle states specifically, avoid dependence. It recommended interfaces to carry out the relationship between the classes that we want to have relationship.

Each of these principles are aimed at improving practices writing code and ease of maintenance, modification and reuse it.

Software Craftsmanship with Bob Martin

The metaphor used by Bob Martin saying that software development should be craftsmanship, I seem very accurate because, craftsmanship is any product that is made with art and technique usually performed with hands and with good quality. This is exactly what Bob tries to explain, how we can create a better quality software and do not  make programs only for do, without any sense,  and without paying attention to the quality of the final work.

Bob's idea to create a change in people is good, but complicated. Usually, as programmers, we are used (not all, I'm not generalizing) deliver programs for the sake of fulfilling a contract and  only by that reason. We do not consider the quality of the code, most of the time we do not even take into account if we solve the problem in the most efficient way,  just care about giving the solution.

I consider that every work we do speak a little of ourselves, therefore we should pay a little more interest to do so. If we really love what we do, we must try to do our best effort. Perhaps the same IT industry lead us astray, to make us believe that a quickly software outsells than a good software, but I think we need to change this belief. I do not believe some company prefer something quick but that in the future will give them problems that could represent extra expenses for them.

We can try to change our mentality, not only to develop programs but also in other things. We must see the software as a craftsmanship that we create, and the documentation like your support. Sometimes the program may be clear to us but not to others, and therefore the explanation never hurts to. Besides this good practice can occasionally save our life in an emergency code.

Is Design Dead?

This article stands out again the importance of design in programming. I found it very accurate the part where mentioned that people focused on programming underestimate the work of the dedicated to the design, without considering that both techniques are combined to achieve the best of a program.

An important concept is refactoring as it can sometimes be useful, depending on how it is used. For example, we must not believe that refactoring corrects errors that were committed in the past because it is not. In addition, you should keep in mind that this technique will only work in a proper way if you have a good design. People are inclined to use UML diagrams for design, others simply do not, the only important thing here is that the design should be as simple as possible.

Again the software architecture and the importance of knowing different design patterns to improve the programs is mentioned in a matter of simplicity. It is mentioned that the programs should be simple and able to be understood by people who maybe not engaged in coding.

A point to be considered is that the design is an aid to deployment part, and with aid I want to say that could prevent errors. It is recommended that if you are in that part of encoding and errors that could belong to the design are found, they must be corrected and documented in the design, which does not always take place.

As programmers, and so that our programs have a longer duration, we should not leave aside the design, since as we have been learning in other articles, is an essential part of a program that not only improves the quality, also help saving time and money in a big project, and a good design can get us out of many future problems.

Who Needs an Architect?

The importance of architecture in programming, is again based on how to improve the way in which a system is developed. Comparing the theme of architecture related to the construction and in our case, the related software development is, as mentioned in the end, the foundations of our program. The difference between the two is that in a construction is not possible to make changes once the stage was completed, unlike software development where you can be performed changes, even if they have a cost in time.

The part where are mentioned that the programs unlike to building constructions, should be able to change. I do not know how well is that a program is so flexible, from my point of view I think it depends on the use to which it will give to the program and also an important aspect is the documentation, because we can have a very flexible program but without the necessary documentation, making changes can be a very complicated task, and sometimes choose to start a program from the beginning is the best option.

This article mentioned again the importance of good design during the performance of a system. Among the various definitions of the word architecture I understand in a better way that mentions the architecture is like art, where the limits are imagination, design and organization. The benefits of good architecture are many compared to the problems that could result in the future. For obvious reasons, to make designs we are not facing problems related to physical as in the case of building designs, all that should concern us is a design that includes all the features, and we have to remember that a good design will guide during the development of our program.  We have to do of the design a good practice in every program that we perform.