Category Archives: CS-343

Learning RESTful Designs Principles

So for this second quarter’s professional development activity, i read the Stack Overflow post, “Best practices for REST API design”(https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/), in basics it covers the fundamental guidelines for designing Restful APIs that are both efficient and developer-friendly, covering some key principles like properly structuring URLs, making sure to use nouns instead of verbs when it comes to endpoint naming, implementing HTTP methods accordingly to standards as well as ensuring consistency in API design. The post also talks a little bit about versioning, error handling and security as vital aspects of any production-level API.

I selected this specific resource considering it does relate to what we were doing in class and some of our homework as well, since we’re getting involved on building maintainable, modular systems and REST APIs are just one of the common interfaces used in modern software architecture, for anyone trying to work in backend development you can deepen your understanding of how to design APIs that other developers can easily understand, use and extend to some degree.

From the rest of the article(no pun intended), I learned that REST isn’t just about making the things in question work but having a consistent and predictable interface that makes client-server communication easier. I like how the article broke down best practices for naming conventions, like how using resource-based URIs like /users or /orders/1234 instead of action-based ones like /getUser makes the API more intuitive. I also remembered about the significance of using HTTP status codes, like 201 Created for successful POST requests or 404 Not Found for missing resources. These small details can contribute somewhat to API usability and maintainability.

So i’d say pretty much that the article reinforces the more architectural concepts that we’ve discussed before in class, like abstraction, modularity and encapsulation. An API that is well-designed abstracts away complex backend logic and presents a clean, understandable interface much like how we design modules in general when it comes to software construction. I also like to think that it connects to our work when it comes to some other software design principles like separation of concerns and loose coupling. RESTful Design makes it so that different parts of a system can evolve independently, which is essential for large-scale software projects.

If i had to reflect on this after my reading of the article, i would say that i realize on some occasions i find myself taking shortcuts when designing endpoints for personal projects, mostly just trying to focus on making sure it’s functionality is in suitable position as opposed to focusing on structure, but after my reading i think i’ll try to be more deliberate when it comes to naming conventions, HTTP method uses and documentation.

Overall, this resource gave me a clearer framework for thinking about web service design, and I can already see how it will help me create more scalable and maintainable software in future projects.

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.

Principle of Least Knowledge (AKA Law of Demeter)

Hello everyone, today I will be talking about the Principle of Least Knowledge (AKA Law of Demeter). When first looking into this topic I was unsure of exactly what this was and how it would be applied to programming. When doing my research I found the Khouri College of Computer Sciences at North Eastern University had a page dedicated to this topic, where this law was first introduced.

General Formulation

Illustration of the Law of Demeter, highlighting the principle of limiting interactions between objects.

The LoD is essentially a simple style rule for designing object oriented systems.

“Only talk to your immediate friends” is the motto. 

Professor Leiberherr, the author, states a formulation of “Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.” Its main motivation is to control information overload thus helping memory management as each item is closely related.

You can informally summarize the Law with these three formulations:

  • Each method can only send messages to a limited set of objects, namely to the argument objects and to the immediate subparts of the class to which the method is attached.
  • Each method is “dependent” on a limited set of objects (organize dependencies)
  • Each method “collaborates” with a limited set of objects (organize collaborations)

To formulate the Law we can choose from the following independent possibilities:

  • Object/Class
    • Class formulation is intended to be compile-time
    • Object formulation is intended to be followed conceptually
  • Messages/Generic functions/Methods
  • Weak/Strong
    • If we interpret it as all instance variables, including the inherited ones, we get the weak form of the Law. If we exclude the inherited instance variables, we get the strong form of the Law.

Benefits

In a paper written by Leiberherr, there are a couple facts stated for the benefits:

  • If the weak or strong LoD is followed and if class A’s protocol is renamed, then at most the preferred client methods of A and A’s subclasses require modification.
  • If the weak or strong LoD is followed and if the protocol of class A changes, then only preferred client methods of A and its subclasses need to be modified and only methods in the set of potential preferred clients of A and its subclasses need to be added
  • There’s even more benefits highlighted in the paper pertaining to limiting information overload.

Final Thoughts:

Prior to this webpage I knew nothing about this law/principle, however I now understand that it is a fairly useful rule or its respective use case. The law teaches you a way to program Classes, Inheritance, Abstraction, and a few other techniques. Infact There is so much more depth to this that I cant even fully fit it into this blog post. I would highly recommend you check out this page as It contains all the information you need along with sources to learn this.

, ,

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

How to become a SOLID software developer.

By Petraq Mele

Hello again to those reading this blog, this time I want to talk about an extremely topic relevant in the programming atmosphere, that being a concept known as SOLID. I managed to find a great section written by Manoj Phandis on these principles.

SOLID is an acronym of five OOP design principles designed to help make it more understandable, flexible, and maintainable.

What are the main 5 design principles?

SINGLE RESPONSIBILITY PRINCIPLE: This principle states a class should have one, and only one, reason to change. Lets take an Animal class example, as opposed to the animal class having a sound and feed parameter, separate those responsibilities into separate classes.

Some benefits include:

  • more readable, that is easier to understand
  • less error prone
  • more robust
  • better testable
  • better maintainable and extendable
  • maximizes the cohesion of classes.

OPEN CLOSED PRINCIPLE: “Open for extension” means the behavior of a module can be extended. “Closed for extension” means when we are adding/extending a modules behavior it should not result in changes to a modules source or binary code.

Demonstration of the Open/Closed Principle in object-oriented programming.

An example Manoj gives is a credit card company wanting to introduce a new preferred credit card product with double reward points. Instead of using conditionals, you create an extension via implementation inheritance or interface abstraction.

LISKOV SUBSTITUTION PRINCIPLE: LSP states functions that use references to base classes must be able to use objects of the derived class without knowing it. For LSP compliance we need to follow some rules that can be categorized into 2 groups:

  • Contract rules
    • Preconditions cannot be strengthened or weakened in a subtype
    • Invariants must be maintained
  • Variance rules
    • There must be contra-variance of the method argument in the subtype & be covariance of the return type in the subtype
    • No new exceptions can be thrown by the subtype unless they are part of the existing exception hierarchy.

INTERFACE SEGREGATION PRINCIPLE: Clients should not be forced to depend on methods they do not use. Interface segregation violations result in classes depending on things they don’t need & an increase of coupling and reduced flexibility/maintainability.

Tips to follow:

  • Prefer small, cohesive interfaces to “fat” interfaces
  • Creating smaller interfaces with just what we need
  • Have the fat interface implement your new interface.
  • Dependency of one class to another should depend on the smallest possible interface.

DEPENDENCY INVERSION PRINCIPLE: This principle has two parts. The first part says high-level modules should not depend on low-level modules. Both should depend on abstractions. The second part says Abstractions should not depend on details. Details should depend on abstractions.

Part one example:

Part two example:

Final thoughts:

Overall these principles are very useful when it comes to object-oriented software development. I learned quite a good amount and I want to thank Manoj Phandis for their amazing outline of the SOLID principles, I would advise you to check them out in his website incase you’re interested in learning more.

, ,

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

Application Programming Interfaces

Source: altexsoft

Application Programming Interfaces, or APIs, are the communicating code between a client and server, kind of like a user interface for the computer. They are what receives information from the user interface, sends it to the server to get a result, and sends that result back to the user interface. APIs can be private, partnered, or public. Private is where the API is only available for an organization to use. Partnered is where the API is available to a group of organizations that are in partnership with each other share it. Public is where the API is available to everyone. In our setting, the Thea’s Pantry API is public, mainly used by food pantry volunteers, but the code is openly available on GitLab. 

There are also different types/formats of APIs, like Remote Procedure Call (RPC), Service Object Access Protocol (SOAP), and Representational State Transfer (REST). RPC is when the client requests data from the server and the server sends it. SOAP is a protocol that exchanges data in a decentralized environment, it uses XML messaging between the client and server through HTTP or SMTP. SOAP is known for its high security of data. REST is a protocol where resources are given a URL that can be used to request the data using HTTP methods. REST is simpler and more versatile than SOAP because it requires less complex code writing and uses many formats beyond XML. 

In class and in the homework assignments, we focused on REST API with JSON messaging. We practiced sending requests for GET, POST, PUT, PATCH, and DELETE and some of their different responses like success, entry error, and server error. We also learned how to write our own requests for creating guests, changing a guest’s information, retrieving a guest’s information, and deleting a guest from the system. Some methods, like POST, require arguments as well. To post a new guest, the request needs to have the new UUID and all the information their user will have, like if they are a resident and if they receive financial assistance. To receive a list of users that fit a certain criteria, the GET request needs to have a specific tag in the URL to specify the endpoint. 

Learning APIs will be extremely helpful for the future. In software development, APIs are everywhere. While REST is the most common, it is still useful to know the other kinds as well, like SOAP, and how to use them. Everyone uses APIs: Google, Amazon, Microsoft, Netflix, and many, many more. Getting first hand experience using and building APIs allows me to expand my skillset for real-life applications.

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

Understanding the Twelve Principles of Agile Software

The 12 Principles of Agile Software explained

For this professional development entry, I chose to read the article titled The Twelve Principles of Agile Software Explained from the Agile Alliance website. The article provides an overview of the core ideas that shape the Agile Manifesto and explains how they guide the way modern software is built. What immediately caught my attention was how the principles focus on people, teamwork, and adaptability rather than strict processes or heavy documentation. The article highlights that Agile is not simply a development framework but a philosophy centered on collaboration and continuous improvement. It emphasizes that successful teams listen to their customers, respond to change quickly, and work together to deliver valuable software frequently rather than saving everything for one big release.

I found this resource helpful because it connects directly with what we have been studying in CS-343 about software processes and team communication. In many group projects, I have experienced situations where rigid planning or lack of communication slowed progress. Reading this article helped me see that Agile’s emphasis on flexibility and open dialogue could have prevented some of those problems. The principle that stood out to me most was “responding to change over following a plan.” This idea made me realize that while planning is important, being adaptable is even more valuable. Real-world projects rarely go exactly as expected, and being able to adjust quickly is a skill that separates good teams from great ones.

Another key takeaway for me was the focus on sustainable development. The article explained that teams should maintain a consistent pace and avoid burnout, which is something I think every computer science student can relate to. It is easy to fall into a cycle of late nights and last-minute fixes, but this principle reminded me that long-term quality depends on balance and discipline. The principle about motivated individuals also resonated with me. It stated that the best results come from trusting team members and giving them the environment and support they need to succeed. I have noticed this in my own coursework; when everyone feels respected and valued, collaboration becomes smoother and creativity increases.

The article also touched on the importance of reflection, encouraging teams to pause regularly to discuss what went well and what could be improved. This aligns perfectly with the concept of continuous improvement that we discuss in class. I learned that retrospectives are not just about fixing mistakes but about strengthening the team’s process as a whole. Moving forward, I plan to apply these ideas in future projects by promoting open communication, being willing to adjust plans when needed, and supporting my teammates in maintaining a healthy work rhythm.

Overall, this resource gave me a deeper understanding of what it truly means to work in an Agile environment. It showed me that Agile is not about speed but about building smarter, more collaborative, and more human-centered teams. The twelve principles serve as a strong foundation for both professional development and teamwork, and I believe they will continue to guide me as I grow in my career as a software developer.

From the blog CS@Worcester – Life of Chris by Christian Oboh and used with permission of the author. All other rights reserved by the author.

Blog Entry: Duck Simulator

Summary of the Resource

The resource I explored is the Duck Simulator project from the article “Design Patterns: The Strategy Pattern in Duck Simulations” by Head First Design Patterns (https://www.oreilly.com/library/view/head-first-design/0596007124/ch06.html). The simulator features different types of ducks like Mallard, Redhead, and Rubber ducks with behaviours such as flying and quacking. What’s particularly interesting is that these behaviours aren’t hard-coded into the duck classes; instead, they can be assigned or changed dynamically at runtime. This design highlights important object-oriented programming concepts, including polymorphism, encapsulation, and code reusability. It also demonstrates how the strategy design pattern allows developers to build flexible, scalable, and maintainable programs. The simulation is not only educational but also fun, giving a visual and interactive way to understand abstract programming concepts.

Why I Chose This Resource

I chose the Duck Simulator because it is a hands-on, practical example that clearly demonstrates OOP principles we are currently learning in class. I was looking for a resource that is engaging, easy to follow, and yet illustrates advanced programming concepts like abstraction, interfaces, and composition. The simulator is particularly appealing because it shows how separating behaviours from the main duck classes makes it easy to add new features or modify existing ones without rewriting the core code. This approach mirrors how professional software projects are structured, and I wanted to see an example that connects what we learn in theory to practical programming.

What I Learned and Reflected On

Working through the Duck Simulator helped me understand how to design flexible and maintainable code. Previously, I often relied on inheritance to share behaviours, but this project demonstrated how composition provides more adaptability and control. For example, I could give a Mallard duck a “fly with rocket” behaviour without touching the original class—something that would have been difficult or messy using only inheritance.

The project also helped me see the value of modular thinking, treating behaviours as separate, reusable components that can be mixed and matched across objects. This makes it much simpler to extend the program, add new duck types, or implement additional actions. Experimenting with the simulation gave me a tangible way to understand polymorphism and modular design, which made abstract class concepts from lectures much easier to grasp. It also reinforced the idea that writing clean, reusable code is as important as writing code that just works.

How I’ll Use This in the Future

In my future projects, I plan to apply the lessons from the Duck Simulator by designing programs in which behaviours can be swapped, updated, or extended independently of the main code. This will be especially useful in games, simulations, or any software where features may change over time. The project reinforced the importance of thinking ahead about software structure and planning for flexibility, rather than just focusing on making the code functional. Overall, the Duck Simulator showed me that good software design is a skill that complements programming ability, and it’s something I will carry forward in both my academic and professional projects.

From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.

The Value of Clean, Readable Code

Link to resource:
Why Clean Code is Important | The Power of Clean Code

While searching for a resource on software development and craftsmanship, I stumbled onto the article “The Clean Code Debate: Why Readable Code Still Wins.” It explores a long-standing debate among developers about the continued applicability of “clean code” the idea of writing code that is easy to read, understand, and maintain. In contemporary software development. Although frameworks and technology are developing quickly, the author argues that the ability to produce understandable codes that other developers can work with will always be necessary. The article discusses how techniques like consistent naming, few functions, and a clear structure lessen issues and promote collaboration, all while referencing Robert C. Martin’s Clean Code principles.

I choose this resource because I have noticed that a lot of programming projects and classes place more emphasis on getting the code to function than on making it readable or clean. I have come to understand the value of “maintainability” as I get ready to enter the workforce, not only for myself but also for everyone who might use my code in the future. The author made a particularly strong argument when she said that teams eventually get slower due to careless code. It brought back memories of collaborative projects where unclear variable names or a disorganized organization led to misunderstandings and more troubleshooting. I learned from reading this essay that producing “clean code” is about respecting future developers who will have to maintain or enhance the project, not only about style.

The essay taught me that the ideas of software architecture and design that we cover in CS-343 are directly supported by clean code. Writing code that is simple to modify and expand is related to ideas like modularity, separation of concerns, and readability. I too had to consider my own coding practices after reading the post. Although I occasionally shave corners to meet deadlines, this served as a reminder that little routines, such as explicitly naming functions or reworking when something seems too complicated, can add up to a significant impact over time. I intend to put these concepts into practice going forward by going over my assignments and side projects for readability and clarity rather than just functioning.

All things considered, this resource reaffirmed that “clean code” is a professional approach rather than merely an outdated notion. Great developers will always be defined by their ability to communicate through code, even when frameworks, languages, and tools change.

From the blog CS@Worcester – Life of Chris by Christian Oboh and used with permission of the author. All other rights reserved by the author.

Blog Entry 2

Author: Yousef
Source:
Terra, John. AI for Project Management: Creating More Efficiency, Accuracy, and Better Results. UMass Global Blog, 2025.
https://bootcamp.umass.edu/blog/project-management/ai-for-project-management

Artificial Intelligence and the Future of Project Management

Artificial intelligence (AI) is rapidly transforming how organizations plan, execute, and evaluate projects. In his article, John Terra discusses the growing role of AI in automating processes that once required manual decision-making. He points out that AI technologies can analyze vast amounts of project data to identify trends, risks, and inefficiencies—long before human managers might notice them. This shift marks the beginning of a new era in project management, one where data and prediction take precedence over instinct and routine.

AI tools are now capable of predictive analytics, providing project leaders with accurate forecasts of timelines, costs, and potential risks. Terra also highlights emerging tools such as AI-driven chatbots that handle repetitive communications and machine learning models that track project performance in real time. These systems not only speed up workflow but also strengthen collaboration by giving every stakeholder access to transparent, centralized data. Importantly, Terra reminds readers that AI should complement not replace human judgment. Successful implementation still depends on leadership, empathy, and the ability to interpret data responsibly.

Why This Resource Stood Out

I was drawn to this article because it directly connects to the topics we have explored in Managing Information Systems specifically the use of technology to improve productivity, communication, and decision-making. As someone with a background in IT, I see AI as the next natural step in project management evolution. We already use tools such as GitHub and Trello to coordinate group work efficiently; AI takes this one step further by adding intelligence to those systems. Reading this piece helped me visualize how the principles we study in class can scale up to global business operations that depend on precise, data-driven project control.

Reflection and Application

Terra’s article expanded my understanding of what it means to manage projects effectively in the digital age. I learned that efficiency is not simply about speed it’s about designing systems that anticipate challenges before they occur. The idea of predictive risk management resonated strongly with me because it parallels what we strive for in software engineering: proactive problem-solving instead of reactive troubleshooting.

Another key takeaway was the emphasis on communication and ethics in using AI. Even the most advanced algorithms require human insight to ensure fairness, clarity, and accountability. As I advance in my career, I plan to explore AI-based project management tools and incorporate them into my workflow. This aligns perfectly with our program’s learning outcomes lifelong professional development and effective communication in both technical and managerial settings.

From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.

From UML to Design Patterns: Refactoring the Duck Simulator

Hello everyone, welcome back to my blog! In my previous post, I explored object-oriented design basics and the importance of UML diagrams for understanding class relationships. This week, I applied that knowledge to a practical assignment by refactoring the Duck Simulator project using several design patterns, and I want to share what I learned from the process.

Introduction

UML diagrams provide a visual blueprint for software systems, helping developers understand relationships, dependencies, and responsibilities of different classes. While useful on their own, combining UML with design patterns allows us to translate those visual models into flexible, reusable, and maintainable code. In the Duck Simulator project, I used UML to identify repetitive behavior and then applied Strategy, Singleton, and Factory patterns to improve the system’s design.

Using UML to Identify Problems

Originally, the Duck Simulator consisted of an abstract Duck class and subclasses like MallardDuck, RedHeadDuck, RubberDuck, and DecoyDuck. Each duck implemented its own fly and quack methods. My UML class diagram made it clear that this design was repetitive: multiple subclasses had similar or identical behaviors. This repetition violates the DRY (Don’t Repeat Yourself) principle and makes the system harder to maintain or extend. The diagrams highlighted the exact areas where behavior abstraction could be applied, providing a clear roadmap for refactoring.

Applying the Strategy Pattern

The first refactor I implemented was the Strategy Pattern, which separates the fly and quack behaviors into FlyBehavior and QuackBehavior interfaces. Each duck is assigned a behavior object rather than hard-coding methods. Using UML, I could visualize how Duck classes now depend on behavior interfaces, not concrete implementations. For example, RubberDuck now uses the Squeak behavior, and DecoyDuck uses MuteQuack. This change made it easy to swap behaviors dynamically and reduced duplicated code across subclasses.

Using the Singleton Pattern

Next, I noticed that all ducks shared identical behaviors like FlyWithWings and Quack. To avoid creating multiple unnecessary instances, I applied the Singleton Pattern. UML helped illustrate that each behavior class has a static instance and a getInstance() method. This ensured that ducks reused the same behavior object, saving memory and improving consistency.

Implementing the Simple Factory Pattern

Finally, I created a DuckFactory to centralize the creation of ducks with their associated behaviors. UML shows a clear dependency from the simulator to the factory, encapsulating construction logic and removing manual behavior assignments in the simulator. This simplified code maintenance and improved readability, while maintaining all Strategy and Singleton benefits.

Reflection

This assignment reinforced how UML and design patterns complement each other. The diagrams helped me see problems in the design, and patterns provided proven solutions. After completing the refactor, the Duck Simulator is now modular, maintainable, and extensible. I can confidently add new duck types or behaviors without touching existing code. Personally, I learned that UML isn’t just documentation, it’s a tool that guides better design and code structure.

Resources

While exploring this assignment, I also reviewed a great resource that breaks down the concepts from Head First Design Patterns in a clear and structured way. You can find it here on GitHub. It helped me connect UML representations with real-world code implementations, especially when applying the Strategy Pattern in my Duck Simulator project.

From the blog CS@Worcester – Rick’s Software Journal by RickDjouwe1 and used with permission of the author. All other rights reserved by the author.

An Introduction into REST API

The topic for this blog post was REST API. I chose this topic because later on in the semester we will be going over REST API design and I wanted to get a firm understanding of what REST APIs are first. I watched the video linked below, which is titled “REST API Crash Course”, in which the first half of the video was defining and explaining what a REST API is and then the second half was how to implement REST APIs in your code. https://www.youtube.com/watch?v=qbLc5a9jdXo

To begin, what exactly is a “REST API.” It stands for Representational State Transfer Application Programming Interface. The REST part is a set of rules and guidelines about how you should build a web API. The API part is another set of rules and guidelines about how applications communicate with one another. 

In essence REST APIs are a way for two softwares to communicate with one another.  No two softwares are built the same and have their own factors and variables. For instance, if you have one application coded in Python and another application coded in JavaScript and wanted them to communicate to one another… they would not be able to due to the fact they are in different languages. This is where REST APIs come in which enables a pathway for communication between the two different applications. 

We can further expand on this by using client-server communication example. The server exposes an endpoint API → client makes a request to the endpoint API of the server→ the server processes the request → once processed, the server sends it back to the client in a JSON format. 

It should be noted the client should NOT go directly to a database. If a client to database connection did occur, it would not be good due to the fact the database info would be exposed; which could lead to corruption and information getting exposed inside of the database. With an API, the client does not receive database credentials, limited with permissions to the extent of the API, and the server always retains the real database credentials. Long story short, with an API the information stays hidden. 

There are four main methods of requesting data from the server:

-GET is used to retrieve information from the server.

-POST is used to write information to the server; add a resource.

-PUT is used to update/replace a resource on the server.

-DELETE is used to remove a resource from the server. 

Learning about REST APIs and APIs in general makes me feel a lot more comfortable when we do get to the point of our semester of REST API design. Furthermore, it’s all starting to come together in terms of software construction. Starting with design then going to a better structured scalable design, addressing the relationships of servers and clients in class and soon REST API design, very cool, looking forward to it!

From the blog CS@Worcester – Programming with Santiago by Santiago Donadio and used with permission of the author. All other rights reserved by the author.