This week, I found a study on adopting design patterns in an IT organization. The study was conducted by the University of Oregon, and a link to the study can be found at the end of the blog. I selected this study due to the fact that it dove a lot into software design patterns and why, if they are implemented correctly, they can be extremely beneficial for a company to use.

The overall purpose of this study was to, as stated in the study, provide a scholarly annotated bibliography that examines software design patterns. It wants to provide IT leaders with proof that the implementation of design patterns can achieve increased operational efficiency or the delivery of strategic benefits.

By the end of this study, you can see some clear benefits of using a good design pattern. Operationally, there is a reduced development time as well as as a reduction of errors. This is due to the development process being streamlined, as well as being reusable with tested solutions. Strategically, patterns can contribute to a system that scales over time without a lot of rework, which is huge for organizations with rapidly evolving needs. Patterns also must create a shared language which inherently allows for better collaboration between different teams working on a project.

The study also goes over how it can be implemented using phased adoption; implementing patterns gradually allowing for people to adjust. On top of this, it mentions periodic review and sharing of documentation/knowledge, two very important ideas in terms of efficiently and affectively using design patterns.

Having read this study, it certainly reinforces a lot of the ideas we mentioned when discussing design patterns. I wouldn’t necessarily say everything I read was new, and the new sounding information may have just been worded in a different way, but the study certainly did a good job as sort of drilling the benefits of why a good design pattern can be highly beneficial.

This study also opened my eyes in the sense that I feel as though in my career I may keep an eye out for how different design patterns could be implemented into any projects that I’m working on. Being able to cut back on time, while still completing different jobs in an effective manner is something that will be very important and possibly put you above other people. If I demonstrate a knowledge of design patterns and can implement them well, or at least suggest them, it may at the very minimum open my companies eyes to different possibilities.

Link to study: https://scholarsbank.uoregon.edu/server/api/core/bitstreams/b5d95a74-77d6-454b-9ed5-1f2af2633f8a/content

From the blog CS@Worcester – RBradleyBlog by Ryan Bradley and used with permission of the author. All other rights reserved by the author.

REST (Representational State Transfer) APIs have become a cornerstone in modern software development, enabling seamless communication between different systems. For those new to the field, understanding REST APIs is essential as it forms the foundation for integrating various services and building scalable applications. The blog post “Rest API Tutorial — A Complete Beginner’s Guide” from Moesif provides an excellent introduction to this topic. Here, I will summarize the content of the blog, explain why I selected this resource, and reflect on what I learned from it.

Summary of the Blog Post

The Moesif blog post starts by explaining what an API (Application Programming Interface) is and introduces REST as an architectural style for designing networked applications. It highlights that RESTful APIs are stateless, meaning each request from a client to a server must contain all the information the server needs to fulfill it. The post further discusses key concepts such as HTTP methods (GET, POST, PUT, DELETE), status codes, and the importance of endpoints in API structure.

The guide provides practical examples to illustrate these concepts, making it easier for beginners to grasp. It also touches on best practices, such as the use of proper status codes to indicate request outcomes and keeping URLs clean and intuitive. The post ends by emphasizing the importance of good documentation and consistent API versioning to ensure ease of use and maintainability.

Why I Selected This Resource

I chose this particular blog post because of its comprehensive yet beginner-friendly approach. As a computer science student, I am currently learning about software architecture and development practices. This guide stood out for its clarity in explaining complex concepts and its practical examples, which help bridge the gap between theory and real-world application. I wanted to understand REST APIs better, not just from a theoretical standpoint but in a way that I could apply in future projects, making this resource ideal.

Reflections on the Content

Reading through the blog post was eye-opening. It clarified the purpose and usage of REST APIs and reinforced my understanding of HTTP methods and status codes. The emphasis on statelessness and how each request must be self-sufficient was particularly insightful, as I previously struggled with this concept. Additionally, I learned the significance of designing intuitive endpoints and properly using status codes to indicate different outcomes, such as 200 for success or 404 for not found.

This resource has given me the confidence to start building simple RESTful APIs. I now appreciate why good API documentation and versioning are critical — they help developers maintain and scale services effectively. Moving forward, I intend to apply this knowledge in my coursework and future software projects, ensuring that the APIs I develop are well-structured, easy to use, and maintainable.

Conclusion

Overall, the “Rest API Tutorial — A Complete Beginner’s Guide” was a valuable resource that provided me with a solid foundation in RESTful API development. I highly recommend it to any beginner looking to understand how APIs work and how to implement them in practical projects. For those interested, you can read the full post here.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

One of the first topics we were introduced to was UML diagrams, which are diagrams that represent something, like the order or the makeup in a visual way. In class, we learned UML class and sequence diagrams. The class diagrams visualize the code files, listing off necessary information, like variables and methods, whether they are private, public, static, abstract, and can have notes for things with special cases. The sequence diagram visualizes the sequence of lines of code in main. UML was also used in making diagrams to explain the architecture of systems.

In this blog post, by Nishadha, they go into detail about types of diagrams and provide examples. UML stands for Unified Modeling Language, and is used to model “software solutions, application structures, system behavior and business processes.” There are 14 types of diagrams, which can be organized into 2 kinds, structure diagrams and behavioral diagrams. The structure diagrams “show different objects in a system.” The class diagrams and architecture diagrams belong to this group. The behavioral diagrams “show what should happen in a system.” The sequence diagrams belong in this group.

Structure diagrams are used to show the relationship between classes and/or objects in a software system. There are seven different diagrams, class, component, deployment, object, package, profile, and composite structure. Each offers something a little different from the other, but do essentially the same thing. Class diagrams show the relationship of classes in software, but object diagrams show the relationship of objects in a real life setting. Finding one to use that matches the situation you need it for is not hard. 

Behavioral diagrams are used to show how things are supposed to work. Like structure, there are also seven, use case, activity, state machine, sequence, communication, interaction overview, and timing. Each are more unique compared to each other than the structure diagrams are, but also do the same thing, showing the flow of it. The flow of logging into an account, the flow of shopping, the flow of code, etc. By visualizing the flow, it can allow you to see what is happening, spots that could have issues, and maximize it to be the best it can be. The post includes examples and templates of each type of diagram in case someone is interested in seeing more or if someone wants to use one. 

I chose this particular blog post because I did not know that there were this many types of UML diagrams. With this broad amount, I can see it being used not just for software and businesses, but for other things as well. Visualizing things out is very beneficial, allowing you to keep track of things and make things concrete, instead of just picturing it in your head. I think UML is cool, it is certainly different from what I have learned in the past, but I will use it whenever I need to. It is also not that hard to learn, making it a little bit more accessible.

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

Link to blog: https://dzone.com/articles/top-10-software-architecture-patterns-to-follow

Recently, we have covered a few different types of software architecture, namely Monolith, Client-Server, and Microservices. While these each have their respective use-cases, I wanted to explore more possibilities for the architecture of a software. Because of this, I have found the Top 10 Software Architecture Patterns to Follow in 2024 by Lucas Lagone. 

Lagone establishes a format to his top ten list by describing the overview, benefits, and use-case for each item. His number 1 software architecture pattern is layered architecture. According to Lagone, layered architecture (or the N-tier architecture), divides the software into several layers each responsible for their own functionalities (Lagone). This type of architecture encourages modularity, allowing for independent development of different layers of the software,  and can be utilized for a variety of types of applications (Lagone).

Lagone continues his list, discussing the rest of the architectures below:

• Serverless Architecture
• Hexagonal Architecture
• Event Sourcing
• Model-View-Controller
• Microservices Architecture (covered!)
• Service-Oriented Architecture
• Event-Driven Architecture
• Repository Pattern
• Reactive Architecture

Lastly, Lagone writes about how one can choose the right architecture for their needs, and what factors come into play. Some of these factors include the complexity of the problem domain, the project’s requirements and goals, the scalability of the project, security, team expertise, etc. (Lagone). 

I selected this resource because it is a recently written (November 2023) article that is a good reference for an updated list of software architectures currently in use. It’s a great resource that clearly gets the point across for each item in the top 10, whilst being a short enough read to be a good refresher for those unfamiliar with the information. 

Personally, I found this to be the perfect article for me to quickly learn more software architecture patterns. It doesn’t go too deep into the software jargon and terminology that only an experienced professional would know, yet it still talks to you in a way that assumes you are an educated yet learning individual. I really liked the formatting of the top 10 list, as it gave organization, purpose, and distinction to each of the items. I learned many other types of architecture, and specifically what to consider when selecting a software architecture pattern for your project/team. This is probably the most important part, as choosing an incompatible pattern for your needs could set you back even further than you were before. I hope to apply this to future jobs where I can contribute to the selection of an architecture based on this knowledge.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

In the realm of web development, the importance of REST (Representational State Transfer) APIs cannot be overstated. They serve as the backbone of communication between client and server applications, facilitating the seamless exchange of data. My recent exploration of the article “Understanding REST APIs: A Comprehensive Guide” on Medium provided a deep dive into the intricacies of RESTful architecture, the principles behind it, and practical examples of its implementation.

I chose this article because it offers a holistic view of REST APIs, making it suitable for both beginners and seasoned developers looking to refine their understanding. The author does a commendable job of breaking down complex concepts into digestible sections, ensuring readers can follow along easily. The article not only covers the technical aspects of REST APIs but also emphasizes best practices and common pitfalls, which are crucial for anyone working with APIs.

One of the key takeaways from the article was the emphasis on statelessness in REST. Each API call is independent; the server does not store any client context between requests. This design choice simplifies scalability and reliability, allowing systems to handle multiple requests without the overhead of session management. Understanding this principle has reshaped my approach to API design. I now recognize the importance of making each API call self-contained and meaningful.

Additionally, the article highlighted the significance of HTTP methods—GET, POST, PUT, DELETE—and their respective roles in interacting with resources. This reinforced my understanding of how to use these methods appropriately to perform CRUD (Create, Read, Update, Delete) operations effectively. The practical examples provided illustrated how to structure requests and handle responses, making the learning experience both informative and applicable.

This material significantly impacted my perspective on API integration in my projects. Previously, I approached APIs with a surface-level understanding, often overlooking essential details that could enhance my applications. Now, I feel equipped to design and implement more robust and efficient RESTful services. In my future practice, I plan to apply these principles not just in personal projects but also in collaborative environments, where clear communication with APIs is crucial for successful integration.

In conclusion, “Understanding REST APIs: A Comprehensive Guide” served as an invaluable resource that deepened my understanding of RESTful architecture. The insights gained will undoubtedly influence my future work as I continue to navigate the complex world of web development and API integration.

For more details, you can read the article here: Understanding REST APIs: A Comprehensive Guide.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

Christopher Okhravi explains in this video what a Strategy Design pattern is and how it works through some UML class diagrams and a little bit of pseudo-code as well as stopping at each point to explain each piece of the Strategy Pattern. All of this coming from a book called “Head-First Design Patterns” by Eric and Elizabeth Freeman. I wanted another viewpoint on the strategy pattern outside of class and in a more succinct form, so this video seemed like a good resource. Mr. Okhravi actually really cleared up a lot of the misconceptions I had about the Strategy Pattern in general, as the entirety of the video is essentially just one big example walking through each step of the Strategy Pattern process, even using the same example we had in class of the duck classes, although he does go into explaining each detail of the Strategy pattern thoroughly going into how inheritance is nearly as important as cohesion for this pattern. It also led to the revelation for me about not even needing subclasses and introducing the idea that cohesion was more important than inheritance with cohesion leading to more flexibility than just straight inheritance. Learning about this design pattern actually really helped to me to better understand how I would apply this when actually writing code, it also put the other design patterns we’ve learned about into a better perspective for me and kind of how powerful they really are. Other than this it also showed me that I didn’t really understand how the strategy pattern worked or what a design pattern completely was. But now thanks to this video I’ve definitely developed a better appreciation and a better understanding of how these design patterns work. From this point forward I’ll need to really have more supplemental material for every patter we learn about so I can actually interface with them properly. I think in the future I’ll really have to spend time learning more about other design patterns and their uses as these seem highly valuable to really understand and know how to use. Also, for any further delves into the other design patterns I’ll probably be going back to this creator here as he seems to have a good grasp on them and explains them clearly enough with the visual component for me to really understand it. I highly recommend giving this and his other videos a look as he sorts them into playlists for easy viewing.

Here’s the video on the Strategy Pattern.

From the blog CS@Worcester – aRomeoDev by aromeo4f978d012d4 and used with permission of the author. All other rights reserved by the author.

This week, I am going to be chatting about the benefits of Humanitarian Free and Open-Source Software (HFOSS). Prior to class this week, I was familiar with open-source software, as I have previously integrated some open-source projects into personal projects, but I had never heard of HFOSS specifically, and had not given thought to the potential benefits of popularizing HFOSS development in an educational environment. Instead of referencing a blog this week, I am going to look at an actual HFOSS project that can be found here.

Crisis Cleanup is a platform designed to connect volunteers with individuals affected by disasters, particularly during and after events like hurricanes. This project is a perfect example of HFOSS, demonstrating how collaborative, community-driven software can make a meaningful and real impact.

One of the coolest parts of this HFOSS project is its emphasis on community engagement. Crisis Cleanup operates on the principle that local volunteers can provide the most relevant and timely assistance to those in need. By facilitating connections between volunteers and those affected, the platform enables random people to help in ways they probably otherwise couldn’t. Combine this with the fact that anybody can contribute, and now there is a unique opportunity to create a learning environment for students. Contributors can gain practical experience in software development, project management, and user interface design while working on real-world challenges. Students can also witness the immediate impact of their contributions, reinforcing the idea that their work can lead to tangible change. As we discussed in class, this seems to raise interest/appeal in computer science in groups that are otherwise generally less interested in it, which is an awesome way to get more people involved in the field.

Crisis Cleanup also highlights the importance of adaptability in software development. During a disaster, the needs of affected individuals can change rapidly. HFOSS allows for quick iterations and updates based on feedback from users and volunteers on the ground. This agile approach to software development ensures that the platform remains relevant and effective, which is crucial for a disaster relief program in particular. I think another really cool thing about this HFOSS project (and HFOSS in general) is that the Agile methodology is generally used. It makes sense; Agile is not exclusive to professional software development teams, but to see it used or even suggested for an open-source project is not what I would have guessed at first.

Personally, I have always had an interest in Computer Science, regardless of my awareness (or lack thereof) of HFOSS. I have not yet contributed to any projects of that nature. Moving forward, maybe I will find one to contribute to on my own, now that I know how much they can help people. Overall, I think they are an excellent way to learn/enter the field of Computer Science, and I would love to see more educational environments centered around HFOSS development and projects like the Crisis Cleanup project.

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

This week, I am going to discuss the function and design of a Simple Factory pattern in Object Oriented Programming. At a very high level, this allows a programmer to centralize and encapsulate instance creation functionality into one class, as opposed to having many different classes (or your main class) depend on a large number of different classes. In my opinion, this is particularly useful when designing code that uses the strategy design pattern, as there will be objects for every concrete strategy, and many dependencies will be created. It is much easier (in at least those instances) to encapsulate all of those dependencies and creations into one class, a factory, and have that factory be dependent on all of the classes instead.

These principles are highlighted well in this blog, which provides a use case to demonstrate the usefulness of a factory. In this post, the example used is an implementation of a creature factory (admittedly less cool than a duck factory). Before implementing a simple factory, the main class is responsible to create and instantiate different creatures, and they can be created from anywhere in the code. This works, but is poorly designed, as we have discussed in class. Any time you want to make a change to the way a creature functions, for example, you might have to go edit the code in a ton of different places, and your UML diagram might just look atrocious. To address these design flaws, we can introduce the Simple Factory pattern, which centralizes creature creation logic into one dedicated class. This factory handles the instantiation of various creature types, simplifying our main class instead of scattering creation logic throughout the code. Whenever we need a creature, we call a method on the factory, which returns an instance of the requested object.

The blog example creates a CreatureFactory class with a method create(CreatureType type), which accepts the desired creature type. Inside this method, we use a conditional statement to return the appropriate creature object based on the input. For example, if we get WEREWOLF we instantiate a Werewolf object. If we want to add a new creature type, like Phoenix, we just create a new class for it and update the factory method. There’s no need to search through the entire codebase for instances where creatures are instantiated.

I admittedly don’t do a lot of object oriented programming, but the principle of using a factory makes perfect sense to me, and is something that I do and will continue to do going forward. Centralization of creation looks clean, performs clean, and makes sense. I didn’t really get into this, but it also may be extremely useful for OOP languages that do not have automatic memory management like Java does. You could also centralize the destruction of objects, possibly allowing for efficient tracking and memory allocation/deallocation.

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