Understanding the SOLID Principles

Solid is an acronym that stands for five principles of object-oriented programming and design.

S-Single Responsibility Principle

O-Open/Closed Principle

L-Liskov Substitution Principle

I- Interface Segregation Principle

D-Dependency Inversion Principle

These principles help to avoid dependencies between the classes.

Now talking a little bit more of these principles we understand the following:

Single Responsibility Principle- This principle states that one class should only have one responsibility so the changes in that class do not end up affecting unrelated critical features on the system. This happens from a single action to a set of processes. You can take a view that a single responsibility refers to a group of related business processes. The stamina and tolerance determine how far you go

Open/closed Principle- This principle talks about that classes should be open for extension but closed for modification, this means that adding new behavior instead of changing the base of a class you should create new classes that inherit from this class and add the behavior there. This helps to avoid errors in child classes

Liskov Substitution Principle- You can pass a new class to an existing function that has been written to work with the base class, and the function will perform its work just as if you had passed an instance of the base class. This principle intended to keep alive and well the working relationship between classes and functions. You should forbid modification of a behavior through the mechanism of inherence.

Interface Segregation Principle- This principle tell us to divide and conquer. Instead of writing a big interface, divide the interface members and put them together so the class would not be loaded with responsibilities we won´t use.

Dependency Inversion- This principle basically tell us to write code that refers to abstract classes and interfaces instead to actual classes

War Games

This is a Movie directed by John Badham, where the main character is a teenager, called David Lightman and starring by Matthew Broaderick. David loves computers a lot, he likes to discover new functionalities with his computer, he takes it as a challenge. He heard that a new game is being released, so he took his technical abilities to be the first one to play that game. He entered to a rare interface where he found some names that sounds like funny videogames, but to play them he discovered that he had to introduce a password. He passed many hours trying to discover the password, until he found it.

David selected a game where he had to launch a massive attack to other nation. He was playing as Russia, but he did not realize that this was actually a simulation of an actual war and the machine also thought that this was a real simulation. David passed many difficulties to discovered that this was just a simulation and the USA was not being attacked by Russia. But there was a problem, the machine was taking actions to prevent the “attack” so this intelligence wanted to attack Russia. David discovered that the only way to stop the machine was teaching it to don´t play the game because nobody would win. David learned this algorithm by making the machine play tic-tac-toe against itself.

This movie was interesting because it shows us that at that time computers and technology was marvelous, people could contact another computer via phone and everyone can access by this way to another system. So, for me it was so fascinated that a teenager knew all this kind of trick and have all the knowledge to take advantage to this technology. This movie learned us that technology knowledge is reachable for anyone.

“Software Craftsmanship with Bob Martin”

I have listened to the podcast that is actually an interview to Robert C. Martin, which is a software engineer and author of a lot of books; you can also know him as the uncle Bob. We can hear some subjects like software architecture, software craftmanship and agile software development approach during this interview.

The first thing we hear is Uncle Bob talking about his experience of being a software architect. We also hear him saying that the worst part is the people that tends to separate architects from software developers. He believes is weird because architects make decisions about the code and have no familiarity with it.

Robert Martin, talks in this interview about software craftsmanship (I have never heard about this concept in my life) , and he tell us that is a concept that says that every young coder or developer  needs to have a master because we can not learn coding just with theory, you must help another person to learn, in a project or whatever you want but help someone. This is similar to attending to college, here you have classmates that maybe have some issues with a subject and as a good classmate you can help someone and with that receive more knowledge and feedback. 

Software craftsmanship has also a manifesto with four points, which are:

• Not only working software, but also well-crafted software

• Not only responding to change, but also steadily adding value

• Not only individuals and interactions, but also a community of professionals

• Not only customer collaboration, but also productive partnerships

We hear uncle Bob explaining each point. The first two main points consist on code related to issues, is to have good practices to code and do well-crafted software, not just do what you need to do, but also know how to do it, this applies also when you make changes to the code. You must add value not just to accomplish the requirements.  

Uncle Bob also mentioned some tools and abilities that a good developments craftsman should have:

• Understanding the IDE you are working with

• Version control

• Bug tracking

• Unit testing

• Acceptance testing tool

• Lisp

• Knowing a programming language of each type

Is Design Dead?

I believe that it is important to design first and then code, this will avoid the code and fix. Also, I think that “if you listen to your code a good design will appear” is one of the worst quotes. It is very interesting to know that there are two styles of design. The first one is the evolutionary design, which is a disaster, it makes the code harder to alter. Now, the counter part is the planned design, which contain a notion born from other branches of engineering. Building codes into this design is to follow the rules about how you design structures based on experience of what works.

This las one design is not the perfect one, it has some faults. The first fault is that it is impossible for a person to think in all the issues that are going to be present when they are programming. There is a cultural problem with this type of design, the designers are designers because their skills and experience, but they are too busy with this job, so they do not have enough time to code any more.

A feasible way to deal with changing requirements is to build flexibility into the design so it would be easier to change it as the requirement need it.

In extreme programming the continuous integration is necessary to keep the teamwork in sync, it will be easier to make changes and do not need to integrate other people.  Refactoring is also important because people who do it, find a difference between their effectiveness compared to doing looser, more ad-hoc restructuring.

I agree with the quotes “Do the simplest thing that could possibly work” and “You aren´t going to need it” because we have to think in present requirements and try to make them as easy as we can so that we can change them when the requirement needs it.

Who needs an architecture?

I believe that the meaning that is given to the architecture word is so accurate, I also believe that this word should be used to describe something when we want to talk about the design of something. But also, I think that the IEEE definition is correct, because architecture should also consider the structure and components of something, in this case the software.

An architect should be defined as someone that worries for the important stuff, someone who takes important decisions, must be aware of what is going on in the project. He looks for the important issues for the projects.

In the software development, the architect works in intense collaboration, he should be working with developers, participates in requirements sessions, and mentors’ developers. One of the most important tasks of an architect is to find different ways to eliminate irreversibility and duplication in software design. The difference between this architecture and physic architecture, is that this is limited by imagination, by design, by organization. It is limited not by physics but is limited by properties of people.

The only one that makes it harder is us. In software design, the components are significant because the expert developers say so.

Talking abut code, if we do not have a design we will have a lot of mistakes that will cost more money and time, something that could be critical for a project. These mistakes could involve a lot of people working in the same project. The projects need to be planned previously to know the functions of everyone and determine the functionality of the software. We must consider that the architecture should be balanced. Architecture is useful, and it can be developed in many ways, it does not have to be in one and only way.