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.

Improving Design Communication with PlantUML (Reposted)

Why I chose this?

So for this week’s professional development blog, i decided to go with this resource regarding UML diagrams(https://miro.com/diagramming/what-is-plantuml/#what-is-plantuml) considering we’ve been working on this in class for the better part of a few class days now. While syntax is important, I wanted a resource that went beyond the basics and emphasized best practices — specifically, how to make diagrams more readable and effective as communication tools. Which ties back to what we were doing for the classwork activity, the learning objectives of the activity we did in-class together includes identifying parts of UML diagrams, being able to connect them to Java implementation or even being able to draw the diagrams using Markdown with PlantUML.

What did I learn?
The article did help me with solidifying my understanding of the lifelines, the messages and the activation bars within the UML sequence diagrams, but in general from the article, i learned how PlantUML treats diagrams as code: by writing simple text scripts, you can generate UML diagrams consistently and efficiently. This can help out in collaborative environments, where diagrams kind of have to evolve along with the codebase. The section on best practices i find the most interesting since the article highlights that diagrams should focus on clarity over completeness.

For example, a UML sequence diagram should emphasize the key messages between objects rather than every small detail. The guide also pointed out how to use colors, notes, and layout to improve readability — so them giving pointers on how to use those things is good in case we want to make things look more pretty or neat-looking. I do appreciate the explanation of how PlantUML integrates with version control systems although it’s not something i found particularly too significant. Since diagrams are stored as text, they can be tracked and managed in Git just like source code. This makes them much easier to update collaboratively, compared to traditional tools where diagrams are static images.

Reflection and Application?

I thought it might be something i’d forget about in a month or two, i do think it helped with reinforcing the core concept that the UML designs aren’t just academic exercises that we were doing in class, it can be a practical tool for teams collaborating with each other compared to the traditional tools where it’s like the diagrams are just static images alongside the fact that it isn’t just checking a box but being able to make sure everyone understands, I guess i’d say for any future projects that come to mind, i’ll apply what i’ve learned by keeping my diagrams somewhat simple and try to make it with an audience in mind since there will be people i’ll interact with and get feedback when it comes to my PlantUML code. I also wouldn’t mind experimenting with Markdown and Git so that the diagrams can evolve with the codebase, becoming almost like living documents as opposed to a static artifact.

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

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.