The SOLID Principles

This one is a hard one for the blog. At the moment I can't begin to produce an opinion about the material that can remotely be 300 words long. I think this was the shortest reading material I've had to blog about ever. Especially in class. Not only that but it was uncomfortably informative. Blogging about it is like being asked to write a 300 word 'comment, opinion or critique' about a random set of five entries in a dictionary.

I guess that from this reading I'd say that I'm getting continually more and more impressed the complexities and details of software making beyond solving complicated abstract algorithm problems. It starts to make sense to me why there's so much worrying for the role of a 'software architect', following best practices, crafting and so on.

These principles (or best practices) particularly are very much focused on situations that arise in very object oriented progamming, which is why I am not ultra familiar to the situations. If looked at in greater detail, I believed that all of the 5 refer to a greater principle we hear a lot about when talking about OOP: the concepts of coupling and cohesion, and how we're supposed to have very little of the first one and a lot of the second one. Particularly coupling.

The SOLID principles addres inter-class dependency, which to me is a form of coupling, of having one class care a little too much about another. Perhaps they don't solve or address coupling directly.  I think it would be more accurate to say that, if followed, they prevent high-coupling situations from happening. Unlike refractorings, principle like this aim at preventing those situations.

At the moment I have a feeling that I have not worked in a project that was big enough for these better practices to be of use, so I am very curious to reach the time (if it ever comes) in which I go like 'Oh! this is it! here and now good software architecture practices are explicitly needed.'