There are lots of “rules” we must follow in object-oriented software development and the article The Genius of the Law of Demeter by Javadevguy summarizes how they are useful. From what I put together, it seems like the Law of Demeter took abstract concepts and basically put them into a universal set of rules for Object-Oriented code.
I thought that the law of demeter must be a big deal if someone decided to sit down and write a lengthy blog post about it. This content ended up being interesting as it tried to convince readers why they should obey this “law.” The Law of Demeter basically paves the way for what users can do to a given method. It is kind of like considering the restrictions or possibilities based on the method. One of the takeaways I got from this is how there is a lot of focus on communication between two objects.
The rules listed in the article are as follows–noting that it says “For all classes C, and for all methods M attached to C, all objects to which M sends a message must be”:
self(thisin Java)- M’s argument objects
- Instance variable objects of C
- Objects created by M, or by functions or methods which M calls
- Objects in global variables (
staticfields in Java)
Another useful takeaway I got from this article came from observing the code examples Javadevguy included; how Rule #1 covers that any method can be called on the current object. I also noted when there would be an instance where the law would prohibit something is not “sending a message” to any already existing object that is held in instance variables of other classes.
This will affect the way I continue to do work as an Object-Oriented developer. I mean, in life when you learn there is a more useful or structured way to help you achieve more effective results, you would want to try or follow it, right? For my future use, I will acknowledge (like other blogs and articles) that the Law of Demeter is less of a law and only a suggestion or a guideline.
Overall, I would say that the content has helped further solidified my understanding of some Object-Oriented coding concepts. I agree with the content as it is trying to help people become better developers or better understand the Law of Demeter in general.
Article: https://javadevguy.wordpress.com/2017/05/14/the-genius-of-the-law-of-demeter/
From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.
When coding, users always have to be conscious about the way their code may be implemented or used in the future by different services leading to potential misuse. After reading Code Health: Make Interfaces Hard to Misuse by Marek Kiszkis, it made me think about how important communication between testing code is.
It is also good to remember that at the end of the day, code should be defensive but not too defensive to the point that complexity is increased and performance overall is reduced. Kiszkis says “it is not always practical to have a foolproof interface” because there will be situations where some requirements are things that cannot be expressed in an interface.
If you happen to be reading this page translated from English to another language, hello there, you are one of the main characters of this blog post. Without linguistics, the study of language and its structure, we probably would not be able to figure out how to communicate everything we need to globally while being able to understand it at the same time while testing. There are so many online resources that cover what a specific country or region in a country uses in terms of data formats for their computer systems.
Over the weekend, I had the chance to sit down and listen to another podcast episode by Developer Things. The title, Women in Technology (with Megan Horton), caught my eye as I am always on the lookout to learn about other women’s experiences in technology.
Imagine being several years into your role as a developer; you’ve had a long week, a big project to push tomorrow and suddenly… you’re stuck on something. And you’ve double-triple-quadruple checked to make sure everything is working by code review but you cannot put your finger on how it is not quite perfect. What’s wrong? Let’s find out.
A few weeks ago, I was introduced to JUnit testing in my Software Quality Assurance & Testing course. The blog post tutorial linked below is one I would recommend to those interested in learning about assertion. Reading this post has helped me review the concepts I have learned and I will share what helped me better understand the topic of writing basic assertions with AssertJ.
“Forget about automating your regression tests” is some bold advice from Bas Dijkstra, who has experience as a test automation consultant. It made me wonder what exactly led him to making this kind of statement on regression test scripts and his article, On Ending the Regression Automation Fixation, covered various reasons why.
As someone who will be graduating within the next year, I’m always interested in what software development is currently like. Ekaterina Novoseltseva uses some 2018 statistics and presents interesting facts about software development through Apiumhub—which is a software development company based in Barcelona. The data in this article comes from a collection of over 300 answers from different countries around the world; starting with the challenges in software development.
After learning some life lessons through the pages I’ve skimmed from my copy of The 7 Habits of Highly Effective People by Stephen Covey; this article’s version for software developers in test caught my eye. What exactly are the seven highly effective habits of SDETs? Here are the seven habits that Angie Jones, a senior developer advocate at Applitools, wrote about: being intentional, enhancing development skills, enhancing testing skills, exploring new tools, automating throughout the product’s tech stack, collaborating, and automating beyond the tests.
According to music artists, two is better than one. When it comes to designing code that has two parts, this may not be the case. In Max Kanat-Alexander’s article, he explains how he has a personal rule of needing to know how generic his code needs to be. He describes it as if he were designing an audio decoder and started out with supporting WAV files and then later needed to add support for MP3 files. His solution was for what he only needed on its own instead of having to copy and paste the common parts for the format; he emphasizes that “it’s not just two implementations that are bad, but also two locations.” Another rule Kanat-Alexander has for helping this stay consistent is to create code well enough to ensure you would ideally never have to go back and change it if another part of the code has to be modified.