Category Archives: Worcester State RD

Understanding Design Patterns: Creational, Structural, and Behavioral

Hello everyone, and welcome to my blog entry for this week! Technically, not a blog entry since I am just re-doing the one, I previously posted.

Last weekend, I listened to the podcast from the Coding Blocks Podcast (codingblocks.net). I’ve always been curious about how experienced developers structure their code to make it easier to maintain and scale, so this seemed like the perfect topic to explore. The episode focused on design patterns, specifically the three main categories: Creational, Structural, and Behavioral. Listening to it gave me a new appreciation for how these patterns help solve common software design problems and make codebases more adaptable over time.

Summary of the Podcast

The episode, which runs for about 50 minutes, features developers Michael Outlaw, Joe Zack, and Allen Underwood discussing how design patterns provide reusable solutions to recurring challenges in software development. They describe Creational patterns as those that handle object creation in a flexible way, Structural patterns as those that organize and relate classes and objects, and Behavioral patterns as those that define how objects communicate and share responsibilities.

They shared several examples, such as the Factory Method (a Creational pattern used to create objects without specifying exact classes), the Adapter (a Structural pattern that allows incompatible interfaces to work together), and the Observer (a Behavioral pattern that lets one object notify others when its state changes). What I liked most was how the hosts emphasized that patterns aren’t rigid rules, they’re practical tools developers use to make their code more consistent and easier to maintain.

Why I Selected This Resource

I chose this podcast because I wanted to deepen my understanding of how large software systems are organized. I’ve often heard about design patterns being essential for professional software engineering, but I never had a clear idea of how they were actually applied. The podcast stood out because it explained patterns in an approachable way, connecting them to real-world examples like GUI systems, game engines, and web frameworks. It helped me see that these patterns appear everywhere from database connections to event handling, and that learning them is key to writing scalable, professional-grade code.

Personal Reflections: What I Learned

After listening, I realized that design patterns are really about thinking ahead.

  • Creational patterns reminded me that object creation should be flexible, not hard-coded.
  • Structural patterns showed me how organizing relationships properly can make systems easier to extend.
  • Behavioral patterns highlighted the importance of communication between objects and how good design reduces dependencies.

What stood out to me most was how design patterns encourage better decision-making. They don’t just make code work, they make it work better over time.

Application to Future Practice

Moving forward, I plan to start identifying patterns in the code I write. I want to experiment with the Singleton pattern for managing shared resources, like configuration files, and use the Strategy pattern when implementing algorithms that can be swapped dynamically. Understanding these patterns will help me approach programming challenges with more structure and confidence, and will prepare me for real-world software development where scalability and design quality matter most.

Citation / Link

Outlaw, Michael; Zack, Joe; and Underwood, Allen. Design Patterns Explained. Coding Blocks Podcast, 2019. Available online at codingblocks.net.

This podcast helped me see how Creational, Structural, and Behavioral design patterns provide a common language for building better software. Listening to it last weekend gave me new insights into how thoughtful design decisions can make a project more flexible, maintainable, and ready for growth.

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.

Bridging Structure and Flexibility: Understanding Software Design Methodologies and Agile

Hello everyone, and welcome to my blog entry for this week!For this week’s self-directed professional development, I explored the topic of Software Design Methodologies and Agile Practices. I used several online resources, including tutorials from Atlassian Agile Coach and readings from GeeksforGeeks. Even though the focus was on understanding Agile methodologies, I found that many of the ideas connected directly to our discussions in class about the software development life cycle (SDLC) and software design principles.

Summary of the Resource

Software design methodologies provide structured approaches to building and maintaining software systems. They define how development teams plan, design, implement, test, and deliver software. Traditional methodologies like the Waterfall Model, V-Model, and Spiral Model follow a sequential or plan-driven approach — where each stage must be completed before the next begins. These models emphasize documentation, predictability, and control.

On the other hand, Agile methodologies such as Scrum, Kanban, and Extreme Programming (XP) prioritize adaptability, collaboration, and continuous feedback. Agile breaks development into small iterations or “sprints,” allowing teams to quickly adjust to changes in requirements or user needs. Instead of rigidly following a plan, Agile embraces flexibility — delivering functional software early and improving it continuously.

The Agile Manifesto summarizes this philosophy in four values:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Why I Selected This Resource

I chose to focus on Agile methodologies because I wanted to understand how modern development teams manage complexity in real-world projects. We often hear about Agile in professional settings, but I wanted to explore why it has become so widely adopted. After learning about structured models like Waterfall, I was curious to see how Agile differs in terms of flexibility, teamwork, and iterative design.

This topic also connects closely to our class discussions on object-oriented design and project management, where adaptability and maintainability are key. Understanding these methodologies helps bridge the gap between theoretical design principles and practical implementation in team environments.

Personal Reflections: What I Learned and Connections to Class

Exploring Agile helped me see how methodology shapes not only the process but also the culture of software development. Here are a few takeaways that stood out to me:

  • Iteration mirrors refinement in design. Just like UML diagrams evolve as designs improve, Agile projects evolve through sprint cycles that incorporate feedback.
  • Communication is central. In Agile, daily stand-ups and retrospectives ensure the entire team stays aligned, similar to how collaboration in object-oriented design ensures consistent architecture.
  • Adaptability is a strength, not a weakness. While traditional models aim for stability, Agile embraces change — which is essential when building modern, user-driven applications.

In class, we often focus on designing systems that can evolve. Agile reinforces that same mindset at the project management level software design should anticipate growth, not resist it.

Application to Future Practice

Moving forward, I plan to apply Agile thinking to my future software projects, especially in group work or larger systems. Instead of trying to perfect a design from the start, I’ll focus on building incrementally, testing continuously, and welcoming feedback early in the process.

For example, in future programming projects, I could organize development into short milestones, use version control branches to represent sprints, and hold mini “retrospectives” after each stage. These habits will not only improve collaboration but also help me develop adaptable, high-quality code.

Citation / Link

Atlassian Agile Coach. “What is Agile?” Atlassian. Accessed October 2025. https://www.atlassian.com/agile
GeeksforGeeks. “Software Development Life Cycle (SDLC) and its Models.” 2025. https://www.geeksforgeeks.org

This exploration helped me connect the structured approaches of traditional methodologies with the flexibility and innovation of Agile. It reinforced that software design isn’t just about code — it’s about creating systems and processes that can evolve as technology and user needs change.

From the blog Rick’s Software Journal by RickDjouwe1 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.

Understanding Git Collaboration: Communities, Upstreaming, and Merge Conflicts

Hello everyone! Welcome back to my blog posts. Today I would be delivering my first Quarter blog post.

For this week’s blog, I decided to read “Git Forks and Upstreams: How-to and a cool tip” from Atlassian Git Tutorials. I picked this article because it connects directly with what we’ve been practicing in class—working locally, pushing changes upstream, staying synchronized, and handling merge conflicts. I also wanted a guide that explained the actual Git commands rather than just high-level concepts, since I’ve been moving away from relying only on graphical interfaces.

Summary of the Resource

The article explains the difference between origin (your fork) and upstream (the original repository you forked from). It walks through how to set up your fork so you can keep it synchronized with the upstream repo, which is especially important when multiple people are contributing. Commands like git remote add upstream <url>, git fetch upstream, and git merge upstream/main are introduced step by step. The tutorial also shares a useful tip for checking how many commits your branch is ahead or behind the upstream, which makes it easier to stay in sync.

Why I Chose This Resource

I chose this article because it fills a gap in my own Git knowledge. Until recently, I mainly used the graphical interface on the side to commit, push, and sync my changes. That worked for basic assignments, but I often felt like I didn’t really understand what was happening behind the scenes. This tutorial helped me connect the dots by showing me the exact commands and explaining why they matter, especially in collaborative projects.

Reflection and Takeaways

This resource helped me see Git as more than just a tool for saving code. it’s really about teamwork. Understanding how to add and pull from upstream makes me feel much more prepared to collaborate on group projects or open-source contributions. I no longer see merge conflicts as something to fear, but as a natural part of multiple people working on the same code.

One big realization for me was how important it is to stay synchronized with upstream. In one project I did before, I once ignored updates for too long, and the merge that followed was messy and stressful. Now I understand that frequent git fetch upstream and git merge calls prevent bigger problems down the road.

Another personal shift was moving away from the GUI. While the interface made Git feel easier at first, I see now that the terminal gives me more power and clarity. Running git status, git log, or checking how far ahead/behind my branch is compared to upstream makes me feel more in control. It’s like going from driving an automatic car to learning manual, I finally understand how things actually work under the hood.

Looking ahead, I know these lessons will help me not only in this class but also in internships and my future career. Whether I’m working on an open-source project or contributing to a company’s codebase, being comfortable with upstream workflows and conflict resolution will make me a stronger and more reliable teammate.

Citation / Link

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.

Connecting Object-Oriented Principles to UML Class Diagrams

Hello everyone, and welcome to my first blog entry of the semester!

For this week’s self-directed professional development, I listened to the podcast

SOLID Principles with Uncle Bob (Robert C. Martin) on Hanselminutes. (hanselminutes.com) Even though the focus of the episode was on SOLID design principles, I found that many of the ideas connected back to the object-oriented design principles we covered in CS-343 last week. The principles were inheritance, polymorphism, encapsulation, and abstraction, and also tied naturally into our current topic of UML class diagrams.

Summary of the Podcast

Here I am just going to give you guys a tiny summary of the podcast. It’s about 45 mins.

In this episode, Scott Hanselman interviews Robert C. Martin, known as “Uncle Bob,” about how object-oriented design principles shape the flexibility and maintainability of software. He explains why well-structured code allows systems to grow and adapt, while poor design leads to fragile, hard-to-maintain projects. Uncle Bob also emphasizes the importance of thinking carefully about class responsibilities and relationships early in the design phase, which is exactly what UML class diagrams are meant to capture.

Why I Selected This Resource

I chose this podcast because it offered a professional perspective on how design principles go beyond theory and impact real-world software. Since we just studied the four pillars of OOP and are now practicing UML diagrams, I wanted a resource that would help me bridge those two areas. The episode did exactly that: it showed how principles like abstraction or encapsulation are not just coding rules but also influence how we design and visualize systems.

Personal Reflections: What I Learned and Connections to Class

Listening to Uncle Bob made me reflect on how the four OOP principles are deeply connected to UML diagrams:

  • Encapsulation: In diagrams, private attributes and public methods show how data is protected yet accessible through controlled interfaces.
  • Inheritance: The “is-a” relationships in UML are not just arrows; they communicate how subclasses extend parent classes without duplicating logic.
  • Polymorphism: Method overriding and dynamic behavior become clearer when you see how subclasses can stand in for parents in a diagram.
  • Abstraction: Interfaces and abstract classes in UML help highlight shared behaviors without tying designs to specific implementations.

What stood out to me was how Uncle Bob framed design decisions as long-term investments. A UML diagram isn’t just a class picture, it’s the foundation for whether the software remains adaptable or becomes rigid.

Application to Future Practice

Going forward in CS-343, I’ll use these insights to strengthen my UML class diagrams. I plan to treat encapsulation, inheritance, polymorphism, and abstraction as a checklist when building diagrams. For example, when defining relationships, I’ll ask whether inheritance truly makes sense or if abstraction through an interface is better. These habits will not only help me in this course but also in future projects where design clarity and flexibility are essential.

Citation / Link

  • Hanselman, Scott. SOLID Principles with Uncle Bob – Robert C. Martin. Hanselminutes Podcast, Episode #145, January 5, 2009. Available online. (hanselminutes.com)

This resource helped me connect the four pillars of object-oriented programming we studied last week with the UML class diagrams we are now practicing. It reinforced that principles and diagrams go hand in hand, shaping how professional software is designed and maintained.

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

Starting My Journey in Software Process Management

Hello everyone, my name is Rick Djouwe, and this semester I am also taking Software Process Management. While some of my other computer science courses focus on the technical side of software development, like design, coding, and architecture, this class emphasizes the processes, management strategies, and professional practices that ensure software projects succeed.

What This Course is About

Software Process Management is designed to explore the methods and tools used to manage software projects from start to finish. Topics include:

  • Version control and collaboration tools for effective teamwork.
  • Software process models (from agile to large-scale iterative methodologies).
  • Project management skills such as planning, measuring progress, estimating costs, and managing risks.
  • Software licensing and contracts, and an introduction to intellectual property.
  • Coding standards, documentation standards, and code reviews to ensure consistency and quality.
  • Software maintenance and testing as ongoing parts of the development lifecycle.

In short, this course highlights the practices that make the difference between a project that simply “works” and one that is well-managed, scalable, and sustainable.

Skills and Outcomes

By the end of this course, I will be able to:

  • Gather and prioritize requirements through communication and negotiation with stakeholders.
  • Develop project plans and track progress to ensure goals are met on time and within budget.
  • Apply management techniques in both agile and larger-scale development contexts.
  • Analyze needs and goals to make informed decisions about software solutions.
  • Understand contracts, licensing, and professional ethics within the software industry.

These skills go hand-in-hand with the Computer Science program outcomes, such as analyzing problems, applying ethical reasoning, and demonstrating leadership and effective teamwork.

Why This Matters to Me

As I prepare for a career as a software engineer, this course will strengthen my ability not only to contribute technically, but also to lead and manage software projects effectively. Understanding process management is critical in real-world environments, where collaboration, deadlines, and accountability are just as important as writing clean code.

I also see a strong connection to my current role at The Hanover Insurance Group, where teamwork, version control, documentation, and project management practices are essential to delivering quality solutions. What I learn in this class will help me bring even more value to my work, both now and in the future.

I look forward to exploring how different methodologies shape the software development lifecycle, and how project management skills complement technical expertise. My goal is to come out of this course not only as a better developer, but also as someone prepared to guide teams, manage projects, and ensure successful outcomes.

I’m also excited to meet everyone in this class and learn from each other’s perspectives and experiences as we grow together throughout the semester.

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

Welcome to My Journey in CS 343: Software Construction, Design & Architecture

Hello everyone, my name is Rick Djouwe, and this semester I am beginning CS 343: Software Construction, Design & Architecture. I am truly excited for this class because it represents the next step in strengthening my ability to think beyond coding and focus on building well-structured, scalable, and maintainable software systems.

What This Course is About

CS 343 covers a wide range of essential topics in modern software development, including:

  • Design principles such as abstraction, encapsulation, inheritance, and polymorphism.
  • Best practices like SOLID, DRY (“Don’t Repeat Yourself”), and YAGNI (“You Ain’t Gonna Need It”).
  • Design patterns that provide reusable solutions to common problems.
  • Software architectures and frameworks, including REST API design.
  • Refactoring, code smells, and concurrency, which improve software quality and longevity.
  • Modeling and documentation tools like UML, which ensure clear communication of design decisions.

In short, this course is not just about writing code, it’s about learning to think like a software engineer who can approach problems critically, design solutions thoughtfully, and work effectively with others.

Skills and Outcomes

Through CS 343, I will gain valuable experience in:

  • Collaborating with stakeholders to design, test, and deliver software systems.
  • Applying professional judgment and staying current with evolving tools and practices.
  • Organizing projects using proven methodologies and team processes.
  • Communicating complex technical concepts clearly, both in writing and orally.

These outcomes connect directly to the broader goals of my Computer Science major: analyzing problems, building solutions, and developing the professional skills needed to succeed in the field.

Why This Matters to Me

As someone pursuing a career as a software engineer specializing in artificial intelligence, this course will help me strengthen the foundations of software design and architecture that are critical in building intelligent, scalable systems. Beyond my academic goals, I also see a strong connection to my current role as an Automation Developer at The Hanover Insurance Group, where I contribute to projects that rely on thoughtful design, testing, and collaboration. The principles and practices I learn here will make me more effective in my work today while preparing me for even greater responsibilities in the future.

I am eager to reflect on my progress throughout the semester, connect this material with experiences across my other courses, and apply these lessons directly to both my professional role and long-term career.

For me, CS 343 is more than a class, it’s a bridge between where I am now and the kind of innovative, responsible, and skilled software engineer I strive to become. I am also excited to meet everyone in this course and learn from each other as we move forward together. Feel free to reach out if you’d like to connect, collaborate, or study together this semester!

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