Object Oriented Programming

Hello everyone,

This week’s blog topic will be about Object Oriented Programming. I chose this topic as it is a fundamental knowledge that every programmer should know and this blog does an amazing job at explaining to new programmers while also giving good advice for experienced developers. I would say I am in the middle ground of that spectrum so this was the perfect resource for me to strengthen my understanding of Object Oriented Programming and its concepts.  

The author starts the blog by first explaining and introducing Object Oriented Programming to readers who are not familiar with it and he also lists the topics that this blog will cover giving you a great idea of the structure of the blog and also what is he going over. He explains how Object Oriented Programming revolves around two key building blocks which are classes and objects. He then shows how they work together when writing code. This is another thing that I like about this blog is that he often explains something and provides images and examples to simply it even more, thus making it easier to understand. What was a nice addition to this blog was the section where he started talking about the origin of Object Oriented Programming. This shows us how it was not created overnight, but it took years of hard work and dedication to create sucha  great innaviation. Knowing the context of how it started it also makes me appreciate the significance that OOP has. Another good point that I have to give to the author is how he compared it to procedural programming. It is kinda hard to understand why certain approaches are picked and by giving us this comparison between the two it makes it a lot easier when to use OOP. My favorite section was definitely where he talked about the four pillars of Object Oriented Programming which were inheritance, encapsulation, polymorphism, and abstraction. The explanation for each one of them were concise, and meaningful examples were provide clarifying any questions that readers may have had. The author also gives great analogies and I appreciate this a lot as it makes understanding the concepts a lot easier. My favorite example of this is when he was going over Abstraction, “Abstraction is like a laptop’s user interface. When you use a laptop, you interact with the interface (e.g., the keyboard, trackpad, and screen) without needing to know about the underlying hardware (e.g., the Processor, RAM, and Hard Disk).” 

In conclusion this blog turned out to be very beneficial for me, and I hope the same for whoever is reading this. His blog was very informative without being overwhelming and this allowed me to strengthen my foundation of Object Oriented Programming

Source:
https://www.designgurus.io/blog/object-oriented-programming-oop

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

Pros and Cons of Java

I found an article that discusses the pros and cons of Java in 2025. This caught my attention because Java is the language I have used in most of my classes. Object-oriented programming is also what we are discussing in CS-343. Java seems to be pretty versatile, and is fairly straight forward. I was interested to see in more depth what it has to offer and what it might not be so good with.

The article begins with an overview of Java as a whole. It discusses Java’s wide usage for a variety of different projects and its user friendly features that make it so widely liked. It quickly goes into the benefits of using Java. The author lists four main pros for the language: a straightforward learning process, object-oriented programming, heightened security, and platform independence. It is also mentioned how its simplicity makes it perfect for both beginners and more experienced programmers. For each main pro, the article goes into deeper detail to explain further what these benefits really mean for Java. Some interesting points in these explanations were the security features and the use of JVM (Java Virtual Machine). However, there are also the cons that come with it. The main cons listed here were performance constraints, licensing expenses, and GUI development complications. Similarly to the pros, these cons are then explained in more depth. The article’s last main section gives examples of ideal use cases for Java and some that are not so ideal. Web applications, mobile app, cloud computing and big data projects were listed as ideal use cases, where complex desktop GUI’s and alternative languages being more fitting for certain tasks were listed as times you may not want to use Java.

I found this article to be fairly interesting. Java is a language that I already knew a decent amount about, but it was interesting to learn more about it. As we learn more about Java and object-oriented programming, it is nice to know the benefits and what its strengths are. I also found it interesting that big data projects were listed as something Java works well with. Typically, R and Python are the languages most associated with data, but tools like Hadoop make it fitting for processing large amounts of data which may not be obvious to someone new to the language. Overall, it seems like Java has many benefits, and the cons seem to be minimal. I look forward to learning more about Java as I continue to use it!

https://www.netguru.com/blog/java-pros-and-cons

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

REST APIs and Data

I decided to dive further into what REST APIs really are, and how they are used, as they now appear both in my course syllabus, and as a possible solution for progressing my own internship work.

While searching for information, I came across a blog post titled, What Is a REST API? Examples, Uses, and Challenges (https://blog.postman.com/rest-api-examples/). This post goes over what REST APIs are, how they are used, and what you can do with them.

The post also included a YouTube video, demonstrating setting up a REST API, and this part I found particularly interesting. I saw the person in the video utilize GET, and a command to filter for a specific Id associated with the data they wish to retrieve. This rings a bell for me, as I index database instances with an Id very often at my workplace. As I now need to export some of the data produced by my workplace software, in particular by fetching and filtering various attributes such as by Id, for other platforms, utilizing a REST API to aid me in transferring data could provide the data bridge I need to produce analytics from the software I’ve created.

The post delves into the history of the APIs as well, and talks about how REST can be more efficient than SOAP, and how big names like Facebook and Instagram utilized, and still do utilize, REST APIs to transfer data for their users. I was also intrigued to find out that the Amazon S3 storage buckets also utilize REST APIs, and I’ve worked with them in data courses already.

Some of the benefits of using REST APIs include scalability, flexibility, portability, light-weight, and language/platform independence.

The challenges that need to be accounted for when using REST APIs include ensuring endpoint consistency, keeping the URL structures uniform across teams, versioning, maintaining old APIs while introducing new ones, authentication complexity, including basic or bearer tokens, API keys, or OAuth tokens and passwords, as well as accounting for and preventing security risks, such as through encryption, or protecting keys.

Some best practices recommended by the poster include using correct HTTP status codes, 200, 400, 404, etc, returning informative error messages, making sure to secure your APIs via encryption, input validation, and role-based access. Documentation is also naturally very helpful for reminding yourself what you’ve done or made, and share that information with your team or other coders.

I hope to successfully implement a REST API in the near future!

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

Blog Post 1

Since we’ve been going over GitHub and how and why we use it in class, I decided to pick an article right from the source. In the blogpost How we use GitHub to be more productive, collaborative, and secure, Mike Hanley describes how the staff at GitHub use GitHub themselves as well as how they’ve made new additions with developers in mind. A neat thing I thought as developers themselves working on GitHub I’m sure they thought “wouldn’t it be nice if…” then realizing “oh wait we can just add that”. One of those features that the blog mentions is the “new code search and code view”, which allows for a more quick and easy way to sift through multiple lines of code.

Another point in the blog was about productivity and under that Codespaces. As we had used Codespaces during the GitKit Chapters, it felt well integrated, so I was pretty surprised to find out that it was something that they had only recently implemented and started using (they started using Codespaces in 2021 and the article was written in 2022). Based on the article, this allowed what once took 45 minutes on local hardware to 60 seconds on much faster hardware then most would have on hand. This alone struck me as a sort of equalizer, allowing for more inclusivity in the fact that you don’t need to spend a lot of money on hardware to be on the same “playing field” as other developers.

The last main point in the blog goes into GitHub’s stance on security, which I guess isn’t to surprising as Mike Hanley’s current role in GitHub as well as his previous role was being in charge of security. Anyways, too often is cybersecurity put on the backburner until an inevitable data breach occurs, then it’s all “we value our customers security and privacy” and “security is our number one priority”. Mr. Hanley also seems to see things the same way, as he mentions how they were “still pleading with organizations to implement multi-factor authentication…”, something I consider to be pretty bare-minimum in terms of keeping ones accounts safe. Due to this stance on security I was glad to see that GitHub actually enforces multi-factor authentication with security keys. Another method of keeping things secure is their use of CodeQL. According to the article, in the same open-source spirit that GitHub was founded with, CodeQL queries are also open-source where either GitHub or other developers can share vulnerability patterns. This allows for not just “one set of eyes” to pinpoint possible exploits but instead the entire community.

Reading this article has given me a better sense of how the tools and practices we’re learning now actually look in a professional environment. On top of that seeing GitHub’s own team use features like code search, Codespaces, and built-in security tools shows how even though it feels like we’re leagues apart we’re still on even footing.

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

Why My Homework on Forking and Pull Requests is Actually Career Prep

For the past few weeks in my Software Process Management class, we’ve been deep in the Runestone GitKit modules. At first, it felt like we were just going through the motions: fork a repo, create a branch, make a commit, open a pull request. It was a bit mechanical. But once we got to the later modules on syncing with an upstream repository and dealing with merge conflicts, the bigger picture started to click. I realized I was learning a real-world workflow, not just homework exercises. To get a better understanding of why this process is so important, I spent time on the Atlassian “Source Code Management” tutorials. I wanted to see how the steps from our class connected to the way professional developers actually work.

The Atlassian resource was the perfect companion to our GitKit labs. It framed everything we were doing in terms of a “Forking Workflow,” which is massively used in open-source projects and many companies. It explained that forking isn’t just a step; it’s a collaboration model. It gives you your own server-side copy (your “origin”) to experiment freely without threatening the stability of the main project (the “upstream”). This directly clarified the purpose of the two remote repositories we set up in GitKit. The tutorials also gave a crystal-clear explanation of pull requests, describing them not just as a way to merge code, but as a formal mechanism for discussion, code review, and ensuring quality before changes are integrated.

This connection between class and the professional world was a huge lightbulb moment for me. In Module 3, we learned the mechanics of git branchgit push origin feature-branch, and creating a PR. Atlassian explained the why: this process isolates your work, keeps the main branch stable, and makes every change transparent and reviewable. The steps we practiced for syncing with upstream in Module 4—git fetch upstream and merging changes—are exactly how real developers keep their feature branches up-to-date and avoid nasty merge conflicts. Even the .gitignore file, which we learned about, is a professional standard for keeping junk files out of the shared codebase.

Understanding this workflow is no longer just about passing the class; it feels like essential career prep. When I look at internship job descriptions, “experience with Git and GitHub” is a given. Now I know that means more than just making commits. It means understanding how to collaborate using forks, branches, and pull requests. It means knowing how to resolve a merge conflict gracefully instead of panicking. The hands-on practice from GitKit, combined with the conceptual framework from the Atlassian tutorials, has given me the confidence to say I understand a standard professional development workflow. I’m not just memorizing commands for an exam; I’m building a foundational skill I’ll use every day in my future career.

Resource Link: Atlassian Git Tutorials – Source Code Management

From the blog CS@Worcester – DoaaTime by Doaa Mutar and used with permission of the author. All other rights reserved by the author.

Quarter 1 Blog Post for CS-348

My chosen article for this blog post is this article from the National Institutes of Health.
https://pmc.ncbi.nlm.nih.gov/articles/PMC4945047/

While at face value an article from the NIH might seem completely off topic from our class and what we’re learning currently, this article is actually all about Github. The article is centered around the Bioinformatics industry, and how a big problem with it has always been sorting, storing and accessing biological data and information credibly and easily. The introduction of the article gives a solid run down of what Github is and its relation to Git, while the meat of the article surrounds 10 “rules” to follow while using Github.

I chose this article for my first blog post of the semester because it seemed ironically fitting for the current topic of Git in our class for being an article published by the NIH. But I also chose it because it heavily relates to our sort of beginners guided usage of Git and Github that we’ve been doing. The rules given by the article all seem like really helpful guidelines for anyone new to Github like I am. I’ve always wanted to use it for personal projects and such but it’s always seemed like a daunting platform. Granted our class has torn down a large portion of the wall getting in my way from using Github personally but I do also really like these guidelines given by the article. For example, their rule 1, using Github to track your projects progress and changes make to the project, that taking advantage of its own system for doing so is a massive help from tracking progress on ones own, especially when working with a whole team of people on one project.

Out of all these rules though, I really do think rule 5 and 7 are the ones I reflect on most, I’ll admit I’m sometimes lazy and sometimes forgetful. Sometimes I do skip a test on a project. But that’s where I realize I can use that to my advantage with rule 5 of this article. It talks about using Github’s web hooks to test your code, find bugs and detect logic errors every time you push your code. Personally I don’t think it’s advantage I would pass up and don’t want to pass up in the future of using Github for class and myself.

As for rule 7, I know it seems silly but I don’t really like to discuss or bring up problems or issues I have with my projects that I’m working on. It’s always seemed like such a hassle, and whenever I did discuss the issues I’m having, its usually over discord to multiple people at once making responses to each person a mess of trying to keep up and take everything into consideration. So genuinely I do think the issues section of a project will become a very powerful tool for me. It didn’t really hit me in class because actively trying to use it as someone identifying and fixing problems for a project that wasn’t my own felt discouraging, not sure why, but I didn’t really think about from the project lead perspective. I do think a tab dedicated to finding, analyzing and fixing issues will be extremely helpful to me.

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

Behavioral Design Patterns

Design patterns provide many benefits when it comes to coding and software development. They are essentially blueprints to help guide and solve problems through the process of designing software. While there are three types of design patterns, the one I will be focusing on here is behavioral patterns. Behavioral design patterns mostly focus on the assignment of responsibilities between objects and help with communications between those objects.

There are many different types of behavioral design patterns. Some of these patterns include:

  • Chain pf Responsibility
  • Command
  • Interpreter
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template Method
  • Visitor

All of these of different uses along with different pros and cons. For example, command patterns turns request into stand-alone objects called a command. This pattern allows you to capture each component of a request allowing the undo and redo of operations. However, this may cause overcomplications of code because of the layer between senders and receivers. Design patterns are easily customizable to help you approach any problem and provide solutions to many problems you may be having within development.

We’ve begun to touch on design patterns within class using UML diagrams and showing different ways to solve problems. We used the example of a duck class and different types of ducks. More duck types were added that were unusual types of ducks that had different behavior types. We used a couple different methods to help make the program work including overriding, interfaces, and behavior types. Each of these solutions had different pros and cons depending on what the user wanted out of the program.

All-in-all, each different type of design pattern has their own uses and downfalls. When working with design patterns, understand what a client or users want out of a program is key to really determining what design pattern to actually use.

From the blog CS@Worcester – Works for Me by Seth Boudreau and used with permission of the author. All other rights reserved by the author.

The Uml digram

 

The blog
post, UML Diagrams – Everything You Need to Know to Improve Team Collaboration,
provides a clear explanation of Unified Modeling Language(UML) Diagram, its
usage and types ending with how it helps to visualize the project. Starting
off, the blog covers the usage of UML diagrams, continuing with its key uses,
forward design, modeling before coding to plan a system, and backward design, modeling
after coding to document a finished system. Also, it covers the thirteen UML diagram
types and what each type shows and describes what each type represents and how
it contributes to visualizing processes effectively.

I chose this
article as it summarizes clearly what the UML diagram, its usage, how the UML
diagram can be used to collaborate with other teammates. First was that since
the class, I felt that I needed to understand UML diagrams better as I still
did not get what use does it has. The fact that it emphasizes UML diagram as
white board for building and analyzing the system the team gave me some reason
for understanding more about UML diagram. Not only that, but the article also
clearly goes in-depth about the UML diagram that goes way in depth compared to
the course of behavioral and structural diagrams and how they can fit together
in real-world workflows. Overall, this blog clarified how UML diagrams support
collaboration as a visual tools to help team members to see and discuss system
structures and behaviors. It made me view UML not just as an academic
requirement but as a practical communication tool that can strengthen teamwork
in future software projects.

           After
looking at the article and learning more about UML diagram, I felt like even
though it might not be perfect, that I might have to use it for future use. When
coding I have something on my mind to create, but when trying to explain it or comment
on the structure of the code. Sometimes others don’t understand or sometimes I cannot
remember why I did that later. Not only that, but the rough draft of the
structure can also be used when talking with other teammates because I cannot
do everything by myself and we need to see the same picture, and I think UML diagram
will be the virtual whiteboard for it.  

 

https://www.bluescape.com/resource-library/uml-diagrams-everything-you-need-to-know-to-improve-team-collaboration

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

The Uml digram

 

The blog
post, UML Diagrams – Everything You Need to Know to Improve Team Collaboration,
provides a clear explanation of Unified Modeling Language(UML) Diagram, its
usage and types ending with how it helps to visualize the project. Starting
off, the blog covers the usage of UML diagrams, continuing with its key uses,
forward design, modeling before coding to plan a system, and backward design, modeling
after coding to document a finished system. Also, it covers the thirteen UML diagram
types and what each type shows and describes what each type represents and how
it contributes to visualizing processes effectively.

I chose this
article as it summarizes clearly what the UML diagram, its usage, how the UML
diagram can be used to collaborate with other teammates. First was that since
the class, I felt that I needed to understand UML diagrams better as I still
did not get what use does it has. The fact that it emphasizes UML diagram as
white board for building and analyzing the system the team gave me some reason
for understanding more about UML diagram. Not only that, but the article also
clearly goes in-depth about the UML diagram that goes way in depth compared to
the course of behavioral and structural diagrams and how they can fit together
in real-world workflows. Overall, this blog clarified how UML diagrams support
collaboration as a visual tools to help team members to see and discuss system
structures and behaviors. It made me view UML not just as an academic
requirement but as a practical communication tool that can strengthen teamwork
in future software projects.

           After
looking at the article and learning more about UML diagram, I felt like even
though it might not be perfect, that I might have to use it for future use. When
coding I have something on my mind to create, but when trying to explain it or comment
on the structure of the code. Sometimes others don’t understand or sometimes I cannot
remember why I did that later. Not only that, but the rough draft of the
structure can also be used when talking with other teammates because I cannot
do everything by myself and we need to see the same picture, and I think UML diagram
will be the virtual whiteboard for it.  

 

https://www.bluescape.com/resource-library/uml-diagrams-everything-you-need-to-know-to-improve-team-collaboration

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

The Uml digram

 

The blog
post, UML Diagrams – Everything You Need to Know to Improve Team Collaboration,
provides a clear explanation of Unified Modeling Language(UML) Diagram, its
usage and types ending with how it helps to visualize the project. Starting
off, the blog covers the usage of UML diagrams, continuing with its key uses,
forward design, modeling before coding to plan a system, and backward design, modeling
after coding to document a finished system. Also, it covers the thirteen UML diagram
types and what each type shows and describes what each type represents and how
it contributes to visualizing processes effectively.

I chose this
article as it summarizes clearly what the UML diagram, its usage, how the UML
diagram can be used to collaborate with other teammates. First was that since
the class, I felt that I needed to understand UML diagrams better as I still
did not get what use does it has. The fact that it emphasizes UML diagram as
white board for building and analyzing the system the team gave me some reason
for understanding more about UML diagram. Not only that, but the article also
clearly goes in-depth about the UML diagram that goes way in depth compared to
the course of behavioral and structural diagrams and how they can fit together
in real-world workflows. Overall, this blog clarified how UML diagrams support
collaboration as a visual tools to help team members to see and discuss system
structures and behaviors. It made me view UML not just as an academic
requirement but as a practical communication tool that can strengthen teamwork
in future software projects.

           After
looking at the article and learning more about UML diagram, I felt like even
though it might not be perfect, that I might have to use it for future use. When
coding I have something on my mind to create, but when trying to explain it or comment
on the structure of the code. Sometimes others don’t understand or sometimes I cannot
remember why I did that later. Not only that, but the rough draft of the
structure can also be used when talking with other teammates because I cannot
do everything by myself and we need to see the same picture, and I think UML diagram
will be the virtual whiteboard for it.  

 

https://www.bluescape.com/resource-library/uml-diagrams-everything-you-need-to-know-to-improve-team-collaboration

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.