Category Archives: CS-343

Encapsulation | One of the Four Pillars of Object-Oriented Programming

There are four pillars in Object-Oriented Programming (OOP), one of which is ‘encapsulation’, which refers to the good practice of hiding the inner works of an object and its implementation details, where access is only possible through public methods. As one of the pillars of OOP, it is beneficial to me as a learning programmer to understand about the purpose of ‘encapsulation’ and how it can be effectively applied.

I realized during one of my classes — when we were reviewing these four pillars — that while I knew the principle by name, I had never learned encapsulation in detail nor how to best implement it into my code. Looking back at code I had written in the past, it was clear that I did not always follow this practice (i.e. using dangerous global variables as attributes in my objects).

The blog “The four pillars of object-oriented programming — part 1 — encapsulation”, written by Bas Dijkstra, helped better illustrate for me what encapsulation is supposed to do.

Firstly, encapsulation is all about making attributes private. By doing so, an object’s attribute is protected from being accidentally — or maliciously — altered. Instead of accessing the attribute directly, the value can and should be returned through a public method within the object, essentially making the attribute ‘read-only’.

By doing this, a programmer gains more security and control over the code, reducing the amount of unwanted behavior in the system as a whole.

Secondly, good encapsulation is the product of good design. In another blog, “Encapsulation in Functional Programming”, by Mark Seemann, which I found by looking deeper into the strategies of implementing encapsulation into code, talks about creating a ‘contract’ for each class. The contract outline three properties of a class:

  1. Preconditions — what are the minimal requirements for the object to function?
  2. Invariants — which attributes of the object do not/cannot change?
  3. Post-conditions — what are the boundaries/rules of the object after it is created?

Though the article focuses more heavily on encapsulation for functional programming, the design strategy also benefits OOP. Having these properties outlined in the contract of a class helps the programmer understand not only what needs to be encapsulated, but also how it can be encapsulated.

In addition, because of the nature of encapsulation and the amount of control it provides a programmer over the code, testing for such classes that follow the principle becomes much simpler and easier to do .

While a simple principle, encapsulation is a powerful and practical strategy that makes code secure and easy to manage by hiding the inner works of a class behind public methods.

Sources:

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

about plant uml

One of the reason I like PlantUML is that it forces me to design leveraging a common and standardized framework. It adds a level of formality to the process, which ensures I am conceptualizing my architecture correctly and communicating it clearly with concepts that everyone agrees on. It is a value I learned from the Army: we practices a standard way of making decisions and writing orders. By leveraging a standard modeling language I am not reinventing the wheel every time.

From the blog CS@Worcester – Andres Ovalles by ergonutt and used with permission of the author. All other rights reserved by the author.

An Introduction to REST APIs: Simplifying Communication in the Digital World (Week-5)

In today’s interconnected digital landscape, communication between various software applications is essential. Whether you’re ordering a pizza online, checking the weather on your smartphone, or browsing your favorite social media platform, chances are you’re interacting with a REST API (Representational State Transfer API) without even realizing it. In this blog post, we’ll delve into the world of REST APIs, exploring what they are, how they work, and why they are so crucial in the modern web ecosystem.

What is a REST API?

At its core, a REST API is a set of rules and conventions for building and interacting with web services. REST, which stands for Representational State Transfer, is an architectural style that was introduced by Roy Fielding in his doctoral dissertation in 2000. RESTful APIs adhere to these principles, making them straightforward and efficient for developers to work with.

A REST API exposes a collection of resources, which can be thought of as objects or data entities, over the internet. Each resource is identified by a unique URL, and clients (e.g., web browsers, mobile apps, or other software systems) can use HTTP requests to perform various operations on these resources. The four primary HTTP methods used in RESTful APIs are:

  1. GET: Retrieve data from the server.
  2. POST: Create a new resource on the server.
  3. PUT: Update an existing resource on the server.
  4. DELETE: Remove a resource from the server.

REST APIs rely on a stateless client-server architecture, meaning that each request from a client to a server must contain all the information required to understand and process the request. This simplicity and separation of concerns are some of the reasons behind the widespread adoption of RESTful APIs.

Key Concepts of REST APIs

To better understand REST APIs, let’s explore some key concepts:

1. Resources

Resources are the fundamental entities that a REST API exposes. These can be objects, data, or services, and they are identified by unique URLs. For example, in a blog application, resources could include articles, authors, and comments.

2. Endpoints

Endpoints are specific URLs that correspond to individual resources or collections of resources. For instance, a blog API might have endpoints like /articles, /articles/{id}, and /authors.

3. HTTP Methods

HTTP methods (GET, POST, PUT, DELETE) define the actions that can be performed on resources. For example, you might use a GET request to retrieve a list of articles (GET /articles), a POST request to create a new article (POST /articles), or a DELETE request to remove an article (DELETE /articles/{id}).

4. Representations

Resources can have multiple representations, such as JSON, XML, or HTML, depending on the client’s needs. Clients specify their desired representation in the HTTP request’s Accept header.

5. Statelessness

REST APIs are stateless, meaning that each request from a client to a server must contain all the information needed to understand and process the request. The server doesn’t store information about the client’s state between requests.

Why Are REST APIs Important?

REST APIs play a crucial role in modern web and application development for several reasons:

  1. Simplicity: RESTful APIs are easy to understand and use due to their simplicity and adherence to HTTP standards.
  2. Scalability: They are highly scalable, making it possible to serve a large number of clients without sacrificing performance.
  3. Interoperability: REST APIs can be consumed by a wide range of clients, including web browsers, mobile apps, and other software systems, making them highly interoperable.
  4. Statelessness: Stateless design simplifies server maintenance and scaling while also improving reliability and fault tolerance.
  5. Flexibility: REST APIs are not tied to a specific programming language or technology, allowing developers to choose the tools and frameworks that best suit their needs.

Conclusion

In today’s digital age, REST APIs have become the backbone of web and application development, enabling seamless communication between various software components. Understanding the fundamentals of REST, such as resources, endpoints, HTTP methods, and statelessness, is essential for any developer looking to build robust and efficient web services. As you continue your journey into the world of software development, REST APIs will undoubtedly play a vital role in your toolkit, facilitating the exchange of data and functionality across the vast landscape of the internet.

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

The Art of Code Refactoring

Since we have been discussing refactoring in class recently, it got me interested in finding out more about what makes refactoring… well “refactoring”. I found this interesting article “Refactoring vs. Defactoring” by Nicolas Carlo, a French-Canadian Software Engineer, which describes the difference between refactoring and debugging while also introducing the idea of “defactoring”.

The article starts with the definition of refactoring, which according to Martin Fowler, is “a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior“. In simpler terms, refactoring is all about tidying up the interior of a program while keeping the exterior the same.

Nicolas is clear however that fixing a bug, adding features, or changing features is not refactoring but points out the importance of refactoring code before altering the functionality of a program.

Nicolas states that in his experience things that can help with solidifying this distinction are to, start doing distinct commits separating both refactoring and change commits, make commits more frequently, prefix commit messages with R or C to specify the change(s) made, and learn how to use automated refactoring to improve the health of one’s code.

Nicolas also explains by following these practices he feels as if his work has become much safer and simpler than before. With his newfound awareness, he feels as if he can put the best quality into his work. He also gives a brief rundown of how thinking of Refactoring and Changes as two hats you wear when programming can also help increase developer awareness.

While we discussed refactoring, I thought it was interesting how Nicolas framed defactoring as an opposing process to refactoring in the title of the article but I came to find out it is not that at all. Defactoring is described by Nicolas as “cognitive refactoring” which is done by making the code less abstract in places where abstraction is no longer required.

He says that when working with legacy code, he notes some items such as temporary variables that are just not needed in places where they were necessary in the past. By altering code to remove such variables, Nicolas signifies this process as “defactoring” since it removes old abstractions that just are not needed anymore.

After reading this article I feel as if I have a stronger newfound understanding of the importance of separating refactoring from normal changes since it can make a dramatic difference in a program’s overall transparency. In my work alone, I have realized the importance of taking on one aspect at a time improves the cohesion and efficacy of the final product, but I never really thought about the importance of distinguishing changes and refactoring. Trying to be aware of this in the future will help me create the best version of my work possible by ensuring I have a more robust knowledge of a program’s behavior and added transparency of said program through my code alone.

Article Link: https://understandlegacycode.com/blog/refactoring-and-defactoring/

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.

Week 5 – A bit late but we’re getting there…

So it’s been a hot second since I set this blog up, and I apologize for the silence. Been busy focusing on homework and figuring out my work situation.

But with that aside, I just wanna talk about my past with GitHub and repositories before this class. I’ve actually used GitHub many times before, because I collaborate with a modding community. We focus on modding a video game known as Luxor, a classic PC game from the 2000s that I’ll share gameplay of below.

As for what a mod of this game entails, here’s an example of one of my favorites from recent, Hollow, made by my friend Dommo:

A lot of effort has been put into these mods, and I’ve contributed to a lot of them, and even made my own. I have no recordings of it, unfortunately, but I swear it exists, haha.

Though as of recent, we’ve been discussing how to properly archive mods. For the longest time, we’ve been using our Discord server for modding to store them, but that poses an issue: Many people might not have access to Discord due to their countries, operating systems, or various other reasons.

This led to some people moving over to GitHub, which was one of my first times learning how it actually properly worked. Before this, I simply downloaded stuff from it, but I learned the basics of how to push and pull repositories and have a local clone to work on and collaborate with multiple people.

Currently one of the biggest projects being developed using GitHub is OpenSMCE (https://github.com/jakubg1/OpenSMCE) which is a game engine being built off of the Love2D engine to allow us to have an opensource engine to work off of for our mods, as opposed to the limited and clunky engine we use currently with the original game.

The reason I discuss this is actually because the new information I’m learning in these classes is inspiring me to help work on and learn the process of being in a team working on a software/engine development with Jakub, the developer of OpenSMCE. This has been an application I’ve been very excited to see have a full release, and being able to say I contributed to it and helped it reach that state would be amazing.

Hopefully as the semester goes on, with the lessons I’m learning about how to create an application as well as work in a collaborative environment, I’ll end up contributing to this project, and maybe I can even use this blog as a way to discuss the ongoing developments and issues we’ve been facing with the development of OpenSMCE. It would be interesting, and I will probably reach out to Jakub within the next week about it.

Anyways, that’s all I have for this week, until next time!

-Tempura

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Data Redundancy – Relevance in Software Systems and Websites

In today’s world, businesses, organizations, and other entities that software and web developers consider “clients” heavily rely on being able to efficiently collect, access, and otherwise manage data for their day-to-day operations. For many, losing access to databases or similar outages hinders their ability to continue operations. In Data Redundancy: Meaning and Importance, author Charlotte White discusses data redundancy and some basic strategies and implementations to address these vulnerabilities.

Data Redundancy goes beyond simply having backups of existing data (although they’re an important component), it’s a proactive plan to prevent data loss and maintain smooth operations in the case of a server shutdown, hardware malfunction, or other major disruptive issue. It’s crucial for ensuring the continuity of business operations as website downtime often leads to financial losses especially for new websites or those with low traffic. Outages can also impact search engine rankings, as uptime is a factor commonly considered by search algorithms. Furthermore, failure to do so resulting in data loss can result in crashes/issues in other systems, loss of customer information, business details, and other critical and/or confidential information which is essential for an organization’s success and reputation.

How Redundancy Works: Effective redundancy designs reduce dependency on any single copy of data or data center. They commonly implement a 3-2-1 rule of backups, which means having three copies of data in two different locations, one of which is offline storage. Redundancy strategies should also consider factors like hardware redundancy; many servers use hard disk drives (HDDs) to store data which can fail due to simple wear and tear. Some hosting companies use RAID (Redundant Array of Independent Disks) and un-RAID solutions to mirror data from HDDs to other storage devices, minimizing the impact of HDD failures.

Recently in CS343, we’ve been looking at software architectures and strategies for organizing systems that could be realistically implemented to address clients’ needs. In particular, we’ve been considering the differences and strengths/weaknesses between a simpler architecture such as the Monolith versus a more complex architecture such as the MicroServices model, with several intercommunicating systems.

Most of the scenarios we discussed involved the ease of pushing out updates, but I was left wondering about the repercussions and ways to manage the possibility and reality of a database or system going totally offline. For businesses involved in eCommerce, uptime is money in terms of sales as well as maintaining search engine optimization. Given how damaging a disruption like this could be, data redundancy plans are an important consideration when planning and setting up a website or system. Understanding the value of D.R. and how they are implemented is an asset in planning and designing software systems and projects, and generally beneficial for computer science students and professionals.

Source:
1. Data Redundancy Meaning and Importance: A Complete Guide | ResellerClub India Blog

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Week of October 9, 2023

https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith

Since learning about different software architecture styles like the monolithic architecture, the client-server architecture and the microservices architecture, I’ve been curious how large-scale applications transition from one architecture to another as the project grows in scale. I found this blog post on the Atlassian website breaking down the differences between the monolithic architecture and the microservices architecture, as well as telling the story of Netflix’s innovative migration from a monolithic architecture to a microservices architecture.

The article begins with the example of Netflix’s transition between architectures. Netflix was growing rapidly by 2009 and needed to expand its software infrastructure to meet the massive demand. Before “microservices” as a term was in wide usage, Netflix was one of the first major companies to migrate to a microservices architecture, and in 2015 earned a JAX Special Jury award for its successful deployment. Netflix’s new architecture would model itself on DevOps, defined by Amazon as “the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity (https://aws.amazon.com/devops/what-is-devops/#:~:text=DevOps%20is%20the%20combination%20of,development%20and%20infrastructure%20management%20processes.)”.

Following the story of Netflix’s change in infrastructure model, the article continues with an explanation of the monolithic architecture style. The monolithic architecture is a traditional design, which is defined by the application being housed in a single self-contained server. This architecture is simple to understand and easy to use as a foundation for your application. The major drawback of the monolith, however, is the difficulty in updating the application. Making changes to the code base requires bringing the entire service offline. Monolith architectures are not scalable with the growth of the application either.

The microservices architecture addresses some of the disadvantages that come along with a monolith architecture. The application is divided into independent services each with their own databases and methods. With this architecture model, only the components of the application that require changes need to be taken down, leaving the other components of the application free to continue working.

One inherent barrier to using the microservices architecture is the expense of multiple machines to host the different microservices, as well as storage space for their accompanying databases. It may only be beneficial for an application to transition to a microservices model once it has reached a certain scale. Small to mid-size applications may be perfectly well served by monolith architectures for much less cost than hosting the application across a microservices architecture.

From the blog CS@Worcester – Michael's Programming Blog by mikesprogrammingblog and used with permission of the author. All other rights reserved by the author.

Exploring the Strategy Design Pattern in Software Development

I recently came across a fascinating article that I believe directly relates to our course material as it is the focus of our current Design Patterns Homework. In this blog post, I will provide a summary, share my reasons for selecting this resource, offer my personal insights, and discuss how this newfound knowledge can be applied to our future practice as software developers.

The resource I found is an article titled “A Beginner’s Guide to the Strategy Design Pattern,” available on the FreeCodeCamp website. This article serves as an introductory guide to the Strategy Design Pattern in software development. It outlines the pattern’s purpose, components, benefits, use cases, and best practices for implementation. The core idea of this pattern is to encapsulate a family of algorithms, making them interchangeable at runtime.

Why I Chose This Resource

I selected this resource because I was struggling with understanding the homework assignment and this article helped me better understand the strategy design pattern. Moreover, the article provides practical examples and clear explanations that make it accessible to beginners like myself.

Reflections on the Content

The article begins by explaining the core concept of the Strategy Design Pattern. It emphasizes the benefits of encapsulating algorithms into interchangeable strategies, including improved code flexibility, re-usability, and simplified testing. I found this concept to be highly relevant to our studies, as it promotes clean and maintainable code, a fundamental skill for any software developer.

The article discusses real-world use cases for the Strategy Design Pattern, such as sorting algorithms, validation rules, and payment processing. These examples helped me see the pattern’s practical application in various scenarios, and I can envision using it in my future projects.

Additionally, the article provides a step-by-step guide on how to implement the Strategy Design Pattern in Java, breaking down the process into clear, manageable steps. This hands-on approach was incredibly valuable as it demonstrated how to apply the theoretical knowledge in a real coding scenario much like the one seen in the Duck Simulator.

Application to Future Practice

Understanding the Strategy Design Pattern will undoubtedly benefit us in our future practice as software developers. Here’s how:

  1. Code Flexibility: By using this pattern, we can make our code more adaptable to changing requirements. It allows us to swap out different strategies at runtime, making our software systems more versatile.
  2. Re-usability: The Strategy Design Pattern promotes the re-usability of code. We can create a library of interchangeable strategies that can be applied to various projects, saving time and effort.
  3. Clean Code: Implementing this pattern encourages clean coding practices by separating concerns and reducing code complexity. This results in code that is easier to read, maintain, and debug.
  4. Testing: With strategies separated from the main object, testing becomes more straightforward. We can test each strategy in isolation, ensuring that it functions correctly.

Conclusion

In conclusion, the Strategy Design Pattern is a valuable tool in software development, and I believe this article provides a solid foundation for understanding and implementing it. As future software developers, mastering design patterns like this one will be essential for creating efficient, maintainable, and flexible code. I encourage you to read the article and explore this pattern further to enhance your skills in software development.

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.

learning concurrency

I’ve heard these terms a lot, concurrency and multithreading, but I never really bothered looking into what they actually do. All I’ve really known about these terms was that they make things run faster. I mostly associated multithreading with hyperthreading, I’ve known that CPUs can use multiple cores for the same application to speed up runtime and make games perform better, but I was always sort of confused about how some games have issues with actually taking advantage of modern high-end CPUs. Usually, this is fixed by some sort of modification, if it’s been written already. That being said, my association between the two is only really surface level.

Hyperthreading is really just related to the physical hardware, which makes it different from multithreading in programming. Instead, multithreading is a form of concurrency in which a program has multiple threads that can run simultaneously, with each thread having its own operations and processes that it executes. What this ultimately means is that within a program, multiple operations can be executed at the same time.

This really fascinates me coming from the perspective of only writing straightforward code. While I sort of knew intuitively that programs can probably do multiple tasks at the same time, I’ve only experienced this on the end-user side of things, rather than the individual writing the program. After looking into how threads work in Java on a BairesDev post regarding Java concurrency, I can really see how powerful of a tool concurrency can be for runtime efficiency. This post essentially goes over what concurrency is and the ‘basics’ of utilizing built-in multithreading functions in Java, along with the advantages and disadvantages that this design comes with.

Of course, it does seem like it takes a careful approach to make sure that the implementation of such a tool is actually beneficial to the project. Even with this relatively simple tutorial, I did find myself a little confused at some points, particularly at the point where Locks are introduced. Though this could be the effect of the hour at which I decided to start writing this blog post, it still stands to reason that the complexity of writing a multithreaded program may result in a more difficult development process, especially in debugging.

Regardless, I was truly fascinated by the subject matter and I’m really excited to be going over concurrency in our course (CS-343). This seems like a tool I would really like to use as I enjoy toying with logistics in video games and the like.

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

Minimizing Anti-Patterns

The article I chose for this week’s blog post is “What Is an Anti-Pattern?” by Andreas Schöngruber. I chose this article because it discusses what anti-patterns are, gives some examples of anti-patterns, and how to avoid them. I chose this article for this week’s blog because it fits well with the syllabus topic of anti-patterns. I found the section about recognizing and avoiding anti-patterns to be very helpful. This blog post will focus on the aforementioned section about recognizing and avoiding anti-patterns in your code.

I will first discuss the section of the article which discusses recognizing anti-patterns in your code. One method that the article mentions involves keeping an open mind and looking to others for feedback. “When identifying anti-patterns in our code or design, we must keep an open mind and question our assumptions. Sometimes, we may become attached to a solution that required a lot of time and effort, but there might be a better solution out there. To avoid this, it is helpful to seek feedback from others.” As this quote states, it is imperative not to be too attached to a process that you developed or are developing, especially if the time it takes to develop or implement this feature is more than the value that the feature is worth. Another important part of being able to mitigate the harm done by anti-patterns is knowing how to avoid them.

While being able to identify anti-patterns is incredibly important, it is also important that one knows how to prevent their occurrence in the first place. One method of doing so is by stepping back and looking at the greater picture of the project that you are working on. “When working on software projects, it is essential to be aware of common pitfalls that can lead to anti-patterns. One strategy to avoid these pitfalls is to take a step back and consider the larger context of the problem. Understanding the problem in its entirety will help in coming up with a good solution.” Instead of being hyper-focused on one part of a larger project, which could lead to anti-patterns arising in your code, its best to take a step back occasionally to make sure what you are working on is not falling into the traps of anti-patterns. Another method of preventing anti-patterns would be a divide-and-conquer approach to developing features. “Another strategy is to break down large problems into smaller pieces. Doing this can help avoid getting overwhelmed and make it easier to spot issues and inefficiencies.” Using this strategy can be very beneficial because it can allow you to see anti-patterns as they appear in your code.

Article: https://www.baeldung.com/cs/anti-patterns

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.