Category Archives: Quarter-3

More about SOLID design principles

For this quarters blog post, I wanted to write about SOLID design principles and chose SOLID design principles explained written by Phillip Johnson to better my understanding. During class activities we learned about design principles, specially object oriented programming which goes in hand with SOLID. Johnson’s blog explains these ideas in a clear and real-world way, using examples from different programming languages that we don’t use in class like Ruby and C#.

In Johnson’s post, he begins by sharing his personal experience when he first encountered SOLID through Sandi Metz’s book and how it helped him write better code across different languages. SOLID originates from an essay written by Robert Martin, also known as Uncle Bob in which he emphasizes that “successful applications will change and, without good design, can become rigid, fragile, immobile and viscous. These are some terms we learned in class. SOLID stands for five key ideas: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion.

Single Responsibility: we should avoid making multiple tasks in one class. Johnson’s example refactors database and file operations into separate classes. Open/Closed: extend behaviors without altering existing code, essentially if we wanted to add/change functions in an existing class then we should be able to do so by extending the class instead of modifying it. Johnson also uses the duck example that we worked on. Liskov Substitution: sub classes should work just like their parent classes. We shouldn’t be making overrides that change expected behaviors. Interface Segregation: Use small, specific interfaces instead of big ones. Johnson’s example uses ducks and fish, and how we should separate each behavior just like we did in our Design Patterns homework. Dependency Inversion: rely on abstractions and not specific details. Basically, High-level code shouldn’t depend on low-level details.

From Johnson’s blog, I was able to learn more in depth about what SOLID is, how each of the principles connect, and how to find code smells. I think his post helped me understand our previous Design Patterns homework even more than I did while completing it. What stood out to me most was that the blog didn’t just explain what SOLID is. It showed me why these principles matter in real code. I realized that creating good code isn’t just about make it work once, but rather about making it easy to maintain, refactor, and improve over time. Because of this, I want to prioritize using SOLID a lot more in my future coding projects so that my code remains clean, adaptable, and easy to extend.

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

UML Class Diagrams

Link: https://www.jointjs.com/blog/uml-class-diagrams

In this blog post, I decided to look at Martin Kaněra’s blog post titled “UML Class Diagrams: All you need to know.” This blog post gives a comprehensive overview of UML class diagrams, covering what they are, why they matter in object-oriented development, and how they can compare to other UML diagrams. This post explains that UML class diagrams model the static structure of systems by showing classes, attributes, and methods. They also show the relationships between them, such as association, inheritance, and aggregation. Kaněra says that each class rectangle is divided into three parts, which are name, attributes, and methods. There are visibility symbols such as “+” for public, “#” for protected, and “-” for private. I liked how Kaněra discussed abstract classes and interfaces, as we see those concepts show up often and they can sometimes be a little bit confusing unless you see them drawn out. The blog also mentions how class diagrams should be used for structure, sequence diagrams should be used for object interactions over time, and that activity diagrams should be used for flows of control.

I chose this blog post because we went over the UML class diagrams earlier this semester, so I thought it would be nice to get a quick refresher and also do a deeper dive into the topic. We’ve done assignments involving UML diagrams, but there were always a few small things I would get confused about so it was nice to get clarification. I also think that it is very important to know this stuff, as this is a part of how real teams design and discuss systems. This blog post does a very good job of showing how class diagrams play a role in real life software projects as well.

Reading this blog post made me realize how important UML class diagrams are. Kaněra does a good job placing emphasis on identifying design problems early, such as classes that have too many dependencies. This just further shows how useful these diagrams are for projects. In the future, I can apply this by sketching a quick class diagram before I start coding a feature, and then I could revisit it while I am working on the project. I can also do this for group projects, as using a shared diagram could help keep everyone on the same page for terminology and boundaries between components.

Overall, this blog post helped refresh my memory on UML class diagrams, and also gave me some further clarification on certain principles. After reading this blog, I feel much more confident in implementing UML class diagrams into future projects.

From the blog CS@Worcester – Coding Canvas by Sean Wang and used with permission of the author. All other rights reserved by the author.

API

The software landscape is dynamic and constantly changing. Application Programming Interfaces(API’s) have evolved from what was once an optional tool, to a vital epic of software architecture. These APIs are the joining forces between different systems allowing mobile devices, third party services, backend microservices, and front end interfaces to interact in an efficient structured manner. 

Simply put, API defines rules and protocols for software components to interact. When focusing on backend development, API’s are used to show system functionality. Whether its authenticating users or  retrieving data APIs can expose flaws or confirm functionality. This rewards systems that have flexibility in their development because the internal implementation can be abstracted from the external interface. 

There are several types of APIs that have specific implementations for system architecture.

  • REST API’s: REST or (Representational State Transfer) is the most prevalent for web based services. These use the standard HTTP(GET, POST, PUT, and DELETE), and client stateless architecture. Client stateless architecture is a system where the server stores one of the client information, rather it treats each request as a self contained independent transaction.
  • GraphQL APIs: These enable clients to request specific needed data from a single endpoint. This can cut back on network overhead simplifying client code. This is useful for client-driven backends.
  • Websocket API’s: these are useful for real-time, two directional communication. This includes chats, gaming, updates, ect. This allows persistent connection between the client and server. Using Websocket entails event-driven design

APIs are essential for maintainable back-end architecture. Alongside these APIs, there are best practices to follow to get the most out of API’s. Clear naming conventions should be used to ensure consumers understand. Using intuitive consistent resource names allows for a clearer overall architecture. The next best practice is Versioning. As systems change, versionaling ensures that people running older clients can still run them. This backwards compatibility is essential. Keeping good documentation is also very necessary. This helps developers understand how to use the API and how it interacts with the larger system. Security is needed to safeguard data and API endpoints. And finally error handling with meaningful messages helps keep everything clear while testing for development and dealing with bugs. 

Choosing the correct backend framework can influence how you create your API. Express.js on Node.js, is lightweight and suited for RESTful services. Django REST Framework is built on python and uses rapid API development containing built in features. Spring boot is Java based and is good for microservices architecture. This  isn’t just picking a syntax, this shapes how you test, modularize, secure and scale this architecture. 

My personal experience has now shown how useful API design is. When building a simple REST API for guest data, I defined clear endpoints, selected correct HTTP verbs, and used tools like swagger and spectral to validate my work. This showed me how important consistent status codes are. Even small mistakes like forgetting a field or misnaming a route broke client calls. Working through this has shown me how good design can save time by reducing confusion, bugs, and reworks. 

APIs are not just endpoints, they are crucial pieces to backend software architecture. They encapsulate complexities,  and allow for scalable maintainable systems. This API layer is not just a bridge, but a foundational piece of architecture.

View at Medium.com

From the blog CS@Worcester – Aaron Nanos Software Blog by Aaron Nano and used with permission of the author. All other rights reserved by the author.

The Clean Code Debate: General Practices vs. Uncle Bob

For this quarter’s blog post, I decided to speak more about the principles of clean code. The resources I discovered when exploring this topic surprised me. I have understood the general concept of writing code that is easy to read, maintain, and understand from the start of my time here at Worcester State University. However, now I have been introduced to the more specific and controversial perspective explained by Robert C. Martin (aka, Uncle Bob). My goal with the resources I chose was to compare Uncle Bob’s approach against how clean code is viewed in more general practices.  

This resource, Clean Code: The Good, the Bad and the Ugly, explores Uncle Bob’s perspective on clean code, while the author identifies components they see to be good, bad, and ugly. The resource “Clean” Code, Horrible Performance, tests Uncle Bob’s clean code components and explains how it impacts performance. Lastly, there are two other resources that give examples of general practices of clean code.

From what I understand, the core idea of clean code is that people read code way more often than they write it, so it is important to prioritize clarity. However, on the other hand, Uncle Bob’s perspective advises for small functions and almost no comments. Some of Uncle Bob’s advice is similar to general clean code practices, but this specific advice leads to some conflicts.

The first two resources showed that sticking too closely to Uncle Bob’s principles can actually lead to decreased performance. This happens due to highly fragmented code (following his principles on small, single-purpose functions), which can be less efficient for the machine to run. The main takeaway from these conflicting views is that Uncle Bob’s ideas are helpful guidelines, but they are not universal rules. It is important to understand the trade-off between absolute readability and optimal performance based on the focus and needs of the project you are working on. 

The advice against using comments genuinely surprised me. In one way, comments are a great way for beginner coders to track the purpose of their code, and to boost their understanding of certain components (i.e., loops, methods, functions, classes, etc.). At least, that is what I often used comments for when practicing coding alone. Now I understand that, when working on a team, those initial comments can quickly become confusing and unhelpful. If a comment is not deleted or updated when the code changes, it becomes misleading. Your code should describe itself using good variables, functions, and method names. If you need a comment to explain what each part of the code does, that may be a sign of poor coding design. 

I had intended to use clean code as I continue practicing coding. However, now I have more tools under my belt to make sure my code is not just digestible for me, but also digestible to someone who may need to read or update my code without me there to explain it.

Main Resources:
“Clean” Code, Horrible Performance. Many programming “best practices” taught today are performance disasters waiting to happen – https://www.computerenhance.com/p/clean-code-horrible-performance

Clean Code: The Good, the Bad and the Ugly – https://gerlacdt.github.io/blog/posts/clean_code/

Messy Code V/S Clean Code in MVC context – https://medium.com/highape-tech/messy-code-v-s-clean-code-in-mvc-context-9ad99079a4f8

What Is Clean Code? A Guide to Principles and Best Practices – https://blog.codacy.com/what-is-clean-code

Additional Resources:
Polymorphism in Java – https://www.geeksforgeeks.org/java/polymorphism-in-java/

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.

Quarter-3 blog post

For this week’s blog post, I decided to write about the topic of Object Oriented programming (OOP). During our in class activities, we reviewed and learned how to improve our Object-Oriented software design skills. OOP can sound overwhelming with words like inheritance, encapsulation, polymorphism, and abstraction, but it becomes easier to understand after this blog post breaks it down! The blog I choose today was written by Arslan Ahmad, titled “Beginner’s Guide to Object-Oriented Programming (OOP)”, and I choose it due to how he was able to bring these topics together, explain each one, and how they all can work together in code.

Ahmad begins by tackling the first pillar, Inheritance. Inheritance is a way for one class to receive attributes or methods from another. He includes a fun and interesting example he calls the “Iron man analogy”, describing how all of his suits share core abilities, but certain parts/models add their own specialized features. I found this example useful as a fan of movies but also a great visual to really understand the idea of inheritance. Developers can use this idea to define the basic ideas, expand as needed, and use them somewhere else without rewriting the same code over and over again. This tool is strong to keep code organized and limit the amount of code/logic used.

The next pillar was encapsulation, which focuses on building attributes and the methods that operate them inside a single class. Ahmad uses an example of a house with private and public areas, showing limiting accesses to certain areas. I thought encapsulation was more about hiding information, but the post explains how it plays a key role in security and preventing accidental changes. This is defiantly something I can see using when working on larger programs where multiple classes need to interact safely.

Polymorphism was a pillar that I found the most interesting. He describes it as ” The ability of objects belonging to different classes to be treated as objects of a common superclass or interface.” This basically allows code to become more flexible and reusable. Whether though method overriding or overloading, polymorphism allows developers to write cleaner and more adaptable programs how you want to use.

Finally, the last pillar abstraction, which focuses on simplifying complex systems by deliberately hiding unnecessary details and showing only what the user need to see/interact with. He compares this to a laptop, you click on icons and press keys without having to worry to understand the hardware behind the scenes. Abstraction is very useful to keep their programs organized and easy to use.

In summary, this source helped me to connect concepts and gain further insight on these concepts that I had only understood partially before. His examples where fun and easy to understand which made the material more digestible. In the future, I expect to use these principals when writing class based programs, organizing code, and designing software that is easy to maintain!

Source: https://www.designgurus.io/blog/object-oriented-programming-oop

From the blog CS@Worcester – Mike's Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.

Good Software Design and the Single Responsibility Principle

The single responsibility principle is simple but critical in good software design. As Robert Martin puts it in his blog The Single Responsibility Principle, “The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change.” He also does a great job of comparing this to cohesion and coupling, stating that cohesion should increase between things that change for same reason and coupling should decrease for those things that change for different reasons. Funnily enough, while I was reading a post on Stack Overflow I ran into this line, “Good software design has high cohesion and low coupling.”

Designing software is complicated, and the program is typically quite complex. The single responsibility principle not only creates a stronger and smarter structure for your software but one that is more future-proof as well. When changes must be made to your program, only the pieces of your software related to that change will be modified. The low coupling I mentioned earlier will now prevent the possibility of breaking something completely unrelated. I couldn’t count the number of times my entire program would break by modifying one line when I first started coding, because my one class was doing a hundred different things.

This directly relates to what we’re working on in class right now. We are currently working with REST API, specifically creating endpoints in our specification.yaml file. Our next step will be to implement JavaScript execution for these endpoints. When we begin work on this keeping the single responsibility principle in mind will be incredibly important. It can be very easy to couple functions that look related but change for completely different reasons. For example, coupling validating new guest data and inserting the new guest into the database. While they seem very related, they may change for very different reasons. Maybe validation requirements change, causing the validation process to be modified but not the inserting of a new guest. The database structure or storage system may change leading to modifications to how the new guest is inserted but not how they’re validated. Keeping in mind that related things may change for different reasons will be key for my group leading into the next phase of our REST API work.

This principle is one that I plan on carrying with me during my career as a programmer. It will help me create more future-proofed programs in a world where things must be ready to constantly evolve and adapt. Uncle Bob’s blog was incredibly useful in my understanding of this principle on a deeper level. I feel like a stronger programmer after just reading it. I look forward to implementing what I’ve learned as soon as we start working with the JavaScript of our REST API.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

More on Clean Code

For this quarter’s blog, I decided to research more into the book Clean Code by Robert C. Martin and found a blog discussing the good, the bad, and the ugly regarding the book. I chose this article because we have spent the last few classes working through POGILs related to the book. The author writes about how Clean Code has had its positive and negative impact on software development. For new programmers, the author highlights useful practices that are good for new software developers, such as good naming techniques, not repeating your code, and having functions only do one thing. On the other side, the author describes how the age of the book and its dated techniques can be considered obsolete. Clean Code was written over twenty years ago and is heavily focused on Java programming and outdated extensions that “[limit] the applicability for modern programming practices.” Another criticism by the author is that applying the rules of the book all the time can result in harmful code, such as excessive abstraction and code that is harder to maintain over time. The author argues that programmers should learn when these rules should be broken and apply them on a case by case basis.

This article was certainly helpful to give a further opinion on Clean Code and its subject matter. After going through the Clean Code POGILs in class, I had learned many things that I was not previously taught about programming. They were helpful to correct some bad practices that I was guilty of, such as commenting in place of poorly written code. However, some topics, such as the levels of abstraction or how to use classes and methods properly were initially confusing to me. It seems like the author also expresses similar frustrations in regard to these things. The author of the article describes any of the things from the book can be described in one phrase: “it depends.” Overall though, I felt it necessary to dive deeper into Clean Code for my own benefit. Even though I do not plan on pursuing a career in software development, many of these rules and structures can be applied to other disciplines within computer science and information related fields. When the time comes for me to work on a personal project or something needed for my career, I feel better equipped to handle such a task knowing what I know now. Even if some of the advice is dated, most of it can still be applied and result in better software development.

Original blog post: https://gerlacdt.github.io/blog/posts/clean_code/

, ,

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

Understanding Software Architecture Through Martin Fowler’s Lens

Software architecture is one of those concepts that students hear often but rarely get a clear definition of. This week, I chose to read Martin Fowler’s Software Architecture Guide because it went into depth beyond surface-level definitions of architectural thinking that we usually hear. Since our course is so strongly focused on building maintainable and scalable systems, this resource fit perfectly with the themes we have discussed around design decisions and long-term maintainability in software projects.

Fowler opens the guide by addressing one of the most debated questions in the software community: What, really is architecture? He explains how many definitions focus on “high-level components” or “early design decisions,” but argues these views are incomplete. Referring to an email exchange with Ralph Johnson, Fowler insists that architecture is about “the important stuff.” Architecture is not about big diagrams or an early-stage structural choice; it is about experienced developers having a common understanding of the parts of a system that matter for its long-term health. This makes architecture dynamic and changing rather than merely static documentation.

Fowler also describes why architecture matters, even when end users never directly see it: A poor architecture leads to “cruft,” or the buildup of confusing, tangled code that slows down development. Instead of enabling fast delivery, weak internal quality ultimately hurts productivity. The argument here by Fowler is that paying attention to internal structure actually increases delivery speed because developers spend less time fighting the codebase and more time building features. What struck a chord for me in this is how architecture is coupled with practical results: maintainability, reliability, and team productivity.

I chose this article because I really enjoy the topic and wanted to learn more about software architecture in depth. Fowler’s explanation really helped me understand that architectural thinking is something developers grow into by learning to identify what is truly important in a system. This directly connects with the principles we’ve discussed in class around clean code, modularity, and design patterns. Reflecting on the material, I realized that in future software projects, including class assignments, internships, I will have to think about how my design decisions today will affect my ability-and my team’s ability-to maintain or extend the system later. Good architecture supports future evolution, as Fowler put it, and this is something I want to actively apply as I head toward more complex development work.

Resource: https://martinfowler.com/architecture/

From the blog Maria Delia by Maria Delia and used with permission of the author. All other rights reserved by the author.

Polymorphism and Inheritance: Building Flexible Game Characters

This topic explores object-oriented programming (OOP) concepts like polymorphism, inheritance, and design patterns, showing how these very basic core concepts create reusable code. In particular, the Gamma et al. book demonstrates practical use of polymorphism and abstract classes to define flexible software structures, while the OpenGL guide shows examples of implementing modular systems, such as game engines, where different objects share common behaviors but have distinct implementations. I chose these materials because developing flexible and scalable gaming systems needs an understanding of polymorphism and inheritance. Multiple character types, enemies, weapons, or objects that behave differently yet have similar functions are frequently included in video games. These resources make it easy for developers to build clear, modular code while handling complex interactions between game objects.

               With polymorphism, game developers can regularly allow different objects while each of them behaves uniquely. For instance, a role-playing game (RPG) may have several characters: Warrior, Mage, and Archer. They get from the common Character class that describe methods like Attack(), Move(), or TakeDamage(). Each subclass overrides Attack () to implement uneasy behavior: the Mage cast spells, the Warrior swings a sword, and the Archer shoots arrows. Without polymorphism, coders would use a lot of conditional statements like if (characterType == “Mage”) … else if (characterType == “Warrior”) …; this goes against Open-Closed Principle (OCP), making it difficult when adding a new character. Using inheritance and polymorphism, the addition of a rogue class would require only the implementation of the Attack() method, while existing code would remain the same.

I believe the contrast between conditional logic and polymorphism in game AI to be instructive. In simple projects, using conditional statements to handle various opponent actions could work, but as the number of characters, skills, and interactions increases, the code rapidly gets crowded and challenging to maintain. In contrast, polymorphism enables any type of enemy—such as a dragon, goblin, or mage—to implement its own action while staying handled by the game engine as a generic enemy object. By using this method, AI action becomes versatile, modular, and simpler to expand, allowing for the addition of new challenge types or unique attacks without requiring changes to the current code.

In the future, I want to use these ideas to develop generic avatar and item systems for my personal projects so that new content can be added without having to rewrite the logic. The usefulness of proper object-oriented design in real-world game production is proven by observing how these concepts are implemented in professional game engines like Unity and OpenGL, which close the gap between theory and practical application.

References

  1. Design Patterns: Elements of Reusable Object‑Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides — Addison‑Wesley, 1994. Link: https://www.oreilly.com/library/view/design-patterns-elements/0201633612/ O’Reilly Media+1
  2. OpenGL® Programming Guide: The Official Guide to Learning OpenGL® Version 4.5 with SPIR‑V by John Kessenich, Graham Sellers & Dave Shreiner — Addison‑Wesley Professional, 2016. Link: https://www.oreilly.com/library/view/opengl-r-programming-guide/9780134495514/

From the blog CS@Worcester – Pre-Learner —> A Blog Introduction by Aksh Patel and used with permission of the author. All other rights reserved by the author.

From Ideas to Licenses: My First Deep-Dive into Software Licensing

This semester I finally sat down and untangled the confusing world of software licenses, starting from a basic question: what can you actually protect when you write code? One of the first things I learned is that you cannot copyright a mere idea for a program; copyright law only protects the concrete expression, like source … 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.