GRASP (General Responsibility Assignment Software Patterns) assigns responsibilities for different modules of code in object-oriented software development. There are seven types of roles assigned to classes and objects to easily organize the responsibilities. These roles include Controller, Information Expert, Creator, High Cohesion, Low Coupling, Polymorphism, and Protected Classes. It is important to note that GRASP is occasionally paired with SOLID principles, making for the combination SOLID GRASP. Design patterns like this help keep code clean and more organized, making it more comprehensible and reusable.

Controller suggests that the entity responsible for handling a system operation should be its own class to act as an intermediary between the user interface and the logic of the program. This helps separate concerns as well as improve flexibility of the whole system. Information Expert focuses on assigning responsibilities to classes that include the most information required to fulfill them. By following this principle, we can design systems where responsibilities are distributed efficiently amongst classes which in turn reduces dependencies. Creator guides the allocation of responsibility for creating objects. A class should be responsible for creating objects of other classes if the first class aggregates or has a composition relationship with the second class. By following this, there will be less coupling between classes and ensures better maintainability. High cohesion advocates designing classes with a clear and focused purpose. Each class should have a single responsibility and capture related behaviors and data. This provides easier comprehension of the code and simpler test cases to write. Low Coupling relies on designing classes with minimal dependencies on other classes. The less interconnections between classes allows to create a more modular system and improves maintainability since changes to one class are less likely to affect other classes. Polymorphism enables objects of different classes to be treated the same throughout a common interface in object-oriented design. Leveraging this principle allows for the design of systems to be extensible and adaptable to new requirements and promotes loosely coupled systems.

Applying GRASP principles ensures a clear distribution of responsibilities and promotes low coupling and high cohesion among classes. These principles help create an understandable design architecture while also providing the ability to adapt to future changes. This also helps team members collaborate due to better facilitation for communication among developers and it establishes a common understanding of each component’s role and interactions.

What is GRASP (General Responsibility Assignment Software Patterns)? | Definition from TechTarget

GRASP Principles: Object-Oriented Design Patterns | by Patrick Karsh | Medium

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

So, since the end of the semester is coming up, I should be posting weekly for the near future, so stay tuned for a lot from me! With this week of work, I have two topics I wanted to discuss, both related to each class I’m taking with Professor Wurst.

Firstly, on the Software Process Management side, I wanted to discuss how we’re using Scrum, and the way it’s set up. We’re using GitLab’s issue boards, dividing them amongst where they currently are in The Sprint, with stuff like the Issue Backlog, In Process, Needs Review, Finished, and so on so forth.

This setup reminded me a hell of a lot of Trello, a website/service I’ve been using for years now! And what’s funny is that I even mentioned this in class once, and the Professor said he used to as well for Scrum. My setup is quite different compared to the setup we have on GitLab, however, it still uses a similar Scrum/Kanban-esque setup.

Here’s the two boards I mainly use, one for School, and one for Commission work, as I freelance in art. With my Comm board, it is a bit more simpler, having using tags within lists as opposed to using a list per tag. As for my schoolwork board, it’s simply just listed with each course I’m taking and items of work I need to finish. It’s a very good tool, and I highly suggest it to anyone looking to utilize Scrum or even need a good tool to organize things.

Check it out here! https://trello.com/

As for the Software Design, I was curious what kind of file the .json’s we were using were. We have been using them to store data about students and members of the modified version of LibreFoodPantry’s backend. I’ve seen them used before many times in my times modding games before, usually they store data for configuration files.

So, to learn more, I found this blog from HubSpot: https://blog.hubspot.com/website/json-files, and honestly I think I get it a bit more now. They’re simply data storage files, able to store comma seperated values, objects, and arrays. They also support multiple data types, like integer, boolean, and strings.

So putting that into the context of configuration files, like for settings in games, it makes sense why they are used, due to integer and boolean values. If an option for a game has an on/off choice, a boolean data value to hold that information would make sense, as “true” would be on, and “false” would be off. As for how integers would be used, say you want to store the value of the volume the user wants while playing the game, that can be stored as an integer from 0-100.

All in all, it’s really interesting to learn more about filetypes I don’t know too much about, and I should look into more and how they are written, like .obj, .html, and .ini.

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

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.

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.

In the realm of computer science and web development, understanding the intricacies of Application Programming Interfaces (APIs) is indispensable. My recent exploration into this subject led me to an enlightening IBM article about REST APIs, a cornerstone of modern web services and architecture. This article, fittingly titled “What is a REST API?” (IBM Article Link), delves into the principles and practices of RESTful APIs, offering a comprehensive overview that resonates deeply with our course material.

Selecting this resource was a no-brainer for me. The blend of theoretical concepts and practical applications it offers aligns perfectly with our current coursework on web development and API integration. The article’s clear delineation of REST API characteristics, alongside examples of their use in microservices architecture, provided a solid foundation for understanding their role in contemporary web development.

The six foundational principles of REST APIs, as elucidated in the article, were particularly enlightening. They include uniform interface, client-server decoupling, statelessness, cacheability, layered system architecture, and code on demand. Each principle contributes to the overall functionality and efficiency of web services, emphasizing the importance of a well-structured API.

What struck me most was the concept of statelessness in REST APIs. The idea that each request from a client to a server must contain all the information needed for the server to respond, without relying on any stored context, highlighted the need for efficient data management and transfer in web applications. This insight has reshaped my understanding of client-server interactions and will undoubtedly influence my future projects.

Furthermore, the article’s discussion on the importance of security in REST APIs, such as using OAuth 2.0 for authorization and HTTPS for secure data transmission, was particularly relevant. It underscored the critical nature of protecting data and maintaining user privacy, aspects I intend to prioritize in my future work.

In summary, this IBM article not only broadened my knowledge of REST APIs but also reinforced the importance of secure, efficient web development practices. The principles of RESTful design will be an integral part of my toolkit as I progress in my computer science career. I strongly recommend this resource to my peers for its clarity, depth, and relevance to our course.

As I continue my journey in computer science at Worcester, I am excited to apply these concepts in practical scenarios, especially in web development projects. This article has been a stepping stone in my understanding of how web technologies work in harmony to create seamless user experiences and secure, efficient web services.

Citation: “What is a REST API?” IBM. https://www.ibm.com/topics/rest-apis

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