I recently delved into the fascinating world of software design principles. Among these, the Principle of Least Knowledge, also known as the Law of Demeter, caught my attention and proved to be a valuable guide in crafting efficient and maintainable code. In this blog post, I’ll share my insights into this principle, drawing from various resources to shed light on its significance.

The Principle of Least Knowledge

The Principle of Least Knowledge advocates for limiting the interactions between classes or components in a system, promoting a low coupling and high cohesion design. In simpler terms, it encourages a module to only communicate with its immediate neighbors, reducing dependencies and enhancing the system’s flexibility.

Selected Resource

I stumbled upon an insightful article titled “Law of Demeter in Java”, which provided a comprehensive exploration of the Law of Demeter and its practical applications in Java programming. This resource not only clarified the concept but also demonstrated real-world scenarios where adhering to the principle can significantly improve code quality.

Why This Resource?

Choosing this resource was a no-brainer for me. The Law of Demeter seemed like an abstract concept at first, and I needed a practical guide to bridge the gap between theory and implementation. The Baeldung article not only provided a clear explanation but also offered concrete examples, making it an invaluable tool for someone eager to enhance their coding practices.

Insights and Reflections

After absorbing the content, I realized that applying the Principle of Least Knowledge fosters modular and maintainable code. By minimizing direct dependencies between classes, code becomes more resilient to changes and easier to comprehend. This is especially crucial in larger projects where codebases can quickly become unwieldy.

The real strength of the Law of Demeter lies in its ability to enhance collaboration within a development team. When each module interacts only with its immediate neighbors, team members can work on different parts of the system without constantly interfering with each other’s code. This not only boosts productivity but also minimizes the chances of unintended side effects during the development process.

Future Application

As I move forward in my studies and eventually into the professional realm, I anticipate applying the Law of Demeter as a guiding principle in my coding practices. I foresee it becoming a cornerstone in my approach to software design, ensuring that the systems I contribute to are not only functional but also maintainable in the long run.

In conclusion, my exploration of the Principle of Least Knowledge has been enlightening, thanks to the practical insights provided by the Baeldung article. Understanding and implementing this principle is undoubtedly a step towards becoming a more proficient and conscientious developer.

Reference:

1. Law of Demeter in Java – Baeldung

From the blog CS-343 – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

Overview

This week in class, my group and I installed Java in VSCode and created a unique file to write code in. It was the first time that I created a file that wasn’t in BlueJ or ZyBooks in order to write runnable code inside of. Being it was my first time experimenting with it, it took a while for me to understand. But once it became clear to me I found it very interesting. A tutorial on getting started with Java in VSCode I read went further into detail on how to use Java in it, covering tools, testing, project management, what needs to be installed and many other helpful things.

Installing Java

To first get started a coding pack needs to be installed. There’s a link leading to the files that need to be downloaded. However, the Development Environment activity we did in class only required that the Java devcontainer extension packs in VSCode were installed. Installing that same extension pack is actually the second step for the article’s “Hello World” example. A JDK (Java Development Kit) is vital for running Java in VSCode. With the coding packs and the JDK, Java has been successfully installed onto VSCode.

Creating Source Code Files

The part that fascinated me was creating a source code file. Since the Java coding packs and development kits have now been installed, you can create a file specifically for Java code. This is achieved by choosing a name for your file and adding “.java” to the end of it. VSCode now knows that it is a java file and will recognize any terms and symbols specific to Java that it wouldn’t if it was just a regular text file. Write down code and it won’t take you long to notice that terms like “int”, “for”, “public”, “class”, etc. are colored differently. When you are done writing your code, there should be either a play symbol or a link that says “Run|Debug”. If your code is compilable, the output of your code will be returned in the terminal. 

Interesting Features

VSCode offers many interesting tools that make it easy to search for, test, and edit code among other things. If you have a project in Java or any programming language, it is easy to sort through. On top of that, there are so many extensions such as code spell checkers, debuggers, test runners, and many other tools that make creating code that much easier. Compared to BlueJ and other IDEs I’ve used, this has been the most useful. It took a while to get the hang of, but once I did, I realized how good of a tool VSCode is and can potentially be.

From the blog CS@Worcester – William's Blog by William Cordor and used with permission of the author. All other rights reserved by the author.

From the previous week’s we have been covering the different types of software copyright licenses and their differing purposes in the field. The blog post I chose to cover is “Understanding Software Licensing” by Fernando Galano. The goal of the blog post was to help simplify the legalities of differing software copyright licenses as well as expressing the importance of understanding copyright licenses and why you should know when to use the different kinds. From what we learned in class, from the videos as well as our in class activities, the blog post worked hand in hand in reinforcing the pros and cons of the different copyright licenses to give a better grasp on the topic.

The blog post started with what a software copyright license exactly is. Galano described the concept of a software license is the establishment of a contract between the creators of the software and the individuals who would be using it. The contract would lay out the terms and conditions that the user must follow when it comes to use of the code as well as the rights and liabilities of the user and creator. As explained in the post, the license will protect both parties and make sure that the use of the software is as intended from both the creator and user. After Galano described the preemptive information about what a license is he explained the different types and their pros and cons. He described Public Domain Licenses, Copyleft Licenses, Lesser General Public Licenses, Permissive Licenses and Proprietary Software Licenses. Each license had a almost like tldr description that allowed the reader to easily understand what each license is meant for. He ended the blog post stating that every license has a purpose and it is up to you as the creator to decide what your purpose is for the software and what you want it to be used for.

The reason I chose this blog post was due to the fact that while we have been covering copyright licenses I feel like I still didn’t fully grasp the differences and when you should use each kind of license. This blog post was perfect in using simple terms to allow me to easily understand the different kinds of software licenses and their differing uses. From this I will now be able to one hundred percent understand why I am choosing a certain license when it comes to protecting my work. I feel like reinforcing my knowledge on items like this is very important as copyright licenses are a huge part of developing software.

https://www.bairesdev.com/blog/understanding-software-licensing/

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

When it comes to software, and working on it as a team, or sharing it with others, Git appears to be the bread and butter of it. That is what class is kind of centralized around, learning how to use Git, and how it benefits you and others. At first glance, it appears very hard. However, after understanding its role in the greater scheme of things and putting it into practice, it’s not all that hard. Originally, I thought Git was another coding language, like Java or C++. I was severely wrong, as it is more similarly to Bash in a way, but unique in its own way. It allows for people to create code, share it with others online, where it can be used, changed, and reshared with the original creator or other people, where the same thing can happen, making branches of versions of code different from the last.

To use Git, you need a code hosting platform, like GitHub or GitLab, and a code editor, like VS Code. You don’t need to use these specific sites or editors, as each is similar and unique in their own way. Once you have these, you can start writing your code, stage it, commit it and push it into your code hosting platform on the internet for others to see, use and change. Or you could fork some code you see and change it up however you want, stage, commit and push it back and see what others think. Git allows not only teams to work on code together, but strangers to work on it, from all over the world. 

But who says Git can only be used for coding purposes? In this blog post, by Bruno Brito, they describe how Git can be used for designers, as in those creating graphic design and photo editing. In the post, they describe what Git is, how it is used, how to use it, and other things needed to know as a beginner to Git. However, instead of editing code, they use photo editing software. In the specific post, they are using Tower, which is similar to our VS Code. They describe how to create repos, how to stage and commit, and then how to use code hosting platforms, or for designers, cloud-based hosting platforms, to maintain synchronization. Then they go on to describe forking, cloning, pushing, pulling and branches. 

At quick glance, this could be interpreted as a tutorial for Git, which it is. But it is in a setting different from coding, specifically for design. I like this post because it shows that Git can be used for other fields, similar to my last post. I find that these ways of organizing code, among teams and many people, efficiently, and it allows many people to chip in, and upload their work. Although the post to me is essentially useless, as I have already learned how to do Git, it can be helpful to others who are looking for ways to create an efficient work environment. I can relate to this in a way, as a communications student as well, I am somewhat fond of art, and graphic design. I may not use Git if I am creating work on my own. But in a team, keeping track of who is doing what, and what changes have been made to this piece and what not, it can be helpful.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Software Testing

Software testing is an important process that evaluates and verifies a software application works as intended.

Types of Software Testing

There are many different types of software testing, some are:

• Acceptance – The entire system as a whole is tested and verified
• Integration – Ensuring that individual parts of a software system properly work together
• Unit – A unit is the smallest testable component of a software system. This type tests each unit and verifies correctness.
• Functional – Tests functions by emulating business scenarios
• Performance – Tests the performance of the software under different system workloads
• Regression – Tests rigidity of the software by adding new features and seeing if those new features break or impede on fucntionality
• Stress – Testing the software under maximum workload to see how much the system can handle until it fails
• Usability – Testing how well a customer can complete tasks using the system

Software Testing Best Practices

The software testing process is typically done with a common methodology. Steps to this methodology can include configuring test environments, writing test cases, analyzing test results, and submitting bug reports. Testing tasks are typically automated using tools. Automating tests is beneficial because it allows teams to quickly implement different test cases, test frequently, and get feedback on what did/didn’t work.

Some best practices include:

• Continuous testing – Testing builds as soon as they are ready. This relies heavily on automated testing, allowing software to be validated earlier in the development process. Testing often allows for bugs and errors to be found earlier; therefore, reducing the amount of time spent having to go back and redesigning.
• Configuration Management – Organizations keep test assets (code, test scripts, requirements, etc) in a central location and track what builds need to be tested. These assets allows teams to follow the organization’s testing requirements.
• Bug Tracking – Keeping track of defects is important

Why Test Software?

Testing software regularly can help teams reduce costs and time spent on developing the software. Before releasing a project, testing the software for any errors or bugs is important to give users the best possible experience. If users find that the software does not work as intended, they may stop using it and find an alternative that does work. Although testing has a cost, the cost of releasing defective software outweighs that of continuous testing.

Reflection

The resource used was chosen because it clearly breaks down the different parts to software testing such as the different types of testing, best practices, and why testing is important. Prior to reading this article, I had heard of a few types of testing like Unit Testing, but only became aware of the other types of testing such as Regression Testing. I now understand when designing software, code should be tested regularly and often as overall it will save time and headache.

Resources:

https://www.ibm.com/topics/software-testing#:~:text=Software%20testing%20is%20the%20process,Test%20management%20plan

From the blog CS@Worcester – Zack's CS Blog by ztram1 and used with permission of the author. All other rights reserved by the author.

This week I wanted to write a post about the last SOLID design principle, Dependency Inversion. This principle deals with the relationship between interfaces that operate at a high system level and low system level interfaces.

Composed of two parts, the Dependency Inversion Principle as stated by Robert C. Martin is:

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
2. Abstractions should not depend on details. Details should depend on abstractions.

While the name “Dependency Inversion” might imply inverting the dependency relationship between modules, applying this principle actually involves building both high-level and low-level modules from the same abstraction. Constructing your code to abide by the previous SOLID principles, particularly the Open/Closed Principle and the Liskov Substitution Principle, should implicitly also result in code that abides by the Dependency Inversion Principle. The Open/Closed Principle states that a software module should be open for extension, but closed for modification, and the Liskov Substitution Principle states that an interface should be able to be replaced by a separate implementation of the same parent interface without compromising the functioning of the software.

The author includes another coffee machine themed example, detailing how to apply the SOLID design principles to two separate classes of coffee machine. Starting with two classes, BasicCoffeeMachine and PremiumCoffeeMachine. The classes are very similar, with the only differences being an extra class variable representing a coffee bean grinder and a method to brew espresso for the PremiumCoffeeMachine class. The author describes their process for defining suitable abstractions for a piece of software representing coffee machines, including their decision to have the methods for brewing filter coffee and espresso split into two interfaces. A potential coffee machine class representing a machine with the capability to brew either filter or ground coffee can easily be built by implementing both of these interfaces and overriding the methods within the concrete classes.

Refactoring the code this way enables independence between interfaces and implementations and makes expanding on the code base easier and safer. With fewer dependencies between modules, the effects of any changes to existing code won’t ripple out to other parts of your software.

I wanted to review this principle specifically because I wanted to refactor the interfaces from some old projects of mine. I wrote some Java classes meant to represent characters in a fantasy role-playing game, complete with character levels and statistics. As I left it though, the code is only capable of creating characters meant for the user, and not any non-playable characters or any other sort of entities. I want to go back and redesign my code so that I have fewer methods that only function with specific classes, and more functionality to create and edit characters. I remember I had a lot of trouble trying to increment a character’s level by 1 and increasing their stats accordingly, and I get the feeling that refactoring my code with the SOLID principles in mind will help me get it to a place I am happier with.

From the blog CS@Worcester – Michael's Programming Blog by mikesprogrammingblog and used with permission of the author. All other rights reserved by the author.

Hello everyone, my name is Abdullah Farouk, and this is my third blog so far this semester (hoping I can get to 6 before the semester ends). I am going to be talking about comments in this blog because I saw this interesting article about it, and I just wanted to learn more and be better educated on the topic. When I started out with coding, I always ignored typing comments in my code because I didn’t really get the point of it other than wasting my time. But as things got more advanced, and I kept getting errors in my code and I knew what the error was, but I just didn’t know where the methods were in my code and what their function was. That’s when I started thinking about comments, I told myself comments would been helpful here instead of reading every line of the method to see what it does. In the article that I tagged down below, the author explains the importance of software technical documentation and how it should be used, with some examples to show you.

I have learned a lot about software technical documentation from this article including what are some examples of unnecessary comments. You don’t need to write an English translation of your software code; you just need a high-level overview of your method or an explanation to a complex logic. Back when I started with coding, I used to comment out some of my code that I didn’t need anymore, and I just kept it there, but I learned quickly that it wasn’t good because it just makes my code look messy. Don’t put comments like “fix this bug” but instead put something more useful like what needs to be fixed. I also learned that there is a lot of redundant and excessive comments. For example, you don’t need to write a comment explaining what i++ does because that is unnecessary as the code is self-explanatory.  Add comments that add value to your code, not make it useless and just clutter the code.

Some people say that a good code should not need comments to explain it, but I just disagree because I like reading information about the method before I start reading each line of it. If you don’t like to put comments on your code, then at least make a schema for your code so others can understand the relationship between codes better. The author shows plenty of example diagrams that show you what a code schema looks like.

Reference article : https://medium.com/@VincentOliveira/how-to-write-good-software-technical-documentation-41880a0e7814

From the blog CS@Worcester – Farouk's blog by afarouk1 and used with permission of the author. All other rights reserved by the author.

Over the past few weeks, we’ve learned about the importance of collaboration in a team. Whether that team is using Scrum or some other software development methodology, communicating with one another is one of the key pieces to achieving whatever goals they have. 

While going through the syllabus, I saw “Collaboration tools” as one of the course topics. I thought about what would exist under this category and the first one that came to mind were video calls. Zoom specifically was the one that came to mind and I wondered how it is or would be used in a software development environment.

In an article from Shari Cleare, they share that “video conferencing software provides powerful communication and collaboration tools that scrum masters can use to engage participants, especially those who cannot attend these meetings in person.” One of my first thoughts regarding this topic was that not every person on the team physically has to be at the meetings; or better yet, no one no one has to physically meet at all. This allows for greater flexibility in choosing members or in general as members can be anywhere or from anywhere, as long as they are able to be present for these online meetings.

The Scrum Master or whoever is hosting the meetings doesn’t even have to be present. Zoom allows for automatic meetings at a set time for the team so, If they are unable to make the meeting, in person or online, the other members can still perform their Sprint Planning, Daily Scrum, or other meeting.

If a team choses to meet online only due to location constraints or other reasons, you may think that it would be nice being able to work from home. I’m sure many people would rather work from the comfort of their own home, but that comfort could turn into the thing that holds them and the team back. 

Zoom can be a great tool for members that are unable to make the physical meeting, but as the main form of communication, I feel that it can easily go downhill over time. Personally, I get distracted with other things when I’m at home so doing work takes much longer than it needs to. It is also why I try to do my work while on campus. I feel that many people can relate to this and if they want to get work done and contribute to meetings and such, they should separate where they work and where they can relax.

I hope that I can have the option to do both in the future and am able to find a good balance. Going into the workplace to get work done before going home and having the freedom to work online should I be unable to make it would be great. I believe that this has become more commonplace as well. During Covid, people had to work from home, and now that it has died down, many companies are allowing either option.

https://blog.zoom.us/using-zoom-agile-software-development/

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.