Category Archives: C

Introduction to Pattern Designing

Source: https://www.geeksforgeeks.org/introduction-to-pattern-designing/

This article is titled “Introduction to Pattern Designing.” In regards to software development, “pattern designing refers to the application of design patterns, which are reusable and proven solutions to common problems encountered during the design and implementation of software systems.” These reusable design patterns showcase relationships that occur between classes or objects. They are language dependent, so they can be described as an idea that makes code flexible and overall speeds up the process of development. Their purpose is to solve common problems. There are three main kinds of design patterns, creational, structural, and behavioral. “Creational design patterns abstract the instantiation process.” Creational design patterns offer a sense of flexibility in regards to “what gets created, who creates it, how it gets created, and, when.” Knowledge about which concrete class is being used is encapsulated and the way instances of classes are created is hidden. “Structural design patterns are concerned with how classes and objects are composed to form larger structures.” Inheritance is used to create interfaces/implementations. Structural design patterns are good for when you want to make independent class libraries collaborate effectively with one another and offer flexibility regarding object composition. “Behavioral design patterns are concerned with algorithms and the assignment of responsibilities between objects.” Patterns of communication are being described here. Inheritance is used to divide behaviors between classes, object composition is used for behavioral object patterns, and the object patterns encapsulate behaviors in objects. Overall, the benefits of pattern designing are reusable solutions, scalability, and abstraction/communication. The downfall of it however is that there is a learning curve while you try to understand the patterns, there may be concerns with when you should apply the patterns in your code, and if patterns aren’t implemented consistently and in correlation with the advancement of the system, maintenance issues may occur. But regardless, they are a great way to solve common problems during the development process.

I chose this topic because the idea of design patterns was in the syllabus and it interested me. We learned about design patterns such as Factory, Strategy, and Singleton, but reading about the larger terms of creational, structural, and behavioral patterns offered deep insight into the topic. The supposed benefits of common methodologies in software development are always presented but it is also good to know about the downfalls, which I am glad this article showed about the design patterns. When I am working on a team or in the workforce, I will definitely reference these design patterns to improve the maintenance capability and scalability of my code, and do so in a way which I am able to avoid the downfalls of implementing them incorrectly. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Understanding SOLID Principles: A Guide

As a student learning software design, I’ve heard about the SOLID principles in class, but I wanted to dive deeper to understand how to actually use them. I came across a blog post called “SOLID Principles — The Definitive Guide” by Midhun Vincent on Medium, which breaks down each of the five principles in a way that makes sense for someone new to object-oriented design. The guide was really helpful and lined up well with what we’re covering in my course, so I thought it would be a good opportunity to see how these principles could improve my coding now and in the future.

The article explains the SOLID principles, which are five important guidelines for creating object-oriented software that’s easier to understand, maintain, and extend. The first principle, the Single Responsibility Principle (SRP), says that each class should do only one thing, making it easier to maintain and modify. The Open/Closed Principle (OCP) suggests that classes should be open for extension but closed for modification, meaning you can add features without changing the original code. The Liskov Substitution Principle (LSP) ensures that subclasses can replace their parent class without breaking the system. The Interface Segregation Principle (ISP) advises creating small, specific interfaces rather than large, general ones. Finally, the Dependency Inversion Principle (DIP) suggests that high-level modules should depend on abstractions, not low-level modules, which makes the code more flexible. These principles help make code cleaner, more modular, and easier to adapt over time.

I picked this article because, while the SOLID principles are useful, they can seem pretty abstract at first. The post explains them in a way that feels practical, with examples that make it easier to apply the principles to real-world coding problems. Plus, the examples connected well with the projects I’ve worked on in my course, especially when it comes to organizing code and making it easier to debug. Seeing how these principles prevent code from becoming too messy gave me a new way of thinking about my own assignments.

My Takeaways and Reflection

Before reading this post, I knew the basic ideas behind SOLID, but I wasn’t sure how to apply them in my own code. Now, I get why each principle is important and how they can save time by reducing debugging and refactoring. For example, the Single Responsibility Principle made me realize that I often give classes too many responsibilities, which complicates fixing bugs. By applying SRP, I can keep things simpler and reduce errors.

Looking ahead, I plan to use these principles in my projects, especially the Open/Closed Principle and Interface Segregation Principle. I can see how they’ll help me write code that’s easier to update and adapt. Understanding SOLID will definitely give me a strong foundation as I take on more complex projects in the future.

Resource:

View at Medium.com

View at Medium.com

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

GRASP

Source: https://www.youtube.com/watch?v=GcqTrlL_Htw

This video from YouTube is titled “Design Patterns GRASP // Object Oriented Analysis and Design (ICS).” As stated in the title, it goes over the design patterns of GRASP, or General Responsibility Assignment Software Patterns. GRASP is a set of 9 principles that relate to object-oriented design that help developers/engineers assign certain responsibilities to certain variables, classes, objects, etc. in software. The overall purpose of GRASP isn’t to create “fancy” code, but rather to create maintainable and reusable code/software. The 9 principles are information expert, creator, controller, low coupling, high cohesion, polymorphism, pure fabrication, indirection, and protected variations. “Information expert” places responsibility on classes that have the required information to complete it, wanted behaviors and data are put together. “Creator” places responsibility for the creation of instances of classes to classes that would use it. “Controller” places responsibility for handling system events to a class that describes the event, known as the controller. “Low coupling” states that classes should be as independent as they can be from other classes. “High cohesion” states that classes should have clear purposes with responsibilities that relate to it. “Polymorphism” is implemented so new behaviors can be added without changing preexisting code. “Pure fabrication” states that new classes should be created if there isn’t an already existing one that fulfills a desired requirement. “Indirection” states that dependencies among classes should be minimized so changes can be made without having an impact on other parts of the system. Lastly, “protected variations” encourages developers to design the system in a way that variations in behaviors are negated through encapsulation. 

I chose this particular source because we haven’t covered this topic in class yet and it seemed interesting, I found the topic from the syllabus. This video had a low amount of views and I wanted to give it a chance. After watching the video, I appreciated the fact that the information was presented in a straightforward manner and offered visual examples for each of the 9 principles of GRASP. After learning about Agile methodologies, it was interesting to learn about GRASP, because in my opinion it seems as though instead of being a set of principles of workplace improvement, GRASP seems to be a set of principles for actual work improvement. Overall, the material impacted me in a positive way because I appreciate the idea of everything in a system/software having a certain responsibility, and can definitely see how this will benefit me in the future when I work on more projects related to software development. I will certainly keep GRASP in mind for these future projects. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Understanding SOLID Principles: A Guide 

As a student learning software design, I’ve come across the SOLID principles in a few lectures, but I wanted a deeper dive to really understand how to apply them. I recently read a blog post titled “SOLID Principles — The Definitive Guide” by Midhun Vincent on Medium. This guide breaks down each of the five SOLID principles in a straightforward way, with examples and explanations that actually make sense for someone still new to object-oriented design. The article is totally in line with what we’re covering in my course, so I figured it was a great chance to see how these principles could improve my coding style now and in the future.

Summary of the Selected Resource

The article explains the SOLID principles, which are five key guidelines for designing object-oriented software that is easier to understand, extend, and maintain. The first principle, the Single Responsibility Principle (SRP), emphasizes that each class should focus on a single task, making the code simpler to maintain and update. Next is the Open/Closed Principle (OCP), which suggests that classes should be open for extension but closed for modification, allowing developers to add new features without altering the original code structure. The Liskov Substitution Principle (LSP)follows, which ensures that objects of a superclass can be replaced with objects of subclasses without causing issues in the application. Then there’s the Interface Segregation Principle (ISP), which advises against creating large, general-purpose interfaces and instead encourages smaller, more specific ones that suit the exact needs of different clients. Finally, the Dependency Inversion Principle (DIP) recommends that high-level modules should not rely on low-level modules but rather on abstractions, which reduces dependency and enhances flexibility. Together, these principles form a strong foundation for writing clean, modular code that can handle future changes more gracefully.

Why I Chose This Resource

I chose this post because the SOLID principles are really useful in building better code but can feel abstract at first. The article breaks down each principle in a way that makes them feel practical and achievable. Also, the examples in the post connect well with coding challenges we’ve faced in our course projects, especially in terms of keeping code organized and easy to debug. Seeing how SOLID principles can prevent code from becoming a tangled mess gave me a new perspective on how I approach my own assignments.

My Takeaways and Reflection

Before reading this post, I understood the theory behind the SOLID principles but not really how to implement them in my own code. Now, I can see why each principle matters and how they can actually save time by reducing the need for debugging and refactoring down the line. The Single Responsibility Principle, for example, made me think about how I often give one class way too many jobs, which then makes fixing issues complicated. By applying SRP, I can keep my classes simpler and less error-prone.

Moving forward, I’m planning to use these principles as I work on my projects, especially with the Open/Closed Principle and the Interface Segregation Principle. I can see how they’ll help me write code that’s easier to adapt if requirements change or if I add new features later. In the future, I think understanding SOLID will give me a solid foundation (pun intended!) as I move into more complex software development work.

Link to the Resource

https://medium.com/android-news/solid-principles-the-definitive-guide-75e30a284dea

View at Medium.com
View at Medium.com

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

What is Reasonable Test Coverage?

Earlier this week I was reading through some blogs and stumbled across this particular piece that I found highly amusing but answered a question that I had been looking for an answer.

I found this article called The way of Testivus. It’s essential Confucius meets programming. While reading through and chuckling at most of the things mentioned on this page I stopped being side tracked and continued to see if I could find a good answer to my question – What is a reasonable amount of test coverage? As I continued to google I landed back onto the artima.com forums and found there was the question I had been searching for. Funny enough the writer of the “The way of Testivus” replied with an answer to this poster’s questions

Testivus On Test Coverage
Early one morning, a programmer asked the great master:

“I am ready to write some unit tests. What code coverage should I aim for?”
The great master replied:

“Don’t worry about coverage, just write some good tests.”
The programmer smiled, bowed, and left.

…

Later that day, a second programmer asked the same question.

The great master pointed at a pot of boiling water and said:

“How many grains of rice should put in that pot?”
The programmer, looking puzzled, replied:

“How can I possibly tell you? It depends on how many people you need to feed, how hungry they are, what other food you are serving, how much rice you have available, and so on.”
“Exactly,” said the great master.

The second programmer smiled, bowed, and left.

…

Toward the end of the day, a third programmer came and asked the same question about code coverage.

“Eighty percent and no less!” Replied the master in a stern voice, pounding his fist on the table.
The third programmer smiled, bowed, and left.

…

After this last reply, a young apprentice approached the great master:

“Great master, today I overheard you answer the same question about code coverage with three different answers. Why?”
The great master stood up from his chair:

“Come get some fresh tea with me and let’s talk about it.”
After they filled their cups with smoking hot green tea, the great master began to answer:

“The first programmer is new and just getting started with testing. Right now he has a lot of code and no tests. He has a long way to go; focusing on code coverage at this time would be depressing and quite useless. He’s better off just getting used to writing and running some tests. He can worry about coverage later.”

“The second programmer, on the other hand, is quite experience both at programming and testing. When I replied by asking her how many grains of rice I should put in a pot, I helped her realize that the amount of testing necessary depends on a number of factors, and she knows those factors better than I do – it’s her code after all. There is no single, simple, answer, and she’s smart enough to handle the truth and work with that.”
“I see,” said the young apprentice, “but if there is no single simple answer, then why did you answer the third programmer ‘Eighty percent and no less’?”

The great master laughed so hard and loud that his belly, evidence that he drank more than just green tea, flopped up and down.

“The third programmer wants only simple answers – even when there are no simple answers … and then does not follow them anyway.”
The young apprentice and the grizzled great master finished drinking their tea in contemplative silence.

 

In my early stage as a programmer I decided I am going to dedicate myself to not best understanding what I should be looking for in code coverage but better understanding how I can get there with quality tests.

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