Christopher Okhravi explains in this video what a Strategy Design pattern is and how it works through some UML class diagrams and a little bit of pseudo-code as well as stopping at each point to explain each piece of the Strategy Pattern. All of this coming from a book called “Head-First Design Patterns” by Eric and Elizabeth Freeman. I wanted another viewpoint on the strategy pattern outside of class and in a more succinct form, so this video seemed like a good resource. Mr. Okhravi actually really cleared up a lot of the misconceptions I had about the Strategy Pattern in general, as the entirety of the video is essentially just one big example walking through each step of the Strategy Pattern process, even using the same example we had in class of the duck classes, although he does go into explaining each detail of the Strategy pattern thoroughly going into how inheritance is nearly as important as cohesion for this pattern. It also led to the revelation for me about not even needing subclasses and introducing the idea that cohesion was more important than inheritance with cohesion leading to more flexibility than just straight inheritance. Learning about this design pattern actually really helped to me to better understand how I would apply this when actually writing code, it also put the other design patterns we’ve learned about into a better perspective for me and kind of how powerful they really are. Other than this it also showed me that I didn’t really understand how the strategy pattern worked or what a design pattern completely was. But now thanks to this video I’ve definitely developed a better appreciation and a better understanding of how these design patterns work. From this point forward I’ll need to really have more supplemental material for every patter we learn about so I can actually interface with them properly. I think in the future I’ll really have to spend time learning more about other design patterns and their uses as these seem highly valuable to really understand and know how to use. Also, for any further delves into the other design patterns I’ll probably be going back to this creator here as he seems to have a good grasp on them and explains them clearly enough with the visual component for me to really understand it. I highly recommend giving this and his other videos a look as he sorts them into playlists for easy viewing.

Here’s the video on the Strategy Pattern.

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

This week, I am going to be chatting about the benefits of Humanitarian Free and Open-Source Software (HFOSS). Prior to class this week, I was familiar with open-source software, as I have previously integrated some open-source projects into personal projects, but I had never heard of HFOSS specifically, and had not given thought to the potential benefits of popularizing HFOSS development in an educational environment. Instead of referencing a blog this week, I am going to look at an actual HFOSS project that can be found here.

Crisis Cleanup is a platform designed to connect volunteers with individuals affected by disasters, particularly during and after events like hurricanes. This project is a perfect example of HFOSS, demonstrating how collaborative, community-driven software can make a meaningful and real impact.

One of the coolest parts of this HFOSS project is its emphasis on community engagement. Crisis Cleanup operates on the principle that local volunteers can provide the most relevant and timely assistance to those in need. By facilitating connections between volunteers and those affected, the platform enables random people to help in ways they probably otherwise couldn’t. Combine this with the fact that anybody can contribute, and now there is a unique opportunity to create a learning environment for students. Contributors can gain practical experience in software development, project management, and user interface design while working on real-world challenges. Students can also witness the immediate impact of their contributions, reinforcing the idea that their work can lead to tangible change. As we discussed in class, this seems to raise interest/appeal in computer science in groups that are otherwise generally less interested in it, which is an awesome way to get more people involved in the field.

Crisis Cleanup also highlights the importance of adaptability in software development. During a disaster, the needs of affected individuals can change rapidly. HFOSS allows for quick iterations and updates based on feedback from users and volunteers on the ground. This agile approach to software development ensures that the platform remains relevant and effective, which is crucial for a disaster relief program in particular. I think another really cool thing about this HFOSS project (and HFOSS in general) is that the Agile methodology is generally used. It makes sense; Agile is not exclusive to professional software development teams, but to see it used or even suggested for an open-source project is not what I would have guessed at first.

Personally, I have always had an interest in Computer Science, regardless of my awareness (or lack thereof) of HFOSS. I have not yet contributed to any projects of that nature. Moving forward, maybe I will find one to contribute to on my own, now that I know how much they can help people. Overall, I think they are an excellent way to learn/enter the field of Computer Science, and I would love to see more educational environments centered around HFOSS development and projects like the Crisis Cleanup project.

From the blog CS@Worcester – Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

This week, I am going to discuss the function and design of a Simple Factory pattern in Object Oriented Programming. At a very high level, this allows a programmer to centralize and encapsulate instance creation functionality into one class, as opposed to having many different classes (or your main class) depend on a large number of different classes. In my opinion, this is particularly useful when designing code that uses the strategy design pattern, as there will be objects for every concrete strategy, and many dependencies will be created. It is much easier (in at least those instances) to encapsulate all of those dependencies and creations into one class, a factory, and have that factory be dependent on all of the classes instead.

These principles are highlighted well in this blog, which provides a use case to demonstrate the usefulness of a factory. In this post, the example used is an implementation of a creature factory (admittedly less cool than a duck factory). Before implementing a simple factory, the main class is responsible to create and instantiate different creatures, and they can be created from anywhere in the code. This works, but is poorly designed, as we have discussed in class. Any time you want to make a change to the way a creature functions, for example, you might have to go edit the code in a ton of different places, and your UML diagram might just look atrocious. To address these design flaws, we can introduce the Simple Factory pattern, which centralizes creature creation logic into one dedicated class. This factory handles the instantiation of various creature types, simplifying our main class instead of scattering creation logic throughout the code. Whenever we need a creature, we call a method on the factory, which returns an instance of the requested object.

The blog example creates a CreatureFactory class with a method create(CreatureType type), which accepts the desired creature type. Inside this method, we use a conditional statement to return the appropriate creature object based on the input. For example, if we get WEREWOLF we instantiate a Werewolf object. If we want to add a new creature type, like Phoenix, we just create a new class for it and update the factory method. There’s no need to search through the entire codebase for instances where creatures are instantiated.

I admittedly don’t do a lot of object oriented programming, but the principle of using a factory makes perfect sense to me, and is something that I do and will continue to do going forward. Centralization of creation looks clean, performs clean, and makes sense. I didn’t really get into this, but it also may be extremely useful for OOP languages that do not have automatic memory management like Java does. You could also centralize the destruction of objects, possibly allowing for efficient tracking and memory allocation/deallocation.

From the blog CS@Worcester – Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

The blog post I’ve chosen is all about PlantUML diagrams and how they can be used in ways to help your coding. The author writes about why diagrams can be useful for seeing things visually in a text heavy environment like coding is. There are many advantages to representing code in a diagram. Making the program abstract and only focusing on the process of how each thing should work with the others helps to focus on concepts rather than the implementation and actual workings of the code. There are also many types of diagrams, such as sequence diagrams that show what events take place over time, a use case diagram that shows what different levels of users are able to do, class diagrams that detail different objects’ construction, activity diagrams that can show workflow, and others. PlantUML is able to be used in many different ways for many different scenarios. There are sometimes problems that PlantUML cannot solve in the most elegant way, as the author describes, but there are alternatives and some problems that PlantUML was not designed to solve.

I think this blog was helpful to read through and see just how versatile PlantUML diagrams can be after learning about how to make them in class. Another benefit to diagrams that the blog didn’t go over, but we did in class was being able to find potential problems in the code before you even type anything which can save a lot of time. I think that using UML diagrams more often can help me with coding as having a diagram that gives me a top-down view would be helpful to look at instead of scrolling through a wall of text to find what I need to do next or how I can improve my code. I sometimes find that I can overcomplicate some sections of my code and having a written out simplified plan to look back at will help me code with more focus and also help with encapsulation which I don’t do as often as I should.

After reading this blog I will be more aware of what situations could be helped with a PlantUML diagram and make one to keep me focused on the structure and entire scope of the program. There are also ways to use diagrams in order to show processes that I haven’t used yet or have talked about in other classes which could be a good tool to use in the future to explain and show complex abstract processes.

PlantUML Diagrams – Matt Hayes

From the blog CS@Worcester – Computer Science Blog by dzona1 and used with permission of the author. All other rights reserved by the author.

In the world of computer science, especially for those new to programming, concepts like design smells and technical debt can seem daunting. However, grasping these ideas is crucial for building sustainable software. Design smells are indicators of potential problems in your code, such as overly complex structures or poor naming conventions. Technical debt, on the other hand, refers to the compromises made during the development process that can lead to greater issues down the line, akin to borrowing money that needs to be paid back later.

I recently came across the article “Understanding Technical Debt” by Tom Smith on Medium. This piece breaks down these concepts in an approachable manner, making them easier to understand for beginners. Smith discusses common design smells, such as “Long Method” and “Feature Envy,” and explains how they can accumulate into technical debt if ignored.

I chose this article because I believe it provides a solid foundation for understanding these concepts without overwhelming beginners with jargon. As I embark on my journey in computer science, I find it essential to learn about the long-term implications of my coding decisions. Smith’s article highlights the importance of recognizing design smells early on, which resonated with me as I often focus on getting things done rather than considering the quality of my code.

What I learned from the article is that design smells serve as early warning signs. For example, if a method is too long or complex, it may indicate that it’s doing too much and should be broken down into smaller, more manageable pieces. This insight has made me reflect on my past coding experiences, particularly a group project where we rushed to implement features without thoroughly reviewing our code. The result was a project that became difficult to manage and understand. I realized that by overlooking design smells, we inadvertently added technical debt to our project.

Moving forward, I plan to apply this knowledge in my coding practice by adopting a more mindful approach. I want to prioritize code quality and regularly check for design smells as part of my workflow. Implementing practices like peer code reviews and refactoring sessions will help ensure that my code remains clean and maintainable. I believe this proactive approach will not only enhance my skills but also contribute to a more positive team environment where everyone is encouraged to uphold coding standards.

In conclusion, understanding design smells and technical debt is vital for anyone starting in computer science. By paying attention to these indicators, we can write better, more maintainable code. I highly recommend reading Tom Smith’s article for a beginner-friendly introduction to these essential concepts.

Resource:
* Fowler, M. (n.d.). Technical Debt and Design Smells: A Practical Guide. Retrieved from Martin Fowler’s website.

* Smith, T. (n.d.). Understanding Technical Debt. Medium. Retrieved from Medium.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

Link to blog: https://developer.ibm.com/articles/an-introduction-to-uml/

To start off the new semester and new course, we’ve been learning, discussing, and practicing with UML diagrams, or Unified Modeling Language diagrams. These diagrams are great ways for software developers and companies to visualize the structure of programs, large or small. There are many different types of diagrams, and we’ve mainly covered Class Diagrams and Sequence diagrams. 

Although I am unsure about the popularity and usage of UML diagrams in professional environments, I believe they can be beneficial to the organization and cleanliness of a team’s code, for it is to be written after it has already been structured and designed. The article I chose today is one by Donald Bell on IBM, and it discusses a few types of UML diagrams with some background information on each.

Bell introduces a new topic to the audience as well as anyone should: with some background information. He states the creation of UML was to model computer applications and ensure that anyone who understands UML diagrams can efficiently, accurately, and productively contribute to the project. 

The first UML diagram covered is the Use-Case diagram. Such diagrams are utilized to help readers understand the interaction between the program and its users. There can be many Use-Case diagrams for one program, but they are more so used to highlight the essentials. Bell describes how to create this type of diagram so that it is easy to understand.

The second UML diagram covered is the Activity Diagram, which shows “the procedural flow of control between two or more class objects while processing an activity” (Bell). Bell believes the best-case scenario for this type of diagram is for more business-oriented visualizations, such as how a company wants to operate at a higher level. These types of diagrams are not as technical as other diagrams which makes it easier to understand for non-programmers (Bell).

The last UML diagram Bell covers is the Deployment Diagram, which shows the physical representation of a software system. This would mean user computers, databases, websites, etc.

I selected this article because it covers a few UML diagrams that we haven’t discussed in class, and it is important for software developers to have some UML proficiency.  This would be a beneficial skill to have at a new job, so you might understand the codebase faster. IBM is also a very credible company in the software industry which is why I chose an article from their website.

The content of the resource was presented in an understandable way for someone with a little bit of software knowledge. I enjoyed learning about the background of UML and its creation, along with the three types of UML diagrams that were listed and described. I hope to use such knowledge at a new job that may use UML diagrams so I could provide more productivity in a shorter time rather than taking too much time trying to understand the codebase.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

In this post, I will be exploring the concept of inheritance in object-oriented programming. Inheritance is one of the core principles of OOP that allows a new class to inherit properties and behaviors from an existing class. The largest benefit of inheritance, in my opinion, is the ability to eliminate unnecessary (or otherwise necessary) repetition in the code. This week, we discussed design smells, and excessive repetition is one that can make code incredibly tedious to read and maintain, and it is one that can be eliminated or minimized by proper use of inheritance. The blog post I will be referencing this week can be found here, and it provides a very detailed example of inheritance as well as some further explanation of vocabulary and more advanced concepts that we have not yet covered in class, like upcasting and downcasting. I chose it because of these extra details it provides; most resources I found about inheritance provide the definition and a basic example, without going much further.

Let’s consider a practical example related to the one used in the blog post. Imagine you’re developing a software application for a zoo. You might have a base class called Animal that includes properties like name, age, and methods such as makeSound(). From this Animal class, you could create specific subclasses like Lion and Elephant. Each of these subclasses would inherit the properties and methods from Animal, allowing you to easily manage common functionality while still being able to define unique behaviors for each animal.

To expand on some of the details provided in the blog post, we could also create an instance mufasa of the Lion class and assign it to some Animal a1 = mufasa;. This would be allowed as upcasting, since Lion extends Animal. We could also then downcast a1 back into an instance of the Lion class, because at runtime, a1 will actually be a Lion instance.

Again, the main advantage of inheritance is its ability to promote code reuse. Instead of duplicating code across multiple classes, you can simply extend an existing class. For instance, if you needed each animal to have a method eat() that does the same thing for any animal, you could just implement it to the Animal class instead, saving time and space and keeping your code cleaner. The elegance of inheritance lies in its ability to create a hierarchy of classes. In our zoo example, you could further extend the Elephant class to create subclasses for different species of elephant, each with its own unique features, all while retaining the common behaviors defined in Elephant. The real world is full of hierarchies, and understanding how we can mirror those relationships programmatically when we want to represent or implement them in our code is a critical skill to have for an object oriented programmer.

From the blog CS@Worcester – Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

In this post, I will be discussing some basic concepts about abstraction in object-oriented programming. The resource I reference can be found here. I chose this topic because in the first few group activities, I was made aware that I had forgotten some of the key differences between kinds of abstraction (at least in Java), such as the difference between an abstract class and an interface. Though we reviewed these differences in class, I wanted to continue to find specific examples that would allow me to better understand the concept. Abu’s blog post briefly explains what abstraction in object-oriented programming is, some of its benefits/purposes, and some elementary examples of how to implement (no pun intended) abstract classes and interfaces.

The largest point of note I want to discuss is the benefit of modularity when abstraction is implemented. I recently finished up a personal coding project, in which modular development was a necessity. The project involved a central framework capable of ingesting a very specific kind of data from different websites, but each of the websites had a different way of providing that data. The most efficient answer I could think of was to make the central framework independent of the websites themselves, and to make it deal only with the data after it was obtained. I then created a module for each website that held the data, and implemented whatever logic I needed to in order to get the data and pass it to the central framework. I used Python for this project, but in hindsight, I may have been better suited to implement an object-oriented programming language like Java. Each module could have been a concrete class that extends some abstract class Parser, as each of my parser modules in my Python project used the same methods anyways. Each module had a get_url_and_interactions() function, a get_parse_function() function, and an stm() function (we can leave that abstract for now). It would have been very simple to use an object-oriented programming language, as I could have abstracted what it means to be a parser.

Now, this worked fine; since I was the only developer on the project, and had full visibility over all of the code, I didn’t need to check if a module implemented, for example, the get_url_and_interactions() function. I knew that it did. Moving forward, if I were coding more collaboratively with anyone else, or even if I just wanted to code according to some better practices moving forward, I could have used abstraction to standardize the parsers to ensure they all implemented certain methods or functions.

Though a little cliche, I do think it is very nice and elegant that the same thing can be accomplished in so many different ways. I think it is a good metaphor for most problems worth solving.

From the blog CS@Worcester – Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.