Category Archives: Programming

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.

Design Patterns

Design patterns are essential tools for software developers, providing standardized, reusable solutions to common coding challenges. Rather than developing unique solutions every time a familiar problem arises, developers use these templates to write organized, efficient, and adaptable code. Design patterns are not complete blocks of code but instead serve as blueprints, guiding the structure of code in object-oriented programming and enhancing overall project organization.

according to the published article on GeeksForGeeks, the article mentions about A key advantage of design patterns which is reusability. Patterns can be applied across different projects, which saves time and effort by eliminating the need to repeatedly solve similar issues. This flexibility also allows developers to apply patterns quickly in various scenarios, accelerating development. Another benefit is standardization; design patterns create a common vocabulary among developers, which simplifies communication and collaboration within a team. By recognizing these patterns, all team members can quickly understand and follow the structure of the codebase.

Design patterns further promote efficiency by offering solutions that have been tested and refined over time. Since developers do not need to invent new solutions for frequently encountered problems, they can progress faster with fewer errors. Additionally, design patterns are designed to be flexible. They are adaptable templates, meaning they can be customized to fit specific project needs, making them a versatile tool for a variety of applications.

Types of Design Patterns

Design patterns fall into three main categories: Creational, Structural, and Behavioral.

  1. Creational Patterns focus on managing object creation to keep systems flexible and independent of object-specific creation logic. Examples include:
    • Factory Method: Allows creation of objects without specifying the exact class.
    • Singleton: Ensures only one instance of a class exists globally.
    • Builder: Breaks down complex object construction into simpler steps.
  2. Structural Patterns emphasize organizing classes and objects to create efficient, larger structures. Examples include:
    • Adapter: Enables incompatible classes to work together by adjusting their interfaces.
    • Facade: Simplifies complex systems by providing a unified interface.
    • Decorator: Adds extra functionality to objects without altering other instances.
  3. Behavioral Patterns focus on defining how classes and objects interact within a system, streamlining communication in complex applications.

In summary, design patterns help developers produce clear, maintainable, and scalable code. By adopting these patterns, developers can approach recurring problems with reliable solutions, improving collaboration, reducing development time, and creating codebases that are easy to expand and adapt. In the fast-paced world of software development, design patterns serve as a stable foundation for building robust, flexible applications

Reference: https://www.geeksforgeeks.org/software-design-patterns/

From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

Week 18B – C Testing

For this week, I wanted to look at how different languages handle test cases, and I’ll continue with one I’m not the most familiar with, C! I’ve worked in small amount of C in classes at Worcester State, but have little experience outside of that. I feel like this is a good topic to discuss as knowing how other programming languages handle unit testing would be a great way to expand my knowledge when it comes to furthering my understanding of it within Java.

If you haven’t already read my other blog post on Python testing, feel free to read it right here!

Week 18A – Python Testing

For learning about unit testing in C, I consulted this article on the subject: https://interrupt.memfault.com/blog/unit-testing-basics

It seems like unit testing in C is a lot more barebones compared to Java, which in my experience utilizing C, makes sense for the language. A lot of features primarily used in Java, like object-oriented structures aren’t available in C (to my understanding, could totally be wrong).

For one major aspect, there seems to be only one assertion command in C, just simply “assert”. Theres no assertTrue, assertFalse, assertThrows, or assertEquals, just simply “assert”. And from the example given below: 

#include <assert.h>

// In my_sum.c
int my_sum(int a, int b) {
  return a + b;
}

// In test_my_sum.c
int main(int argc, char *argv[]) {
  assert(2 == my_sum(1, 1));
  assert(-2 == my_sum(-1, -1));
  assert(0 == my_sum(0, 0));
  // ...
  return(0);
}

It seems the “assert” function comes from the <assert.h> library, much like the JUnit librarys used in Java. But more importantly, it seems that “assert” is the equivalent of “assertEquals”.

It also seems like Unit Testing in C is best implemented with tools outside of a compiler for C. The ones mentioned in the article in specific were CppUTest, Unity, and Google Test. For the rest of the article, the use examples using CppUTest. It was interesting to hear one of the options being called Unity, which is the name of a game engine, which, while not written in C, is written in a mixture of C# and C++, which are both offshoots of C. Makes me wonder how testing in a gaming engine works, perhaps it’s something to look at in a future blog post, hint hint, wink wink.

CppUTest seems to implement the same SetUp() and Teardown() functions that JUnit can employ, which is really good, as these methods are important for testing multiple methods. It also seems to have more then just an Equals assertion, even though the example used is another equals example.

This gets me more interested in C, as I have been told understanding C allows you to understand other languages much more clearly. Perhaps I’ll take a deeper dive some day, who knows! Until next time, my readers~!

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

Week 18A – Python Testing

For this week, I wanted to look at how different languages handle test cases, and I’ll begin with the one I’m the most familiar with, Python! I’ve worked with Python in small amounts in the past, and have an understanding a lot of it’s syntaxes are similar to java’s, albeit simpler. I feel like this is a good topic to discuss as knowing how other programming languages handle unit testing would be a great way to expand my knowledge when it comes to furthering my understanding of it within Java.

For this, I’ll be looking at the official page for unittest on Python’s website, here:

https://docs.python.org/3/library/unittest.html

Right off the bat, I’m really interested in the fact that unittest is actually based directly off of JUnit! Which means a lot of the syntax, formatting, and framework is quite similar, just modified to fit the mold of Python.

Looking at the snippet they gave as an example…

import unittest

class TestStringMethods(unittest.TestCase):

    def test_upper(self):
        self.assertEqual('foo'.upper(), 'FOO')

    def test_isupper(self):
        self.assertTrue('FOO'.isupper())
        self.assertFalse('Foo'.isupper())

    def test_split(self):
        s = 'hello world'
        self.assertEqual(s.split(), ['hello', 'world'])
        # check that s.split fails when the separator is not a string
        with self.assertRaises(TypeError):
            s.split(2)

if __name__ == '__main__':
    unittest.main()

In this, it seems the way you define test blocks is by having a class with (unittest.testcase) and then doing “def” to define each test case.

Even the assertions are the same and written near identically, as the first three use assertEqual, which is identical to javas assertEquals, minus the s, and assertTrue and assertFalse, which are also identical to their java counterparts. assertRaises, which is used in the third test, seems to be Python’s equivalent to assertThrows, however, it seems to be a bit different in comparison. assertRaises seems to identify a specific kind of exception being raised, whereas assertThrows would just identify any exception in general.

The last line also is a block of code that allows an easy way to run all the tests, so when you run unittest.main() in a command line, it will automatically run all the tests and display the results.

There also seems to be a whole bunch of different command line options to display results and modify the ways in which its run. As an example, theres “-v”, which stands for verbosity, much like the bash command, which shows the results of each individual test being run, like below:

test_isupper (__main__.TestStringMethods.test_isupper) ... ok
test_split (__main__.TestStringMethods.test_split) ... ok
test_upper (__main__.TestStringMethods.test_upper) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.001s

OK

It seems extremely interesting and makes me want to learn more Python, which would definitely help me in my career in all sorts of ways! Next blog we will be looking at how unit testing works in C. Until then!

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

Behavior Driven Development

Behavior Driven Development ( BDD ) is a test practice that makes sure there is good quality by automating test before or during system behavior specification. BDD test focuses on facing scenarios that describe the behavior of a story, feature, or capability from a user’s perspective. When the tests are automated they make sure that the system constantly meets the required behavior.

The Behavior Driven Development Process

The BDD process has three phases to it. The discovery phase, formulation phase, and the automation phase.

1.) Discover phase: This phase is where the user creates the initial acceptance agenda for the feature. This phase is usually done in a collaborative manor, each team member is contributing.

2.) Formulation phase: This phase is where the acceptance agenda sets into detailed acceptance tests, as the backlog item gets closer to implementation. This phase also incorporates specific examples of the behavior.

3.) Automation phase: This phase is where automation tests are automated to run constantly. This is to make sure that the new system supports the new behavior.

Benefits of Behavior Driven Development

1.) Early detection of errors / defects: When you automate tests in the early stages of development process, you can identify and address the issues. BDD allows for the early detection of defects.

2.) Faster Flow and Time: when using BDD, you can reduce the errors, rework, and replan. BDD accelerates the flow of the development process. Developers can produce features / products faster and more efficiently.

3.) Stronger Test Coverage: BDD allows for a more comprehensive test coverage that focuses on the user behavior and scenarios. Both common and edge cases are tested as well.

4.) Clear understanding: BDD can be plain and clear to understand, because specific scenarios are used to describe the behavior from a user’s point of view. This helps the development to fully understand the requirements and whats going on.

Why I chose this resource

I chose this article ” Behavior Driven Development” because it provided a detail look of a very important test method that goes in conjunction with the technical and business aspect of testing. Understanding BDD is important in today’s society of software development, for giving an efficient and more user friendly user products.

Personal Reflection

This article increased my understanding of BDD and the use of it in software development. I learned a lot about how BDD strengthens collaboration and communication between the business side of things and the technical side of things. This helps to ensure that user’s expectations and requirements are met. The new found knowledge will be extremely valuable in my future endeavors because I will incorporate this method in my future projects. This will help to improve the development process and product efficiency and quality. Also, by using BDD I can make sure that all requirements and specifications are met.

The full article is here: https://scaledagileframework.com/behavior-driven-development/

From the blog CS@Worcester – In&#039;s and Out&#039;s of Software Testing by Jaylon Brodie and used with permission of the author. All other rights reserved by the author.

Test Doubles

Test doubles are a very important tool in software testing. Test doubles allow for users to break off a portion of their code to test specific parts and functions. This helps because users can do this without depending on the other factors within their code. Test doubles are substitutes, they copy the behavior of real objects. This helps to make sure that the tests remain structured and efficient.

Overview of Test Doubles

For this blog post, I chose the Article “Test Doubles: Mocks, Stubs, and Fakes Explained” by Martin Fowler. The article talks a lot about the overview of the different types of test doubles, their roles, and how they can be used in testing.

Types of Test Doubles

1.) Dummy: A dummy object is required for the creation of another object required in the code. Dummy objects will never be used in the test, they are simply like place holders to satisfy the code and its requirements.

2.) Fake: A fake is an object that will always have the same return value. This object is useful for testing certain scenarios, like a user that is logged in or in a consistent database response. They are simple implementations that are not that suitable for production but are good for testing.

3.) Stub: A stub will provided predetermined responses to method calls. Stubs usually imitate the behavior of external components like databases or web services.

4.) Spy: A spy will record information about the interactions with the object being under tests. This helps verify interactions and make sure there is the correct behavior in method calls.

5.) Mock: A mock can be a more advanced test double that will allow for dynamic behavior based on the test scenario. They verify interactions and can change behavior based on conditions. They are useful for ensuring that certain methods are called with specific parameters during the test.

Benefits of Using a Test Double

1.) Early detection of errors/issues: Using Test Doubles will help the users to find any issues within the code. This helps with reducing the risk of defects in production

2.) Cost Efficiency: Using Test Doubles will significantly help to reduce the costs that will come with fixing the issues later in the development process.

Why I Picked this Resource

I chose this resource for the blog post because it provided an in depth overview of the various types of test doubles and their specific role within testing. This article’s contents had some similarities of what we discussed in the class, making it relevant and valuable.

Personal Reflection

This article not only increased my understanding on the topic of Test Doubles, but it also showed my how unique and important each one can be in regards to testing. I also learned the various benefits of these test doubles, so when I choose one in my future endeavors I will know which one will benefit me the most.

In my future endeavors, I plan on using what I have learned about these Test Doubles objects by implementing them on future projects. This new found knowledge will help me to make better decisions in the future and will also improve the quality of my work.

The full Article is here: https://ahmadgsufi.medium.com/test-doubles-understanding-the-different-types-and-their-role-in-testing-67cbf71ea252

From the blog CS@Worcester – In&#039;s and Out&#039;s of Software Testing by Jaylon Brodie and used with permission of the author. All other rights reserved by the author.

Elevating Code Reviews: Practical Tips for better Collaboration

Code reviews are a vital part of the software development process, serving as a checkpoint to ensure quality, foster knowledge sharing, and mitigate future issues. Drawing on practical advice from a stack overflow blog article (found here) this post explores how to elevate the practice of code reviews, enhancing their effectiveness and the collaborative environment they create.

Summary

The article from stack Overflow provided insightful tips on improving code reviews, emphasizing the importance of constructive communication and efficient processes. It suggest setting clear goals for reviews, such as catching bugs, ensuring consistency, and mentoring junior developers. Techniques like keeping comments clear and actionable, prioritizing empathy and understanding, and maintaining a balance between criticism and praise are highlighted as crucial for productive reviews.

Reason for selection

I chose this article because effective code reviews are essential for any development team aiming to produce high-quality software. As our coursework often involves collaborative projects and peer reviews, applying these enhanced practices can significantly benefit our collective learning and project outcomes.

Adding to the reasons for selecting this article, another compelling aspect is its relevance to the ongoing discussions in our software development courses about maintaining high standards in coding practices. As someone who has been part of several projects and observed firsthand the impact of well-conducted code reviews, I recognize the value in learning and sharing effective review techniques. This article not only enhances our understanding of best practices but also equips us with the tools to implement them effectively in our work, making it an invaluable resource for any aspiring software developer eager to improve their craft and contribute positively to team projects.

Personal reflection

Reflecting on the article, I appreciated the emphasis on empathy and clarity in communication. In past group projects, I’ve seen how negative feedback can demotivate peers, whereas constructive and positive communication can enhance team dynamics and improve code quality. This article reinforced the idea that code reviews are not just about finding errors but also about building a supportive team culture.

Application in future practice

Armed with these enhanced practices, I plan to apply the article’s recommendations in upcoming projects, particularly those involving teamwork. Emphasizing clear, empathetic feedback and leveraging tools for automating mundane aspects of code review will allow me and my peers to focus on more complex issues, thus improving our efficiency and the quality of our work.

Conclusion

Effective code reviews are more than just a quality assurance step; they are a cornerstone of a collaborative and learning-focused development environment. The tips provided by the Stack Overflow article offer valuable guidance on making good code reviews even better, ensuring that they contribute positively to both project outcomes and team dynamics. As we continue to engage in more collaborative projects, these practices will be essential in shaping how we approach code reviews and interact as a development team.

resources

https://stackoverflow.blog/2019/09/30/how-to-make-good-code-reviews-better/

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

Week 14

Considering this week we only had one day of class it’s good to reinforce the ideas we learned to spread out in separate classes. I was in a search this week for an article that went into depth about software technical reviews. Software technical reviews are very important; understanding the fundamentals is a key component in the field. 

The main function of a software technical review is to examine a document either in a group or alone and find errors or any defects inside the code. This is done to verify various documents to find if they reach specifications, system design, test plans, and test cases. An important thing to consider is this is a step to make sure the client gets clarity of the project and stays informed on how it’s going. In addition, finalize any changes to reach the requirements before being released to the market. This allows for improved productivity, makes the testing process cost-effective, fewer defects to be found outside the team, and reduces the time it will take to create a technically sound document. The main three types of software reviews include software peer review, software management review, and software audit reviews. The process of software review is simple if you are informed of the implementations taking place. First is the entry evaluation which is just a standard checklist to know the basis for the review. Without a checklist, you will be pulling on strings to find what is wrong with the code or what it’s missing. Then comes Management preparation ensures that your review will have all the required resources like staff, time, and materials. Next is review planning where you create an objective that comes from the team. You then move on to preparation where the reviewers are held responsible for doing their specific task. Lastly, examination and exit evaluation where the group meets up and is discussed to make the team on the same page and verify any discoveries.

Reading this article allowed me to see other steps that are taken to do a software technical review. If we as a team were able to create an objective of what to search for inside the code last week it would have been more goal-oriented instead of randomly searching for faults in the code. As a team, it would have been great to have a more organized group so then when we come together we have an understanding of what we should all find. I would like to see how it would work trying to explain to someone who doesn’t code what has been done and show them that their money is being placed in the right place. Other than that this is a great way to reduce time and be in unison with your team.   

https://medium.com/@vyashj09/software-technical-reviews-in-software-testing-what-is-software-technical-review-321462039f4f#:~:text=A%20software%20technical%20review%20is,an%20object%20in%20the%20software.

View at Medium.com

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Week 12 – Comparing Tips

For this week, I wanted to look at what some websites consider helpful tips when it comes to testing software in Java and compare that to what we have learned in class. By looking at each tip one by one and comparing it to the things Professor Wurst has taught us during our lectures.

For this, I will be looking at this website: https://www.code-intelligence.com/blog/11-tips-unit-testing-java

Tip Number 1 is to “Compose Tests before Writing Code”, which is actually what we have been focusing upon for the last few weeks, so it’s good to see that this is being reaffirmed

Number 2: Keep tests small and concentrated. This is another subject that we’ve been looking at as well, as we’ve been looking at strategies on how to concatenate code for test.

Number 3: Defining your Code Coverage. This isn’t actually something I believe we’ve spoken about in this class, however, we have discussed similar things in my previous classes with Process Management.

Number 4: Isolating Tests from External Sources. This one Im not sure if we have discussed it, but it also seems like a given, considering we have been taught to always only use tests in test classes and to pull from testing packages when importing.

Number 5: Automate wherever possible. I don’t actually think we’ve done this yet in Testing, however, this is something we have discussed previously in another class, I believe in Software Design. If you can automate something, always try to.

Number 6: Creating Mock Dependencies. This isn’t something in specific we’ve touched upon yet I feel, however it makes sense. I feel as though when I did our first homework, I kind of did something similar to this.

Number 7: Use Assertions. Yes. Absolutely we have done this in class. All if not most classes we have written use assert.equals(), assert.true(), or assert.false(), amongst others.

Number 8: Using proper names to test methods. This is something we learned way back in CS101. Always name your methods something understandable for you and your team to instantly know what it does. Never write gobbledygook names for methods, be concise.

Number 9: Keep Unit Tests Up to Date. I don’t believe this has been taught yet as most code we have worked with has been static and unchanging. However, Im sure we will have assignments where we focus on this harder. It definitely seems like something that is extremely important, as code changes so too should the tests, or else they wont work properly or even give false positives.

Number 10: Don’t Focus on Implementation. This one is interesting to me. We haven’t really spoken about implementation of code when it comes to testing. It’s very interesting to me because I have never really thought about this before, but it definitely makes a lot of sense to me. Something good to keep in mind for the future.

And lastly number 11: Create independent test cases. I actually unfortunately learned this myself the hard way with the first homework, as each class was accidentally dependent of one another if ran back to back. It’s something I definitely need to keep in mind going forwards.

And thats it! It’s definitely a lot of overlap which is great to see. Until next week!

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

Week 12

Considering that we have been working on the Mars rover for the past two weeks, I decided to find an article that correlated with this. I went straight to the source and found something about the actual Mars rover. I was able to find an article that piqued my interest. This article was specifically about the real rover and the people who worked on it. I chose this article to show the broad potential we all have inside the CS field that none of us even heard about. I hope to open your minds to all the possibilities you can do with code.

    The article begins by introducing the reader to Melody Ho a full-stack developer for the Nasa Mars website. She has a multitude of responsibilities she has to publish information about every mission and create data pipelines to be accessible to the public. Her journey began by working on a basic HTML book and playing computer games. She gives her reflection on her journey to inspire the next generation of women in space and technology. She most enjoys programming code that is efficient and adapting it to the best version of code possible. When she was growing up she was considering a career in computer games because she hadn’t yet seen the opportunities available for programming. She leaves the article by advising the next generation. She says to embrace new things and don’t be scared because these are opportunities that are needed to succeed. Technology is constantly changing don’t be discouraged if all doesn’t click it will take time.

   Reading this article gave me more of an introspective view of someone’s life in coding. This article doesn’t have much connection to the code we do in class but I think it’s very interesting to see the whole perspective of a coding journey. This article touches upon aspects that you may not think about every day but it gives much attention to what is important. Melody trying to inspire the next generation is very touching. She didn’t have to do this but she did. For me, it gave me a broader view of programming because sometimes you may have a tunnel vision of what you can do with your code but the possibilities are endless. There are a lot of connections that you may not see on an everyday basis. She mentioned how she double majored in business and I didn’t even see the correlation of coding in a management setting but it’s there. There are a lot of connections in programming with other skills there are some I haven’t thought about.

https://airandspace.si.edu/stories/editorial/coding-brings-mars-data-down-earth

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