I chose the blog post, “People Don’t Understand OOP” by Sigma because it addresses recurring challenges in programming, specifically around OOP. Understanding how to improve my approach to OOP principles would help me write cleaner, more effective code that’s easier to maintain and adapt over time. Not following these concepts has led to messy code in previous years. Personally, I feel like I made a lot of these mistakes when I first started coding, however as more classes have gone by I have been able to break some of these bad habits. Unfortunately, there are times when I will make these mistakes when coding without thinking so that is what led me to choose this blog post, so I can learn how to not make these mistakes in the future.

The blog post  explores common misunderstandings surrounding Object-Oriented Programming (OOP). The author, Sigma,  argues that misconceptions often stem from oversimplified metaphors and an incomplete grasp of fundamental principles like encapsulation and abstraction. Frequent mistakes include equating OOP with buzzwords like inheritance and getters/setters, while neglecting its core concepts such as bundling related state and behavior into cohesive units (objects) and minimizing dependencies through proper encapsulation.

The post highlights that encapsulation is not merely about hiding internal state but about reducing interdependencies and ensuring modularity. Public properties, often critiqued for exposing internal states, are likened to getters and setters in their inability to prevent object coupling. The author points out that real-world OOP is much more nuanced, involving trade-offs that depend on the problem domain and language constraints. A detailed comparison of popular languages, including JavaScript, Python, Rust, and Go, demonstrates varying implementations of OOP features like inheritance, subtyping, and encapsulation. 

From the article, I was able to rethink my use of OOP principles and highlighted that simplicity and adaptability should be the goal when programming. Going forward, I plan to be more thoughtful about whether OOP concepts like inheritance are necessary or if simpler, more flexible design choices would work. The article taught me that well-designed OOP should evolve naturally rather than forcefully adhering to principles. This perspective will help me develop solutions that adapt to change more easily, making my work in software development more efficient and adaptable. After reading, I feel like I will be able to not make as many mistakes that lead to inefficient use of OOP creating a better and more efficient workflow when coding.

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

This week, I found an article questioning the relevancy of UML as Agile development processes are becoming more and more used today. This was an interesting article for me to read as it points out some of the flaws with trying to use UML while developing software with Agile, but also a couple of potential ways it can still be useful. The overall notion I got from reading this article was that UML has it’s time and place, but it is certainly becoming a thing of the past as developers start to lean more toward an Agile development process.

The article states that in an Agile environment requirements are typically not defined in detail prior to starting the project, as well as the design of the software. As the project progresses, the requirements and design will usually evolve over time. Also, formal documentation during a project isn’t as much of a necessity while going through an Agile development process. These three big components of Agile clash quite a bit with trying to implement UML as UML pretty much requires the exact opposite of these three components. Basically, you can’t define the design and details prior to the project because of insufficient information which you would need with UML, and it would also need a lot of effort to update the UML diagrams as the project evolves.

There are a couple ways UML diagrams could still be useful as listed in the article as well:

Once development is completed, it may be helpful to use UML diagrams to support the system. Using UML to define and standardize the architecture would also be another reason to still practice it.

I think, as I stated earlier, there is a time and a place for using UML. Obviously, if you haven’t adopted an Agile development process then UML could still be on the table to use; most people do use Agile now though. Because of this, you can certainly still use UML diagrams, but if you want it to be in an efficient manner, it should be used in one of or both of the ways mentioned directly above. It’s still great to have the knowledge of most certainly, as UML from what I’ve read and heard other people speaking isn’t completely outdated, but it definitely isn’t going to be something worth stressing over if you’re not the most knowledgeable on how it works.

From the blog CS@Worcester – RBradleyBlog by Ryan Bradley and used with permission of the author. All other rights reserved by the author.

This week, I am sharing a blog post related to software design principles written by Alex Klimenko, a well-versed Java developer with experience in building applications, performance optimization, and multithreading. This blog was selected based on the relevance to our course topics and the relation being drawn to Java. Please consider reading Alex’s full blog here.

Klimenko’s post covers three main principles DRY, KISS, and YAGNI, all of which are vital for avoiding common coding pitfalls and ensuring that we are writing code that others will use and that our future-selves can be proud of. The writer’s description of these principles allowed me to grasp the concepts on a deeper level and learn about how they can really make a difference when properly implemented.

The DRY principle is an acronym representing the phrase “Don’t Repeat Yourself” which Klimenko also equates to “Do It Once”. This blog explains this concept by focusing on the root, which is that no repetition leads to less code, resulting in less errors, which means that the code, itself, is easier to maintain and update throughout time. Klimenko encourages the use of encapsulated utility classes and methods for common tasks, the use of polymorphism and inheritance to avoid duplicating code, and employing design patterns like the Template Method to refactor common behaviors.

The KISS principle can be spelled out as “Keep It Simple, Stupid” and really sticks out to me as I know I have encountered issues in this realm previously. This principle has the goal of favoring straight-forward solutions over unnecessarily complex solutions. To do this in Java, Klimenko provides many implementations ranging from encouraging clear and concise naming conventions, following Java’s best practices such as those from Java Code Conventions and Java Language Specification, and making use of standard libraries and frameworks.

The YAGNI principle represents the phrase, “You Aren’t Gonna Need It” which, in software development, equates to the concept of avoiding adding functionality/complexity to code until it is required by the customer’s current specifications. The writer phrases this as avoiding “speculative development” or thinking about future needs that are not yet even in existence. A few of the ways Klimenko relates this principle to Java is by encouraging a minimalistic class design, lean dependency management, and avoiding premature optimization.

After reflecting on all that this blog has helped me to understand, I have become much more aware of some of the poor qualities that likely exist in my own code, but I also feel like I am prepared to begin attempting to apply these concepts in my work so that I can gear myself towards becoming a better programmer with sound principles. Mastering these principles will take years of practice, but to begin applying them now, as a student, I can ensure that my approach to coding and the implementation will constantly be improving.

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

SOLID is an acronym for a set of design principles for object-oriented programming that is used to help developers create flexible, efficient, and easily maintainable software. I think the article “SOLID: The First 5 Principles of Object Oriented Design” by Samuel Oloruntoba and Anish Singh Walia does a great job explaining the SOLID principles. I plan on using these principles in the future to further develop my code and to make sure it is easy to read and understand.

Here is what each of the letters in SOLID stand for:

S: Single Responsibility Principle (SRP)
O: Open-Closed Principle (OCP)
L: Liskov Substitution Principle (LSP)
I: Interface Segregation Principle (ISP)
D: Dependency Inversion Principle (DIP)

SRP states “A class should have one and only one reason to change, meaning that a class should have only one job.” Essentially this means that any object or class should be made for one specific function in order to better understand the code.

OCP states “Objects or entities should be open for extension but closed for modification.” The article states that “This means that a class should be extendable without modifying the class itself.” I think this article does a great job explaining what all of the different principles mean as well as giving examples for each of them. I strongly recommend using this website if you’re trying to learn about SOLID.

LSP states “Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.” At first, this really confused me. After doing some research and coming across this website, I began to understand this principle more. In simpler terms, it means that every subclass should be a substitute for their parent class. If you need examples to see how this would work, I highly recommend looking at the linked article.

ISP states “A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.” This principle states that software should be broken down into smaller, more specific parts. This is so it doesn’t depend on code it doesn’t use.

DIP states “Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions.” In simple terms, both high-level and low-level modules should depend on abstractions, and abstractions should not depend on details.

Link to article: https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design#dependency-inversion-principle

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

In class after learning about a few select HTTP response codes, I wanted to look into the whole library of possible codes to get a better understanding of how website calls work and the potential errors that come with them. The blog I chose to read from gave a brief introduction to why knowing the meaning of the response codes is important for managing or using a website. Before going into the specific definitions of each code, the author states the main takeaways at the beginning of the article which helps the reader know what to look out for as they read ahead.

The codes are representations of the types of responses between the web server and the browser. Every time you use a new URL an HTTP code is generated. The author goes on to explain how making sure you have successful HTTP codes is a good way to promote a website because search engines use the HTTP response codes to determine if that URL will show up as a result.

Next is the part of the article that shows how the first of the three digits are grouped and defined, which I didn’t know and is helpful to know. Some that we didn’t go over in class was 100 codes that are for Informational responses and 300 for Redirection. There is then a reference table provided that gives the corresponding code and definition for each code. The author then goes into more detail about how search engines use these codes to determine what pages get recommended to users.

I think that for myself and how I tend to learn best is by looking up libraries of every possible response/function/use for something and deepening my understanding of a topic and knowing how it works and why it was made that certain way. It will also be helpful as both a developer and a user because now when I see an HTTP response code, I will know what it means and what I would need to do to fix or get around the problem. I also learned how important HTTP response codes are for increasing your website traffic and another reason to have efficient web code for something that I wouldn’t have thought of. Doing outside of class and self-directed research on class topics is very helpful to connect different topics together as well as how they relate to work that is done in the field

Common HTTP Response Codes Explained – Neil Patel

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

The article I chose for my blog entry is titled “Design Patterns” from Refactoring Guru. Design patterns are tried-and-true solutions to recurring problems in software design; they act as adaptable blueprints to guide programmers on how to solve design problems effectively in code. This article introduces design patterns, breaking down what they are, their history, and why they are valuable in object-oriented programming. Additionally, it covers why design patterns have become essential for developers, offering a common language for communicating solutions to complex design challenges.

Refactoring Guru’s article is structured into several sections, including “What are Design Patterns?”, “History of Design Patterns”, “Why Should I Learn Design Patterns?”, and “Criticism of Patterns”. The website offers a straightforward breakdown of why design patterns are essential, teaching programmers how to approach various challenges in object-oriented design. By establishing common concepts and practices, design patterns create a shared language for developers, enabling them to communicate and collaborate more efficiently.

The article also categorizes design patterns into three main types: creational patterns, structural patterns, and behavioral patterns. Each category serves a different purpose in software design:

1. Creational Patterns – These focus on creating objects in a way that supports flexibility and reusability, ensuring that objects are created efficiently and consistently to allow the project to scale.
2. Structural Patterns – These organize classes and objects into cohesive structures, making it easier to expand and modify systems. They help parts of a system interact smoothly while staying independent.
3. Behavioral Patterns – These improve communication and responsibility-sharing between objects, streamlining interactions to reduce complexity and make the system easier to manage.

After reading this article, I have a much deeper understanding of software architecture, especially within object-oriented design. Initially, I chose this topic because I wanted to enhance my understanding of design patterns for a homework assignment. Although we had a class discussion on the topic, I found myself struggling to grasp the purpose of design patterns fully. Learning about the intent behind patterns, including why they are named and applied in specific ways, has helped me see design patterns as as the core in building flexible, maintainable code.

In the future, I plan to use design patterns as a guideline and blueprint for project planning and implementation. I appreciate how design patterns provide a structured approach to problem-solving in software, allowing me to develop systems that can grow and change with ease. Additionally, I value how design patterns enable programmers to collaborate more effectively. By using a shared vocabulary, developers can discuss complex solutions more simply, making teamwork smoother and more efficient.

Overall, this article from Refactoring Guru has not only broadened my understanding of design patterns but also shown me how these patterns are a crucial part of becoming a proficient software engineer.

Sources:

https://refactoring.guru/design-patterns

Citation:

Design patterns. Refactoring.Guru. (n.d.). https://refactoring.guru/design-patterns 

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

Most of my time developing software so far has been with the back-end, I had to learn a decent amount about specific algorithms and because of the languages I worked with especially Java, learning about the Garbage Collection is something that’s been on my mind for a while. Overall, my time spent actually researching the Garbage Collector for Java has been very limited, all I knew was the baselines of the algorithms and the base of the functionality. While searching for some posts and information about the GC I came across a video from Inside Java that went over the Z Garbage Collector. Here is the link to said video, https://inside.java/2023/04/23/levelup-zgc/?utm_source=blog.quastor.org&utm_medium=referral&utm_campaign=scaling-microservices-at-doordash. For a quick summary of what is discussed in the video, there are multiple garbage collector types for Java, most of which are usually used in different scenarios. A quick description is given of these garbage collectors and some of their strengths in terms of throughput, memory footprint, latency and scalability. After discussing these, we learn more about ZGC which first released in a jdk11 development build for testing. Comparatively, ZGC is far better than pretty much every other GC in terms of scalability, heap allocation, latency and just overall performance. ZGC especially in terms of pause times is so much better that most other GC have a pause time in the terms of milliseconds, while ZGC has pause times in terms of microseconds. With accessibility in mind, when doing performance tuning for ZGC it is way easier, after jdk 17, it auto-adjusts itself to handle the amount of threads it will need for garbage collection, aside from that there is only the max heap allocation that the user should worry about tuning as well. The reason I am mostly interested in these types of algorithms and garbage collection systems in general is because many of the projects I’ve developed rely on them to be as efficient as possible, removing the unused data and keeping memory usage down. After listening to this I will most certainly either start using ZGC for my applications or do more research on the topic because for the most part I never paid too much attention to what GC my applications were using, it didn’t matter to me since I was uninformed on what exactly they did. Now that I know more about how specific GC’s function I’m most certainly going to start and try to apply ZGC to most of my projects as it seems it will be the most efficient for me.

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

Earlier in this course, I learned about UML diagrams, how to read them, how to make them, and so on. This section of the class stuck with me as I thought it was pretty interesting how we use these diagrams to “visualize” our code. I thought I’d gain some more insight on UML diagrams and possibly more on how they are used in the real world.

For those who aren’t so familiar with UML diagrams, let me give you some background. UML stands for “Unified Modeling Language” and is “a way to visually represent the architecture, design, and implementation of complex software systems” (Lucidchart). These diagrams can be generally divided into two types, structural and behavioral. Both types of UML diagrams are pretty self-explanatory but structural UML diagrams display the various pieces of a system and how they are related while behavioral UML diagrams show how the system “interacts with itself and with users, other systems, and other entities” (Lucidchart).

In this blogpost from Lucidchart, one of the first things that caught my eye was under the section “Why should you use UML diagrams?” Of the four bullet points, three of them had me nodding my head in agreement, these were:

• Bring new team members or developers switching teams up to speed quickly.
• Plan out new features before any programming takes place.
• Communicate with technical and non-technical audiences more easily.

To me, these points make perfect sense. I’m not very familiar with how development teams work in the real world but I assume that there are plenty of developers and others that may come and go in companies, groups, and such. It may sound like a simple switch or change but that new person may have no idea what they will be working on or how it will be worked on. UML diagrams could help them adjust more quickly and help them understand their role, team, and work better. As for planning, simply adding a new piece to the diagram to indicate a new piece of the system could help display the relationships to what they already have. And finally, UML diagrams are much easier to digest than multiple files, classes, blocks of code, and such, especially for those who are not developers. A customer may want some update or insight into what they are spending their money on, and so, teams can simply show them a UML diagram and point out where they are and where they plan to go.

Blogpost: https://www.lucidchart.com/blog/types-of-UML-diagrams

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

In the realm of software development and design, UML (Unified Modeling Language) class diagrams play a pivotal role. The blog post “UML Class Diagram Explained with Examples” by Algomaster provides a comprehensive overview of class diagrams, illustrating their importance in modeling the structure of a system.

Code, while essential for functionality, is not always the best medium for conveying complex relationships between components. To address this challenge, the Unified Modeling Language (UML) class diagram provides an abstract visual representation of the structure of a system. The blog post by Algomaster, offers a detailed explanation of UML class diagrams, including key concepts such as classes, attributes, methods, and associations. This resource was particularly relevant to our recent assignment on Modeling with UML Class Diagrams, where we were tasked with designing class diagrams to represent a student-course scheduling system.

The blog post breaks down the structure of UML class diagrams, explaining each component in detail with accompanying examples. The tutorial begins by outlining the core elements of a class diagram, including classes, attributes, methods, and associations.

I selected this blog post because it provides a clear, concise explanation of UML class diagrams and their practical application, which directly ties into the Modeling with UML Class Diagrams assignment. This resource helped me better understand how to translate Java code into a UML diagram by identifying key components such as classes, attributes, and methods. Additionally, the visual nature of the tutorial, with its real-life examples, made it easier to grasp abstract concepts and apply them to my assignment.

I feel more confident in my ability to design and interpret UML class diagrams. Visit the original post on Algomaster: UML Class Diagram Explained with Examples.

From the blog SoftwareDiary by Oanh Nguyen and used with permission of the author. All other rights reserved by the author.