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“.

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.

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.

I decided to write my first self-directed post about a blog I found regarding Git and its significance in software development. During our course thus far, we have spent quite the amount of time learning Git; more importantly, why it exists and how to use it. This blog summarizes the importance of Git in modern software development. Prior to its creation, there was not a feasible or reliable way to maintain code amongst developers. This led to inefficient workflows and harder collaboration that may have impeded a developer’s ability to contribute effectively to a project. The blog claims that 85% of developers believe that Git’s introduction and adoption have made collaboration much easier than it was before. It later talks about what Git is, how to set it up and some basic use cases. The author writes about some common issues with Git such as merge conflicts and how to integrate it into your IDE. Later on, the article highlights some best practices such as meaningful commit messages or committing small changes, rather than many large changes at once.

For beginners to Git like me, this was useful to reinforce what we have learned in class so far. I chose this resource to learn more about Git outside of class. I had previously heard of Git and GitHub from prior usage of the Internet, though, I had no idea how it was used or how prevalent it would be within the computer science field. Since Git was a newer topic for me and one that I had not touched upon in my 7 years of studying information technology and computer science, I wanted to look more into it outside of class to get a better grasp on it. I feel that after reading this blog, I am more comfortable using Git than I was before. For me, I love to learn new things, and I find that learning something from multiple different angles is often most effective for me. Using this in combination with the lectures and practice from class has been a useful resource for me to improve my Git skills. Within the realm of software development, knowing Git, or at least how version control systems work, is imperative to being successful within the field. Even outside the field, knowing collaboration, effective communication, and teamwork is essential, since computer science is rarely an independent field. I also feel more confident after reading this article, knowing the best practices and common issues that I may run into while working in the field. Overall, this article was extremely effective in expanding my understanding on Git and version control systems.

The link to the article can be found here: https://blog.rheinwerk-computing.com/gits-significance-in-software-development

CS-348
CS@Worcester
Quarter-1

ZG

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

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.

This blog is based on “OOP Principles: What is Object Oriented Programming?” from Full Stack Foundations. The article has a clear understanding of the four core pillars of object-oriented programming. That being encapsulation, abstraction, inheritance, and polymorphism. It also explores how these principles tie into more advanced design ideas such as composition over inheritance and more.

The article begins by explaining why OOP is valuable, emphasizing that it organizes code into modular blocks that bundle together data. OOP helps developers manage complexity in large systems. It then talks about encapsulation as the practice of hiding code and exposing only interfaces, which helps reduce unintended interactions. Abstraction is explained as representing concepts with simplified models. Inheritance is presented as a practice that allows new classes to build upon existing ones, enabling reuse of behavior. Finally, polymorphism is described as the ability to treat different classes as instances of a common base type, making systems more flexible and adaptable. Later in the article, the author connects these principles to design patterns, noting that good object design avoids fragile hierarchies.

I chose this article because it’s connection to our class, discussing design concepts. OOP is a key topic in this course, from abstraction and encapsulation to design principles and patterns, and I thought this blog was a good representation of OOP. It struck a good balance between the basics of OOP and the many ideas that are needed to think about design in a professional way.

Reading this article reminded me that OOP is more than just syntax like classes and methods. The discussion on abstraction and encapsulation stood out the most to me because in my past projects and classes I often never thought about the exposure of too many details of a class, either through public fields or otherwise. The article emphasized that clean abstraction is essential for maintainability. I also appreciated the warning about inheritance. The article shared the idea that using composition over inheritance can prevent problems and lead to more flexible ideas.

The main takeaway for me is that OOP is an idea that allows code to be built clean and modular rather than something that has to be perfected up front. In future assignments and projects, I want to be more aware about the principles of clean OOP coding. I also plan to make better use of interfaces and encapsulation so that classes depend less on concrete implementations. This resource gave me a refresher on these ideas and hopefully I can build systems that are easier to maintain and improve upon.

https://www.fullstackfoundations.com/blog/oop-principles?

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

When I first started learning Git, it honestly felt like a different language. Everyone else around me seemed to know what they were doing cloning repos, branching and pushing changes to their remote repositories. I’d hesitate before every command, worried that I was about to break something permanently. Reading guides like DataCamp’s roadmap for beginners gave me … 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.

When I first came across UML in our class activity projects, I often felt lost trying to understand it. There were so many different diagram types, rules, and notations that I struggled to keep track of them all. At first, the symbols looked like a foreign language, and I wasn’t sure how they connected to … 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.