Category Archives: CS-343

Understanding and Embracing YAGNI

Link: https://codibly.com/blog/articles/yagni-how-to-do-things-when-you-actually-need-them-to-be-done

The blog post “YAGNI – how to do things WHEN you actually need them to be done” goes over the YAGNI (You Ain’t Gonna Need It) principle and why it is necessary as a guardrail against over-engineering in software development. The blog starts off by explaining the origins of YAGNI, as it originated from eXtreme Programming (XP) used in agile software development teams. Essentially, YAGNI should be used so that developers can resist the urge to implement features that are not necessary or needed. The blog compares YAGNI to KISS (Keep It Simple, Stupid), as while KISS advocates for more simplicity overall, YAGNI is more focused on discouraging unnecessary functionalities. The blog also goes over the risks of over-engineering, as it can lead to more bugs and simply be a burden when it comes to maintenance. Furthermore, it can also just lead to making your code way more complex for no reason. In the end though, in order to apply YAGNI in a responsible way it requires good judgement, as some additions are harmless as long as they don’t increase the complexity, but generally speaking it is better to keep it clean and simple.

I picked this blog post because I think that this is very important practice that will apply to a workplace environment. You always want to plan ahead and implement features that may be needed in the future, but overdoing it is not good. It is very important to find a balance, as doing too much of either can lead to big problems. For our course, this blog post also covers other software design principles, as well as some agile practices too. I think that all of these principles are very important for when it comes to working in a team environment, which is something that I will most likely have to do in the future. In a team environment, it is important to make sure your code is not complex, as other people will have to read it and potentially debug it as well.

Going forward, I plan on applying YAGNI principles to my current code as well as any code that I work on in the future. This blog gave me a good reminder that just because we might need an abstraction in the future, that doesn’t mean that we have to add it now. This can just lead to more maintenance, bugs, and just unnecessary complexity. I can apply these principles favoring simple versions of programs, as well as consistently reevaulating the requirements of a program. Overall, this blog post on YAGNI gives a great view and perspective on a principle that is very important in software design.

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

Mastering OOP Fundamentals with SOLID Principles – ByteByteGo

The blog post/article I choose to read and write about is Mastering OOP Fundamentals with SOLID Principles from the ByteByteGo blog page. This blogpost goes into many aspects of the OOP programming, some of which we’ve discusses in class. The first portion delves into Encapsulation, Abstraction, Inheritance, and Polymorphism. It explores some key concepts like single inheritance, multiple inheritance, multilevel inheritance, hierarchical inheritance, method overloading, method overriding, etc. It explains how these 4 fundamentals are important for creating and utilizing OOP effectively, but in and of itself doesn’t necessarily create code that is easy to work with and maintain.

That’s why it introduces the principles of SOLID, which according to the syllabus is something we will eventually touch on in the future. The S is for Single Responsibility Principle, stating that classes should only have a single reason to change. This ensures better organization, easier debugging, and improved testability, so it’s better to split a complex class into multiple simplified classes. The O stands for Open/Closed Principle, stating that classes should be open for extension, but closed for modification. Essentially, if we want to add new behaviors to a class, new subclasses or interfaces should be added without changing what already exists. The L stands for Liskov Substitution Principle, stating that “objects of a derived class must be replaceable by objects of the bass class without altering the program’s correctness.” A subclass shouldn’t break existing functionality while behaving like it’s parent class. This somewhat relates to the interface portion of what we did in class. The I stands for Interface Segregation Principle, stating that clients should not be forced to depend on unused interfaces. Essentially, interfaces should be small and specific, with only relevant methods. Finally, the D of SOLID stands for Dependency Inversion Principle. This states that high-level modules and low-level modules should depend on abstractions, rather than each other. This can help improve flexibility and mobility, so that it’s easier to test and work with without making as many modifications.

The reason I chose this blogpost/article is because it directly relates to what we’ve learned with the fundamentals of OOP so far, as well as introducing me to something that’s planned for the syllabus. I also saw it as a good primer for Java and OOP thinking to help me better understand the general ideas and concepts that hold it up.

Even though a good portion of what was written is just reiterating some of what we’ve discussed in class, I found it really helpful to have things explained another way with the examples the blogpost gave. It helped me better grasp the purposes behind these fundamental principles and ideas in a way that felt easily digestible. The SOLID portion was also interesting, and everything intuitively makes sense. I can definitely see myself referring back to this and sticking to these ideas as I do OOP programming in the future, because it genuinely does seem to make the code easier to work with and easier to understand.

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

CS343-01: Week One Blog

Software Constr – Week One

For week one’s blog, I read the article I first found, Software Architecture Recommendations By Mark Richards. I wanted to start off with something I’ve found first before potentially either diving into more research for videos and articles or maybe even going through what my classmates have found for inspiration.

In Software Architecture Recommendations By Mark Richards, it features a software architect named Mark Richards who covers his definition of software architecture along with the key soft skills and responsibilities of an architect. There are two aspects of software architecture in his vision, as structure and as process. “Within the structural aspect of software architecture there are 4 dimensions: architecture characteristics, architecture components, architecture styles, and architecture decisions.” He mentions how there are soft skills and techniques which include negotiation, facilitation, and leadership when it comes to the process aspect he sees in software architecture.

He says that negotiation is a required skill since “almost every decision you make as an architect will be challenged. Your decisions will be challenged by other architects who think they have a better approach than you do; your decisions will be challenged by business stakeholders because they think your decision takes too long to implement or is too expensive or is not aligned with the business goals; and finally, your decisions will be challenged by development teams who believe they have a better solution.” Which makes sense since if you want to do your job, people will think what they have to say is better, more efficient, etc. So you do have to understand the political climate– as the article says– and how to navigate it to get the views and decisions you made both approved and accepted.

Facilitation is another “soft skill” that Mark Richards thought of where the architects don’t only collaborate with development teams. He says that they should also collaborate with various business stakeholders to understand a number of things such as “business drivers, explain important architecture characteristics, describe architectural solutions, and so on.” Upon further research, I found that facilitation is a shift in the architect’s role from a central decision-maker to a facilitator who empowers the development team to make architectural decisions collaboratively, so it’s a tool to have to keep things on track.

And then there’s leadership. The architect in Mark Richards’ mind is responsible for leading and guiding the development team through implementations. “They are there as a guide, mentor, coach, and facilitator to make sure the team is on track and is running as smooth as a well-oiled machine, and to be there when the team needs clarification or has questions and concerns about the architecture.”

Reading this from his perspective and his opinions are an interesting way of learning his job as a software architect since he has the experience and he has learned from the mistakes he’s made. It’s an important thing to know that even though it’s his job, he’s always learning about ways to improve and for him to share this knowledge is something that’s valuable since you can take the advice and knowledge given and apply it to your own job.

Source: https://apiumhub.com/tech-blog-barcelona/software-architecture-recommendations-mark-richards/

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

Design Patterns in Software Construction

Hi, 

For this blog post I have chosen the topic design patterns in software construction. I watched the video linked below which is titled Design Patterns in Plain English | Mosh Hamedani by Mosh which does a great job of showing how design patterns in software construction work. https://youtu.be/NU_1StN5Tkk?si=aFdc2v01YIvoGq0m

Firstly, we must understand what exactly a design pattern is with respect to code. Design patterns are reusable solutions to common problems in code. From here we can make the inference that the goal of a design pattern is to build reusable and extensible software. To help us achieve this, there are three main categories which are creational, structural and behavioral patterns. Creational patterns regard different ways to create objects. Structural patterns are about the relationship between those objects. Behavioral patterns are about the interaction/communication between objects. From these categories we would choose which one to use based on the specific problem to implement the design pattern.

To help with the process of a design pattern, you would want to use a UML diagram to better visualize and understand the whole code. This way you will be able to see the type of relationships from one body to another; whether it’s inheritance, composition, and/or dependency to name a few. Something you may see on the UML diagram could be an interface.

An interface is a powerful tool that is often used in design patterns. Furthermore, they promote loosely coupled apps and flexibility. With an interface in the design pattern it strives substantially towards the overall goal which is to build reusable and extensible software.

Mosh then goes on to discuss and show the four principles of object-oriented programming, which are encapsulation, abstraction, inheritance, and polymorphism. Encapsulation deals with bundling data and the methods that operate on it into a single unit or class and hiding the values or state of an object within a class. In coding, abstraction is in regards to reducing complexities by hiding unnecessary details in classes. A great example of abstraction to better understand is thinking of a tv remote control; it shows only what you need to see. The next one is inheritance. Inheritance is a mechanism for reusing code across classes including common behavior. Try thinking of a parent to a child class. The child class inherits the parent class, but also has instances and methods of their own. Polymorphism is the ability of a single object to take many different forms. Mosh stresses that you must know and understand these principles as they are crucial to building design patterns.

Some takeaways are understand the problem you are facing first, have a strong foundation in OOP, and know when not to use a design pattern. Furthermore, creating multiple classes or a new interface just for one or two actions of a given state is simply not worth it; go with the else if statement.

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.

Week 1 CS-343 Blog: Strategy Pattern

I want to introduce a powerful tool in the arsenal of software engineers aiming to write clean, flexible, and maintainable code. The tool that most developers would need to upgrade the code without modifying the existing client code , and it is particularly helpful in scenarios involving algorithms of your code. The tool is called “Strategy Pattern“.

What is Strategy Pattern?

Strategy Pattern is a behavioral pattern that enables the selection of algorithms at runtime. This tool is crucial for developing flexible, maintainable, and modular code. Especially when multiple algorithms are applied to solve a problem. The key goal is to allow software entites be open for extension but closed for modification, meaning without having any impact or changed on the client code, but modifying and extending it.

Type of Strategy Pattern

  1. Context – Holds a reference to a Strategy, delgates work to it. The Context doesn’t implent algorithm logic itself.
  2. Strategy Interface – Defines a common method (or set of methods) that all strategies must implement, so they’re interchangeable.
  3. Concrete Strategies: Classes implementing the Strategy interface, each providing a different algorithm implementation.

Benefits

  1. Flexibility – New strategies can be added without modifying existing code.
  2. Seperation of Concerns – Context is freed from algorithm details; each strategy handles its own logic
  3. Easy to test: You can test each strategy class independently.

Disadvantage scenario

  • Using pattern strategy creates more classes to manage, which can complicate desgin
  • Some abstraction layers which may or may not be worth it in simpler scenarios.

Conclusion

The startegy patterns is useful when you have multiple algorithms or behaviors that needs to be added or swaped dynamically, in order to solve problem without impacting the existing code. It helps you build modular, maintainable, and extensible systems. But you should be mindful about the extra complexity it comes with.

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

Unlocking Encapsulation: Why Data Hiding Matters

I came across an article on Titled “Encapsulation in Object Oriented Programming”. It Explores in detail about the core principles of object-oriented Programming (OOP): encapsulations. Although I had already heard about this concept in computer science class, that time just covered the minor details and definition without really understanding why it is so important in practice. Reading this article helped me see encapsulation in a new way, especially through real-world examples and comparisons that made the idea much easier to grasp.

               Encapsulation is explained as hiding the internal details of a class and only allowing controlled access through methods. This is usually done by keeping variables private and providing getters and setters for interaction. According to the article, errors can easily occur when other program pieces change an object’s state directly in the absence of encapsulation. However, with encapsulation, updates are subject to predetermined guidelines, maintaining the system’s unity and security.

               One of the examples that stood out to me compared encapsulation to locking a house. If all the doors and windows are left open, anyone can come in and move things around. In programming terms, that would be like exposing all fields of a class as public. By contrast, encapsulation is like keeping the house locked and only providing a few keys for safe entry. In the same way that you wouldn’t give full write access to everyone on a GitHub repository, you don’t want every part of a program to freely change the internal state of your objects. Instead, you provide limited access—like adding collaborators with specific permissions or using pull requests for controlled changes. This analogy helped me understand why developers stress the importance of data hiding: it keeps things organized, prevents misuse, and ensures that changes happen in a safe, predictable way.

               The article provided an actual scenario using a bank account class. Any piece of code might set a balanced variable to a negative value if it is public, which would go against the program’s logic. However, the application may set restrictions like “balance cannot go below zero” if the balance is private and is only accessible via the deposit() or withdraw() methods. This demonstrated to me how encapsulation guarantees that critical rules are always observed while also hiding information.

               What I learned from the article is that encapsulation goes beyond coding style—it’s about safeguarding data and ensuring programs behave correctly. A helpful way to picture it is how GitHub handles collaboration. Instead of letting everyone edit the main project directly, contributors usually fork the repository, make changes in their own copy, and then open a pull request for review. This process keeps the main branch stable while still allowing improvements, like what we practiced in our CS343 and CS348 classes at WSU.

               Overall, the article provides the details we need to practice and build stronger knowledge in the basics of the field.

References:

“Encapsulation in Object Oriented Programming” by AKshay Raut (Medium)
↪ https://akshayraut.medium.com/encapsulation-in-object-oriented-programming-4cfb0ee28f12

FreeCodeCamp. (n.d.). The Four Pillars of Object-Oriented Programming. https://www.freecodecamp.org/news/four-pillars-of-object-oriented-programming/

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.

Learning How Architecture Patterns Shape Reliable Software

For my first blog, I read “Software Architecture Patterns” from the ByteByteGo blog. The post explains what architecture patterns are, why they exist, and how they help developers organize software systems that scale and remain maintainable. It outlines several common patterns such as layered, event-driven, microservices, client server, and micro kernel, describing their main structures and the problems they solve. The article emphasizes that architecture is not about strict rules but about creating a structure that supports clarity, reliability, and growth.

The author shows how the layered pattern divides applications into presentation, business, and data layers, useful for simple or monolithic systems. Event driven architectures handle asynchronous communication, making them ideal for systems that must respond quickly to different events. Microservices split large systems into smaller, independent services that can be developed, deployed, and scaled separately. Client server architecture remains a foundation for most web applications, while micro kernel focuses on extensibility, often used in plugins or modular software.

I chose this blog because it connects directly with what we are learning in CS-343 about design principles, maintainability, and system organization. It presents architecture patterns as practical solutions rather than abstract theories. The visuals and examples in the article made complex ideas clear. Reading it helped me understand that the architecture pattern chosen for a project directly affects performance, scalability, and how teams collaborate.

What stood out to me is the focus on trade offs. Each pattern has strengths and weaknesses depending on the project’s goals. For instance, microservices improve flexibility but increase deployment complexity. Layered systems are easier to start with but can slow down change if dependencies grow too tightly coupled. This reinforced the importance of balancing simplicity, independence, and maintainability, key themes from our class discussions about SOLID and GRASP principles.

From this reading, I learned that good architecture is about creating boundaries that protect core business logic while allowing technology and frameworks to evolve. I plan to apply this by practicing modular design in future projects and thinking more critically before deciding on an architecture. Understanding patterns like microservices or event-driven systems will help me reason about trade offs when I design APIs or backend structures.

Overall, ByteByteGo’s article strengthened my understanding of architecture as the backbone of sustainable software. It made clear that design patterns are not only about writing code but about shaping how software grows over time.

Link: https://www.thoughtworks.com/en-us/insights/blog/architecture/demystify-software-architecture-patterns

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

From Inheritance to Strategy: Lessons from the Duck Simulator

One of the primary obstacles in software design is ensuring that code remains easy to maintain and extend. Initially, inheritance seems like the clear answerplacing shared code in a superclass and allowing subclasses to override as necessary. However, as demonstrated in the classic Duck Simulator example, relying solely on inheritance can result in fragile designs.

From Inheritance to Strategy

In the first version of the Duck Simulator, all ducks derived from a base Duck class. This approach worked until we introduced unique ducks like RubberDuck (which squeaks instead of quacking and cannot fly) and DecoyDuck (which does neither). Suddenly, we found ourselves needing to override or disable inherited methods, leading to duplication and design issues such as viscosity and fragility. Transitioning to interfaces helped to declutter the design, but it also required us to replicate code across similar ducks. The true breakthrough arrived with the Strategy Pattern,

We extracted behaviors like flying and quacking into separate classes (FlyWithWings, FlyNoWay, Quack, Squeak, MuteQuack). Now, ducks possess behaviors rather than inheriting them. These behaviors can be altered at runtime, and new ones can be introduced without changing existing code. This transition underscored the principle of favoring composition over inheritance and illustrated the Open-Closed Principle: code is open for extension but closed for modification.

Design Principles in Action

The exercise reinforced several essential principles: High Cohesion: Each behavior class excels at a single task. Low Coupling: Ducks are indifferent to how they fly or quack, only that they can delegate to a behavior. Encapsulate What Varies: Changes in behavior are contained, not dispersed across subclasses. Collectively, these factors enhance the design’s flexibility and maintainability.

UML: Clearly Communicating Design

We also engaged in the practice of illustrating designs through UML diagrams. In contrast to code, UML offers a higher-level representation that clarifies relationships: Associations (for instance, a Student possessing a schedule of Course objects). Multiplicity (for example, a student may enroll in 0–6 courses). Inheritance and interfaces (such as Faculty extending Employee and implementing HasCourseSchedule). Tools like PlantUML enable us to create these diagrams in Markdown, facilitating easy adjustments and sharing.

Key Takeaways

Relying solely on inheritance frequently results in fragile designs. The Strategy Pattern addresses this issue by encapsulating behavior and employing composition. Guiding principles such as High Cohesion, Low Coupling, and Open-Closed promote cleaner designs. UML diagrams provide us with a common language to convey and analyze code. What began as a straightforward duck simulator evolved into an insightful lesson on the significance of design patterns. By embracing the Strategy Pattern and utilizing UML for design modeling, we discovered how to construct systems that are not only functional but also resilient, adaptable, and easy to maintain.

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

Polymorphism in Object-Oriented Programming

Polymorphism was one of those programming words that used to sound scary the first time I ever heard of it. It literally means “many forms” but in OOP, it’s not as scary-sounding as it is. It’s basically when the same method or function can be something different based on what object it’s being called from. As soon as I started reading over some examples, it made a lot more sense.

Think of it like this: an individual might be a class student, a home sibling, and maybe a work employee. Same person, various role depending on context. In programming, polymorphism enables us to do one thing with one function that changes its behavior depending on the object.

There are two main forms of polymorphism. Compile-time polymorphism (or static) is solved before the program ever runs. That generally happens with method overloading, where you have multiple versions on the same method name with different parameters. The compiler figures out which one to invoke. Operator overloading is another example, like using “+” for numbers and strings too.

Then there is runtime polymorphism (dynamic), resolved as the program is running. That is what happens with method overriding. A case in point is a parent class Shape that has a method draw(). Subclasses such as Circle and Square override draw() to do something else. When you call draw(), the program picks one that matches the actual object.

First of all, I used to confuse this with inheritance. They definitely go hand in hand, but they are not one and the same. Inheritance is when you are copying another class’s code. Polymorphism is when you have the same method name but have different action.

A lot of people also think that using polymorphism, especially the runtime kind, makes programs really slow. I used to believe that too, but it turns out that’s not really the case anymore. Modern compilers are built to handle this kind of thing quickly with tricks like virtual tables, so the performance hit is tiny. The trade-off is worth it because you get cleaner code and way more flexibility, so worrying about speed here feels kind of outdated.

I’ve read about this and it struck me how many times I’ve made my own code overly complicated. In Java, for example, I used to create a whole bunch of methods with unique names when I could have done overloading. I also blocked overriding in subclasses because I believed that it would be slow. Now I know that not just is that fine, it’s the correct thing to do most of the time.

In the future, I’d like to use polymorphism more intentionally, especially in my Android applications. It’ll be a tremendous assistance if new functionality is introduced in the future because I won’t need to begin anew. That, to me, is the beauty of OOP, it’s not just about making things function, but making them simpler to maintain and extend in the long run.

Resources:

https://www.cincom.com/blog/smalltalk/polymorphism-in-object-oriented-programming/

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

Why Polymorphism is so Important in Programming

Polymorphism is one of those terms you hear in Computer Science that sounds confusing at first and overly complicated, until you find out you’ve probably been using it this whole time. “Polymorphism in Programming” by Johnathan Johnson is a great blog detailing exactly what it is and how it works. It gives a nice clear definition that’s easy to understand and then lists out the different types you’ll encounter along your programming journey.

Polymorphism is essentially just a process that can perform multiple tasks depending on the context of the situation. There are many forms of polymorphism as well such as Subtype (Runtime), Ad hoc (Compile-time), Parametric (Overloading), and Coercion (Casting). I won’t get too in-depth on each of these as Johnson has already done a great job of this in his blog.

The key takeaway here is that polymorphism allows you to program an interface, not just an implementation. What I mean is by creating an interface or superclass it doesn’t matter what type the object being called is you can just call the method on it. For example, you could have a list of Shape objects that can hold a circle or a square or whatever shape you want, and you can call draw() without caring which specific subclass you’re dealing with. Because of this code duplication can be severely cut down due to multiple objects using the same method all stored in the superclass.

This is similar to what we saw in class with the Duck superclass and all the subclasses with different duck types. As long as you were calling a method stored within the superclass it didn’t matter which subclass you were calling it on. Even if the subclass had overridden the method, you would just be running into ad hoc polymorphism as the program would be switching the version of the method used to that of the one stored in that particular subclass.

Even though I’ve been using polymorphism for years through my career here at Worcester State it’s good to finally learn what this practice is actually called. It’s also good to learn that there are forms of it I wasn’t always using when I could of and instead took the less efficient route to solve my problem. The concept is integral to time efficiency and when programming time is incredibly important in a lot of ways.

I plan on taking this newfound knowledge with me through the rest of my career here as well as whatever the future holds for me.

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