Cohesion and Coupling

In this blog post, we will highlights some important details between Cohesion and Coupling. The definition of the two concepts can be difficult to understand at first, but then it is helpful to imagine a picture of how elements are interconnected, leading to further understanding as Cohesion and Coupling are correlate to each other.

In the blog summary, first of all is how they clarify the complicated definition of these two concepts. Cohesion is about how elements belong together, but it does not depend on the number of connections between elements, which is what coupling is all about. The blog post also shows the pictures that helps us imagine of how loose and tight the elements are, which can be ideal when figuring out the correct way to organize module. In other words, it should leads to high cohesion and low coupling. And finally is how to sum up to the point that why high cohesion does not only make the system easy to understand and change, it also reduces the level of coupling.

I personally choose this post because it is helpful to understand how to apply these two concepts carefully. In object-oriented programming, for example when making a class in Java, we should know when we declare too many properties that could make the class ultimately “do everything”. For example, declaring a bookstore class that do the following properties: add, remove, sale, and receipt. As we create multiple properties like this, we notice that there are properties shouldn’t be necessary, such as sale and receipt, and instead should break down into each individual class. That’s what affect the cohesion, where breaking each properties into each individual class will promote higher cohesion and lower coupling. Therefore, we call each classes a cohesive class.

This concept of Cohesion and Coupling also makes me imagine of how to organize properties in one class that looks easier to maintain. In my experience, not always when declaring a class is a cohesive class, as I can’t determine if some related properties in that class should breaks down into new classes. Therefore, it’s difficult to maintain for larger projects, making it look complicated at a glance. What I learned about these concepts is helpful to me so I can visualize how I should organize classes and properties, by applying the definition of cohesion and coupling, as high and low for each can affects future maintenance and for the overall functionalities of the project.

Source: https://blog.ttulka.com/how-cohesion-and-coupling-correlate/

From the blog CS@Worcester – Hello from Kiet by Kiet Vuong and used with permission of the author. All other rights reserved by the author.

CS343: YAML vs JSON

This week I read a blog post from Postman titled “What is YAML?” You can find that here.

What is YAML?

YAML stands for “Yet Another Markup Language.” YAML is actually a superset of JSON, which I didn’t know and didn’t intuit from the name; the blog goes into depth about the differences between JSON and YAML, in addition to other things.

What are some of the key ways in which YAML differs from JSON?

  • Syntax
    • YAML: indentation (or spaces) infer nesting; colons for KVPs and dashes for listing items
    • JSON: syntax is explicit, f.e. curly braces to define objects and square brackets to define arrays
  • Readability
    • YAML is considered more readable due to its less-astringent syntax rules, while JSON is considered less readable due to its highly structured syntax.
  • Data types
    • YAML supports more data types (such as dates and binary data) than JSON, which supports only primitives and some other data types.
  • Usage
    • YAML is the language of choice for config files and other areas where readability is key.
    • JSON is natively supported by many programming languages, meaning that it fits well into microservices and for data interchange between APIs and web services.

What is YAML used for?

  • Writing config files
  • Data interchange for API/web services
  • Storing metadata
  • Data serialization (and even converting from JSON or to/from YAML)

What is essential to know when working in YAML?

  • YAML has no hard requirements for syntax, but developing an internal style guide to ensure that files written across the organization are equally readable is an ideal best practice.
  • YAML files, especially large ones, can be broken up into individual modules in order to improve maintainability/readability.
  • YAML may present a potential security risk when configuration or other files are autogenerated and expose system/data information that otherwise should not be shown. Be careful about what data is stored in such files.

Why did I choose this blog?

During this semester, I was given an introduction into many of the tools that front-end/back-end developers will be using when working on product, such as JSON, REST, OpenAPI, and YAML. As we approach the capstone next semester, I figure we’ll be using these frameworks even more, so it would be to my benefit to get more acclimated to them now.

That’s all for this week.

Kevin N.

From the blog CS@Worcester – Kevin D. Nguyen by Kevin Nguyen and used with permission of the author. All other rights reserved by the author.

CS343-01: Fourth Quarter

Interface, Not Implementation Programming

According to what I recently learned, programming to an interface and not an implementation is one of modern software development’s “most powerful design principles.” And this is a key to building some flexible, maintainable, and professional software systems. In this blog, I’ll go over the key characteristics of this idea.

To understand this idea, the source says that programming to an interface and not an implementation is about separating what the program does and how it accomplishes the tasks it’s performing, or will be performing. The primary characteristics include abstraction over specificity, decoupling components, enhanced flexibility and extensibility, ease of maintenance and testing, and finally, polymorphism and reusability.

Abstraction over specificity means that when programming to abstractions (like interfaces), the behaviors should be without detailing the exact implementations taking place. “This approach allows for multiple implementations that fulfill the same purpose but differ in internal workings.” 

For a note: coupling in software design is where it measures the interdependence between modules or components which indicates how much they rely on each other. Low coupling is desirable. The second characteristic is Decoupling components. This means that those components become less dependent on specific implementations that cause loose coupling. “When components are decoupled, they can be easily replaced or modified without impacting other parts of the system.”

Enhanced flexibility and extensibility is where the developers introduce the new functionalities significantly changing the code and they can also swap out different implementations that “adhere to the same interface.”

Ease of maintenance and testing is the fourth principle or characteristic of “Programming to an interface, not an implementation.” This is where the testing can become simpler since the interfaces now allow for creations of mock or stub implementations. “This isolation helps developers verify each component’s behavior independently, supporting faster maintenance cycles.”

And finally, the last characteristic is Polymorphism and reusability. This is where the objects are more interchangeable, which in turn, enhances the polymorphism when focusing on interfaces. It leads to reusable code which helps a lot when the same interface can also support different implementations for various scenarios it could encounter.

This is important to know since these principles are applied to different programming paradigms. Programming paradigms are fundamental styles or approaches that are used for structuring and writing computer programs. They’re like blueprints when building a building except with problem-solving. And “programming to an interface and not an implementation” is often associated with Object-Oriented Programming, OOP, one of the different types of programming paradigms. Some of the other paradigms that this principle can be applied to are functional programming or FP and procedural programming.

Source: https://medium.com/@Masoncoding/programming-to-an-interface-not-an-implementation-024d01815070 

, ,

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

CS348-02: Quarter Four

The Vulnerabilities of Git

We use Git for a lot of things from collaborative projects to personal ones. So security threats are a topic that must be taken into account on any given day, especially for important projects. And in the article posted in July 2025, there are seven distinct security vulnerabilities that had been added, all that affect prior versions of Git.

The first of these vulnerabilities of Git is CVE-2025-48384. This includes that while reading a configuration value, Git will take off— or strip as the article says— trailing two things: carriage returns or CR and line feed or FR characters. “When writing a configuration value, however, Git does not quote trailing CR characters, causing them to be lost when they are read later on.” The article mentions how if something called a symlink exists between the stripped path and the submodule’s hooks directory, then it’s an opportunity for an attacker to “execute arbitrary code through the submodule’s post-checkout hook.”

A symlink, upon further research is also known as a symbolic link or a soft link. It’s a special computer file which refers to either another file or a directory by storing a path to it. This makes an alternative access path which doesn’t duplicate the content of the target. These links can break if the target is either moved or deleted.

The second vulnerability is called CVE-2025-48385 which happens when a repository is cloned and (optionally) Git can fetch a bundle. This allows the server to offload a porting of the said clone to a CDN or Content Delivery Network. The client of Git in this situation does not validate the advertised bundle or bundles properly which allows for “the remote side to perform protocol injection. When a specially crafted bundle is advertised, the remote end can cause the client to write the bundle to an arbitrary location, which may lead to code execution similar to the previous CVE.”

There is also a Windows only vulnerability which is a CVE-2025-48386. This is where Git uses a credential helper to authenticate the request when an authenticated remote is cloned. One of these credential helpers is Wincred which uses Windows Credential Manager to store credentials, but it also uses the content within a static buffer. This static buffer’s content is used as a “unique key to store and retrieve credentials. However, it does not properly bounds check the remaining space in the buffer, leading to potential buffer overflows.”

There are also vulnerabilities in Git GUI and Gitk, some of which are specific. CVE-2025-27613 and CVE-2025-27614 are for Gitk. CVE-2025-27613 is when running Gitk in a specifically crafted repository, Gitk can write and/or truncate arbitrary writable files when running Gitk without additional command-line arguments. CVE-2025-27614 is when the user is tricked into running a gitk filename where the filename has a very specific structure and they may run arbitrary scripts that are provided by the attacker.

Over all, always upgrade to the latest version.

Source: https://github.blog/open-source/git/git-security-vulnerabilities-announced-6/ 

, ,

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

The Power of Linters

For my final self-directed blog of the semester, I decided to dive deeper into linters and their function. In class, we had briefly gone over linters, specifically their use to correct non-inclusive or problematic language. This is useful when creating any form of documentation because we want it to be as neutral and non-problematic as possible. I found a blog post from Codacy regarding information about linters, their benefits and drawbacks, and some popular linters for different programming languages.

The article starts by detailing the history of linters, they were created by computer scientist Stephen C. Johnson in 1978 as a tool used to find errors within written code. The name was a reference to the lint trap in a dryer, which was designed to catch the unwanted lint in the machine during the drying process. The linter is a useful tool for static code analysis, which is the process of examining errors in code before executing the code. According to the article, linters can help find “coding errors, stylistic inconsistencies, bugs, violations of coding standards, and potential security vulnerabilities.” It does this by checking your code against a predefined set of rules.

The benefits of linting are that it will reduce the number of errors written into code, it creates a consistent standard for coding practices, and can help improve the objectivity of code. Some argue that the downsides of linting include too many false positives and can negatively affect the performance of programmers in the early stages of development. However, it is generally accepted that linting is a useful tool and is adopted by many development teams.

Prior to this course and the activity we completed in class, I was not aware of linters or what they could do. Most of my code errors over the years would get cleaned up by the debugger in my IDE or by any error messages that came up upon execution. I was not aware of this as a tool that I could use in my development. Though I do not program often, or plan on pursuing it as a career path, I enjoy learning about all aspects of the field. The next time I have to do any kind of programming project, I will be adding a linter to my IDE so I can have a more consistent program with less errors. I enjoy learning more about all aspects of the field to become a more well-rounded academic and professional.

, ,

Source Article: https://blog.codacy.com/what-is-a-linter

From the blog CS@Worcester – zach goddard by Zach Goddard and used with permission of the author. All other rights reserved by the author.

Writing Clean Code

Clean code is about writing software that humans can easily read, understand, and change. Not just about making something that compiles and runs. The main idea is that code should communicate clearly to other developers so the intent of each part is obvious without needing to dig through the entire project or guess what the … Read more

From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.

Learning Front End in a Microservices World

This week we learned a lot about front-end development. Working through the microservices front-end activities (MS07–MS09) really helped me understand what the front end is all about. As a CS student who loves full-stack development, the activities offered a structured approach to seeing how a front end fits into a bigger system rather than just … Read more

From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.

7 Essential Design Patterns

Design patterns are important for developers to use in their code. They make your programs easy to read and implement and they are able to be adapted to many situations. There are 3 kinds of design patterns: creational, structural, and behavioral. 

Creational patterns are used for creating objects. They give flexibility to change the creation process and allow for many types of objects to be created using the same method. The singleton pattern is used when there should only be one instance of an object. Instead of creating a new object every time you need to call it, you call a method that will call an instance of the object. The builder pattern is used when an object has a lot of optional parameters that make it difficult to know what is being applied when it is created. Using a builder pattern creates an empty or default object and then calls set methods to add each parameter you want to use. The factory pattern is for when there are a lot of objects of a certain type, but with different forms. Instead of creating many new objects, you call a factory to create the objects with the specifications hidden in the factory code. 

Structural patterns are used for how objects relate to each other. These patterns allow for high level code to be readable and simple, while keeping the intricacies hidden below the surface. The facade pattern is used when there are many operations and calculations behind the scenes of a process and those are all hidden with encapsulation. On a high level, one method will, for example, purchase a product, but deeper, there is a payment being processed, shipping calculations, inventory checks, etc. The adapter pattern is for when a program needs to be adapted to fit your code. It can be used for implementing public libraries where their units do not match what your program expects, and each time you use the public library, it calls the adapter to modify the output. 

Behavioral patterns are used for how objects interact with each other. The strategy pattern is used when you have multiple ways of doing a process. Instead of using a lot of if else statements, you can define several strategies and set each object to have a strategy. The observer pattern is used for objects that watch for something. It works by “subscribing” to receive a notification of an event. If a program is watching for errors, it would be automatically notified of any errors so it can add it to a log. 

In class, we went over the strategy, factory, and singleton patterns for the Duck example. These 7 patterns are common practice in the software development field and it’s important to know how to implement them. I watched a video explaining these patterns and now I have a deeper understanding of the three we learned and the four that were new to me. I feel confident I can expand on these in a professional setting.

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

Blog 4 Code Review

I am Dipesh Bhatta, and I am writing this blog entry for CS-348 Software Process Management for Blog Quarter 4. I chose to write about code review and how it connects to software process management. My chosen resource is an article titled “What is a Code Review?” from Atlassian (https://www.atlassian.com/agile/software-development/code-reviews). This passage explains what code review is, why it matters in software development, and how teams use it to maintain quality, consistency, and shared understanding across a project.

The passage defines code review as the practice of examining another developer’s work before it becomes part of the main codebase. It emphasizes that code review is more than a bug-finding activity. It helps improve readability, structure, naming, and overall maintainability. One important idea from the article is that code review serves as a communication channel. When developers submit changes for review, they are also sharing their reasoning and thought process with the team. This allows everyone to stay aligned and ensures that the project follows a predictable and well-managed workflow. These ideas directly connect to the concepts of structured processes and shared ownership that we learn in CS-348.

I chose this resource because code review is a key part of modern software process management. Throughout the semester, we used Git, branches, merge requests, and clean code practices. Code review brings all of these together into a single process that supports collaboration and project organization. Understanding how professional teams use code review helped me see the purpose behind good habits such as writing meaningful commit messages, keeping changes small, and separating different tasks into separate branches. These practices make reviews easier and prevent confusion later.

Another valuable point from the article is how code review helps reduce technical debt early. Small issues, such as unclear variable names or overly complex functions, may not break the program right away, but they make the code harder to maintain. Code review allows teams to fix these problems before they grow. This is especially important in long-term projects, where small mistakes can become costly if left unchecked.

The article also highlights the importance of giving feedback respectfully. Suggestions like “Could we simplify this part?” or “What do you think about renaming this variable?” create a more positive and productive review environment. I experienced this in class as well. The way feedback is written affects how teammates respond and how smoothly the discussion goes. Good communication makes the whole team stronger.

In short, code review is an essential part of software process management. It supports collaboration, improves quality, and keeps the codebase organized. Through Blog Quarter 4, I strengthened my understanding of reviews, communication, and clean coding practices that will benefit me in future projects and my career.

From the blog CS@Worcester – dipeshbhattaprofile by Dipesh Bhatta and used with permission of the author. All other rights reserved by the author.

Best Practices for Naming REST API Endpoints

For my fourth blog, I read “Best Practices for Naming REST API Endpoints” from the DreamFactory blog. The article goes over why having clear and consistent endpoint names makes a huge difference when you’re building a REST API. It talks about keeping things simple, using nouns instead of verbs, and organizing paths in a predictable way so the front end always knows where to send requests. After doing last Thursday’s activity in class, this article made even more sense because we actually saw the front end using the backend endpoints in real time.

The article explains that endpoints should describe resources, not actions. So instead of naming something /createGuest, the path should be /guests and the HTTP method determines what happens. That lined up exactly with how our project is set up. When we ran the front end with Vite and used the Lookup page, the browser sent a GET request to /guests/:id. When we registered someone, it sent a POST to /guests. Seeing those requests in the Network tab felt like watching the article play out right in front of me.

In class, we also looked at the front end state diagram, which shows the Lookup page, the Not Found modal, the Registration page, and the Registered modal. Each button or action sends a request to the backend. The article helped me understand why that flow works smoothly the backend has clean, predictable endpoint names. If the paths were messy or inconsistent, the front end wouldn’t know what to call, and the whole flow would break down.

When we opened the developer tools and watched the requests being sent, it was easy to follow what was going on because everything was named clearly. GET pulled data, POST created a record, and PUT updated it. The article talks about how important this kind of consistency is, and now I get why. It’s not just about writing code that looks nice. It’s about making the API something the front end can rely on without confusion.

I picked this article because it connected perfectly to what we did in class. Seeing the front end interact with the backend made the concepts feel real. The article basically put words to what we were experiencing: clean endpoint design makes everything easier for developers, for debugging, and for keeping the system logical as it grows.

My main takeaway is that backend decisions show up everywhere, even on the front end. Good naming makes the whole system easier to understand, and after Thursday’s activity, I see how important that is when everything starts working together.

Link: https://blog.dreamfactory.com/best-practices-for-naming-rest-api-endpoints

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.