Understanding the SOLID Principles

First of all, SOLID is an acronym for the it's five principles hidden in each letter of object-oriented programming (Java, C#, PHP, Python, Ruby, etc.) and design. It's objective is to avoid dependencies, because it may cause problems on the code if there are, so the principles are:

• Single Responsibility Principle (SRP). Basically as the name said the method should have only one responsibility, because the consequences would be at the moment of maintenance, when other programmer change the code and if the class do two things, but the programmer did not check out, the functionality would be compromised.

• Open / Closed Principle (OCP). It states that a class or function should be open for extension and closed for modification. Meaning that the base classes (functions) should be leave alone, when adding a new behavior and create new inheriting classes. It's about inheritance.

• Liskov Substitution Principle (LSP). This principle is like OCP and has the intention to keep happy relationships between classes and functions to work well. Meaning that as the previous principle said, avoid modifying the base class with the difference that LSP do not use the inheritance mechanism (because it would be a violation to the principle), instead of that, create an instance of that class. In other words, avoid inheritance by using keywords according the language, for example in Java you can use final keyword an in C# sealed keyword.

• Interface Segregation Principle (ISP). This principle is about interfaces and avoiding creating too many responsibilities in one interface, making the code less understandable, it's kind of SRP but with interfaces and with the main difference that you should partition interfaces according it's concerns, making the code more readable for other programmers.

• Dependency Inversion Principle (DIP). "Depend upon abstractions, not upon concretions" Meaning that you shouldn't depend of another class, instead it's better depend from an interface, becoming easier to substitute any class you want.

From my point of view , already having understood the principles gave me a new way of code, because sometime we do not follow a standard when coding, but we may ask Why this is important? Dependencies are always there, but the less we avoid the easier it's maintenance will be.

Vatican City, Rome

For more information visit Understanding the SOLID Principles

Software Craftsmanship with Bob Martin

Bob Martin is an software architect, also known as "Uncle Bob", but before that he said he was a little bit of everything, because people need to grow. He thinks architecture is really worth doing, but he thinks architects should be also coders because otherwise they don't connect with the code decisions, "they don't connect with the keyboard", they just forget the code, and doing it that way the architect just forgets about the keyboard and it's really hard to manage a team like that.

The Software Craftsmanship is a good example of how very important advices can be written in a few lines of text where the important ideas are summarized in four principal advices that tell us like programmers that if we want to be better professionals following the software craftsmanship we have to be aware of helping others to do quality software, response to the change and add value to the product with it, strengthen the community of professionals with my contribution and search a good productive partnerships in the projects.

 It is important to mention that there is too much importance in the developers teams related to collaboration and having good practice in a way to  be sure that all members of the team  are informed with the all related to the project and we have to keep in mind coding considering that in the future we want to change something, so the code must be able to change without breaking something else. In conclusion, Bob Martin have a lot of knowledge of how to this Software Craftsmanship Manifesto works, and is important knowing the point of this, to future generations. 'cause at it says, knowledge is everywhere and we need to use that, to get this new industries that want the best of the best, specially with software architects.

Piazza San Marco, Venice

For more information visit Episode 150: Software Craftsmanship with Bob Martin

Is Design Dead?

As we know Extreme Programming (XP), created by Kent Beck is a methodology of software development that according to the author Martin Fowler it is calling the death of software design, so our main concern Is Design Dead? to give a better understanding and answer to this question he gives us step for step many arguments to be or not in accordance with the author.

In software development there are many styles of design, but the author described us two; one of those are evolutionary design, that means the design of the system grows as the system is implemented, but at the end it's a bad idea because makes the code harder to modify going against the practices of XP. On the other hand we have Planned Design that works the same with the disadvantage that entropy sets in, because it's maintenance gets difficult for other programmers.

So I see it's about software entropy, that is a measure of how complex the maintenance gets when we add more code to a program, based on the methodology of Extreme Programming that have the characteristics of refactor code, simplicity in code, keeping design clean among others.

The author said design is not dead, but it had changed looking for: communication of the design through diagrams, keeping clear and simple code, refactoring and keeping an eye to the future to have in mind future problems.
So, from my point of view I agree with the author the design in NOT dead, but it is in constant grow, to get a better standard of design that helps when we code. As my experience with some other courses , design seems to be not useful, but at the moment of implementing, sometimes helped for reducing time and bugs, always if the style of design was good.

Madrid, Spain

For more information visit Is Design Dead?