Monthly Archives: October 2024

Exploring Design Patterns in Computer Science: A Beginner’s Perspective

Design patterns are essential concepts in software engineering, providing time-tested solutions to common problems. As an apprentice in computer science, understanding design patterns can significantly boost your coding efficiency and software design skills. During my learning journey, I found an insightful article, Java Design Patterns from GeeksforGeeks, that provided me with a solid foundation on design patterns. Here’s a summary of the article and my reflections on how it has shaped my learning experience.

Summary of the Selected Article

The GeeksforGeeks article Java Design Patterns covers the key design patterns used in Java programming. It introduces three main types of design patterns—Creational, Structural, and Behavioral. Each category is explored with practical examples and explanations that break down the complexities of design patterns into digestible information. The article also touches on popular patterns like Singleton, Factory, Decorator, and Observer, providing clear definitions and illustrating their use cases in real-world Java applications. It serves as an excellent resource for beginners to grasp how design patterns can improve code readability, reusability, and maintainability.

Reason for Choosing this Resource

I chose this article because GeeksforGeeks is known for delivering educational content tailored to both novices and experienced developers. I needed a source that could present design patterns clearly and practically, specifically for Java programming, which I am currently studying. The website’s step-by-step approach to explaining concepts, accompanied by code snippets, resonated with my learning style. As a beginner, I was looking for a resource that could demystify design patterns without overwhelming me with technical jargon, and this article did exactly that.

Personal Reflection and Key Takeaways

The material was enlightening, especially in how it framed design patterns as reusable solutions to software design issues. Before reading the article, my understanding of patterns like Singleton or Factory was limited to theoretical concepts, but the examples provided helped me visualize their practical applications. One major lesson I took from this article is the importance of the Singleton pattern, which ensures that a class has only one instance and provides a global point of access to that instance. This concept is essential in areas like database connections, where having multiple instances could lead to conflicts.

Additionally, learning about the Factory pattern—a creational pattern that allows for the creation of objects without specifying the exact class—opened my eyes to how flexibility and scalability are achievable in code. This pattern is especially helpful when dealing with large projects where new object types might frequently need to be added.

The article not only strengthened my grasp of object-oriented principles but also inspired me to think more critically about how I structure my code. It shifted my perspective from merely getting the code to work, to considering how to design it efficiently for future use and maintenance. I now see design patterns as a roadmap to writing better, more scalable code.

Future Application of Design Patterns

Moving forward, I plan to incorporate these design patterns into my coding work practices, particularly in my Java projects. The Singleton pattern will be useful in managing system-wide resources, while the Factory pattern will aid in developing modular code that can easily evolve. Understanding these patterns equips me to write code that is not only functional but also adaptable, which is crucial as I delve into larger, more complex projects.

In conclusion, design patterns are invaluable tools for every software developer. Thanks to resources like the GeeksforGeeks article, I now have a clearer understanding of how to implement these patterns in Java, and I look forward to applying them in my future projects.

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

Code Review

For my first real blog entry, I would like to talk about Code Review. I chose this topic because we are doing in-person activities based on clean code, in my Software Process Management class. When discussing how to make code cleaner and more readable, I looked more into the topic for more information. Code Review is a process performed by a person or more to examine and improve the code. I found this blog titled “How to Review Code – Tips and Best Practices” by ‘AK DevCraft’ and noticed that some of the points and practices are the same as we learned in class.

The blog highlights three important tips to be aware of when reviewing code, the first tip being Intention. This tip explained what the dos and don’ts are when reviewing code. When you review someone’s work, it’s pivotal to be positive and respectable. Giving constructive criticism, and explaining precisely what changes need to be made to improve the code. The blog also made sure to emphasize not to leave comments where you didn’t need one. Adding multiple comments to code is unnecessary and makes the code harder to read. The summary of the first tip was to be respectful to the ones who wrote the code and make it a collaboration when reviewing the code.

The second tip the author said was important was Standards. When reviewing code, making the code easy to read while making it easy to understand is what coding is all about. This can be done by sticking to a consistent format, which can be having meaningful whitespace, removing unnecessary gaps, or breaking larger functions into smaller ones. Understanding the standards of variables by creating clear and concise names for every variable. By knowing to avoid abbreviations and add values to variables such as “gallon” or “mL” to make the variable clear on what unit it is. A good practice we learned in class is to avoid duplication, duplication of code can lead to unnecessary code or more confusing messes like bugs or error messages.

The last tip the author highlighted was to review. When finishing the code review, keeping the big picture in mind can verify if your changes were necessary. GitHub is a platform we are using in class for our in-class discussions the platform has a review system to look over the source code and can help you double-check the code.

The blog shined a light on tips I believe are important when reviewing code, when my group did discussions on reviewing code, we used the same tips listed in this blog in our discussion. The blog gave me information on taking reviewing code to the next level, informing me of the GitHub feature to review the source code and always keeping a strict format in mind when reviewing code. I would recommend this blog to someone who is new to reviewing code or just wants a different approach when reviewing code with another person.

Source: https://dev.to/akdevcraft/how-to-review-code-2gam

From the blog Mike's Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.

On the subject of Clean Coding…

This week, I am going to provide some insights/opinions regarding the practicality of some clean code principles, along with an example of when over-optimization for the sake of readability might actually be counterproductive. The resource I will be referencing this week can be found here. This article documents many of the same clean-code principles we discussed in class, plus or minus a few. For each principle, it provides an explanation as well as a coded example to demonstrate the principle and/or the difference between good and bad code according to the principle. I chose this article because I felt it was comprehensive enough to cover the key points for clean coding, and because I tend to use many of the principles outlined in the article in my own code.

I am currently involved in a project where the Single Responsibility Principle (SRP) might actually be counterproductive to my primary objective. In general, I tend to agree with this principle, and I understand its benefits well. It makes code far easier to read and follow, and, as we discussed in class, modern compilers can optimize functions to where there is almost no difference in execution time by offloading logic into its own function.

My program runs an ultra-fast search on a set of numbers (speaking very loosely), and needs to update numbers around 250 times per second. Thus, my time to find what I am searching for and act on it is ~4ms before all the data is useless (think: cracking Enigma in The Imitation Game). Now, factor in that I need the majority of the ~4ms to actually execute based on my search result, and one arrives at the conclusion that the search needs to take <1ms (or as little time as possible). Now to my point: sometimes, to accomplish this, I found that I had to violate the SRP. This means that I call search(), and search() immediately calls execute() if it finds what it’s looking for, eliminating the time it would have taken to return the value to main() and then pass the value back to execute(). This is obviously a miniscule difference, but in my testing and gathering data, I found that when multiplied out to larger and larger numbers, this little hack shaved off a noticeable amount of time.
This might all be more related to Command-Query Separation or the “No Side Effects Principle” than it is to the SRP, but my points still stand. What I am getting at in the big picture is that these principles, while applicable and preferable a massive portion of the time, are not always the right way to go. Sometimes, you have to sacrifice one or more in pursuit of your primary objective. All this said, my largest takeaway going forward is that I should remember and implement clean code principles whenever/wherever possible, but I will always try to remember that they are not law, and sometimes variance is necessary.

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

On the subject of HFOSS in Education…

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&#039;s Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Learning the Basics of Software Copyrighting and Licensing

When I first started studying how code and software is protected by law, I was lost. I’d never explored the realm of who owns what, or when one can utilize another’s code. I decided to delve further into these concepts after I was inspired to by a software development course.

I came across two fantastic pages on TechTarget, one on software licenses, and the other on copyright (1,2), that covered many topics of software law, including what licenses and copyrights are, do, and where they come from. Through reading these pages, I developed a better understanding of the these legal topics.

Licenses

Licenses are contracts between the people who developed or own the software, and the people or organizations who want to use the software. They cover how the software can be used, what the rights of the owners are, and what the users are allowed to do with the software. They can also include how the software is paid for, how many copies can be downloaded, or what level of access to the source code users can have.

This image from TechTarget gives an overview of strictness of different types of software licenses. To apply a license to software, the legal text of the license must be included with the software when shipped. This can be accomplished by including a file called “License” that contains the legal text alongside your software.

Obtaining a license from the software owner generally involves paying the owner to use the software. An example of this exchange is when someone purchases a video game. The person pays the price of the game, accepts the end-user license agreement upon loading the game up, and can then use the software forever.

This concept of payment for license is essentially the same when scaled up for business applications. One company can pay a software company for the license to utilize their software. This will likely cost more money than purchasing a video game, and can potentially involve other stipulations depending on license choice.

Copyrights

Copyright prevents others from copying or otherwise exploiting your creations, but works differently than licensing. For one, copyrighting in most countries, including the USA, is automatic. When software is written, the developer, or company the developer works for, automatically gains copyright over that work. This prevents others from stealing, reusing, or altering the work without permission. The copyright holder can also formally apply for a copyright with their country’s relevant organizations.

Interestingly, copyright can have a time limit in terms of years, with some companies, such as Disney, fighting to lengthen or alter the laws to allow them to protect their original mouse design for as many years as possible.

One huge difference with copyrighting is that someone else can use parts of your work legally without specifically asking you or your company. This is called “Fair-Use” by the non-owner, and includes uses such as for criticism and comment, parody, education, public good, and non-commercial activities.

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

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.