This article from InfoWars main goal is to explain the Law of Demeter, which is something that I have never heard about before this class. The basic premise of the Law Of Demeter is to ensure that classes and objects should never know the internal design and content of other classes. This promotes loose coupling and allowing code to be easily modified and changed in the future. First discussed in 1987 at Northeastern University, the law was developed to help software designers create code that can be understood and modified easily. This seems to be the main goal for most design laws. With more coupling, there is more confusion. The Law of Demeter will ensure that there is minimal complexity within code from restricting classes to have excess knowledge of the inner workings of other classes.
The main reason I selected this article for this weeks blog post was because it again showed some visual examples of code being used in the Law of Demeter, instead of just plain text. As I stated in another blog post, I enjoy seeing pieces of code that show the principle being used, and showing its violations. This article was also another free resource for many beginner coders to utilize to enhance and optimize their code. This is a concept I did not know about before taking this class. Reading the article, I connected the main points of the Law of Demeter to concepts we have learned in class, such as loose coupling. I’ve never realized that those small concepts we learned in class had much bigger implications in the world of software design, such as having a whole law dedicated to it.
In the future, knowing the Law of Demeter exists will help me make sure my code utilizes loose coupling, so that my code can be easily understood and ready by my co-workers on the project. Having code that is easy to read and understand is important when working in a team environment, as you can write something that you personally understand easily, but if a co-workers takes over your work, they are left in the dark as to what they are reading. This also promotes communication in the work environment, such as having standards for writing code so that everyone is on the same page when it comes to creating code, and allows for a more fluid and effective work environment.
From the blog CS@Worcester – Noelan Chabot's Blog by nchabot1 and used with permission of the author. All other rights reserved by the author.