How to Make the Perfect Singleton

In our Software Construction class, we have been going over the design patterns used by developers everywhere. Our last test covered all of the design patterns, and after I got the test back, I decided to research more into the design patterns topic and I found the article, “How to make the perfect Singleton?” I found this article whilst browsing the internet looking for other articles, and this one jumped out at me.

The article starts off by discussing the purpose of the Singleton. I liked this section of the article because it provided some specific examples of when this pattern would and should be used. For example, it said it is “used when you have to control resources” (Patel), and it is used in database connections or sockets.

The article then goes on to show the reader how to create the perfect Singleton. It explains how to initialize it, and it explains how to make the class thread, reflection, and serialization safe. I actually didn’t know what it meant to make a class thread, reflection, and serialization safe until I read this article.

The interesting part of this article is how many new terms it introduced me to. The volatile keyword was brought up in this article, and I personally haven’t seen this keyword anywhere in my few years at Worcester State. The volatile modifier makes it so that the write of a certain variable is guaranteed to happen before the read of said variable. I also learned that making classes thread safe is essential for any “multi-threaded application environment” (Patel). They use Android applications as an example. I also learned how to make my Singleton class safe from Serialization, which is simply just preventing others from creating new instances by serializing and deserializing the singleton. I also learned how to prevent Singleton failure due to reflection. This was also very simple as you just have to throw a run-time exception in the constructor.

This article was a great read and contained a lot of useful information. I plan on using this information that I obtained in the future when I create more classes using the singleton pattern.

 

Link: https://medium.com/exploring-code/how-to-make-the-perfect-singleton-de6b951dfdb0

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Journey into Design Pattern a Adapter Pattern Explanation

As I take another step towards my journey in software C.D.A. I dive into Design Pattern, where I will be focusing on one of the patterns known as Adapter pattern. While searching in the internet I ran across a blog called Design Pattern Explained – Adapter Pattern with Code Example by Thorben Janssen.  This blog talks about Adapter Pattern which actually is one of the many Design Pattern type. This topic is chosen because it was one of the pattern talked about in my Software Construction, Design, and Architecture class. Since the blog by Thorben Janssen talks about the topic related to a class discuss topic, I choose this blog to write about it and summarize its content in my blog. The content in the blog is about the Adapter Pattern of Design Pattern. I will give a summary of what the blog was about and what it explained from my point of view and understanding.

According to Thorben Janssen research on Adapter Pattern, there are two different version of it. The type that uses inheritance and the type that uses composition.

What is Adapter pattern?

Also known as wrapper, the Adapter Pattern is a software design patter that allows the interfaces of an existing class to be used as another interface. In software development the adapter pattern has the same concept of those in real life, for example phone adapters.  Meaning adapter patter are similar to phone power adapters in the sense that one adapter can be used with many different USB devices cable. Say your at your friends house and you have an i-phone USB charger cable but no power adapter, and lets say your friend owns an android and only has an android charger. He can unplug is USB android cable from his power adapter and hand you his power adapter for you to use with your USB i-phone cable so you’ll be able to charge your phone. An adapter is convenient because it enables incompatible objects or devices to be used for the same purpose. The adapter pattern is also convenient because it allows you to use existing class or interface by introducing a new class that adapts between classes and interface without changing the existing class that is known as an adapter class.

In the blog “Design Patterns Explained – Adapter Pattern with Code Example” by Thorben Janssen he gives an applied example of the adapter pattern he referrers it as Brewing Coffee. I highly suggest you to click on the title so you can check out the example and see how he implements the adapter. I will end my blog here and let you do your own research on adapter pattern.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

The Process of Reviewing Code

Since CS-343 is meant to teach us about how to craft and design better code, I figured it would be important to first identify the key components of reviewing code, whether it be your own or someone else’s. To do this, I used the article “Yet Another Code Review Best Practices” by Pawel Ochman as my main reference.

He begins by describing some of the reasons for reviewing the code, leading into a few tips and things to look for, ending into a note about how to maintain the code after your review. With all of this information, a few key things stuck out to me:

  • Prior to reviewing the code, you must create a goal. There can be a single or multiple goals, but no matter what all code reviewers must have common goal(s). Some examples of these goals include:
    • Eliminating bugs at an early stage
    • Improving code quality
    • Increasing knowledge about the project
    • Learning from each other
  • The most important principles to follow when reviewing code are quality and motivation. In this context, quality is the principle of making sure that every time you review code, you review it to the best of your ability. Similarly, motivation is the principle that plays as a constant reminder of the values of code review to keep the team/yourself feeling positive about the review/editing.
  • Positive feedback after reviewing the code is important for whoever’s code it is. The values of code review outweighs allowing it to continue to be inefficient or ineffective in functioning/solving the problem (whatever that may be).
  • The most important point is that you don’t have to be an expert:

It’s a great chance to learn something new. If you are not sure whether solution is correct, you can start a valuable discussion. As a team member you should be able to work on any area of the project. Don’t allow any person to be the only expert in specific part of an application. You should be able to replace anyone in case of his absence.

All in all, this was a great article to learn from as it allows you to see the benefits of  code review through each stage. With small pieces of advice, it transforms what may be a painful process into a more positive one.

 

From the blog CS@Worcester – Fall 2018 Software Discoveries by softwarediscoveries and used with permission of the author. All other rights reserved by the author.

Keep it Clean for the Rest of your Team.

While reading Petri Kainulainens blog (https://www.petrikainulainen.net/writing-clean-tests/) it reminded of something we had learned in class. What we were told was keeping clean and concise names is vital to the testing process. This is reiterated in the blog by Petri clean code is described as a universal understanding of the code for everyone involved. What happens is everybody can create code that makes sense to them, but words can mean something completely different. I think a good example of this would be the use of acronyms if you use GCD to get the greatest common divisor but don’t clarify this of course you can make sense of it, but what about the programmer that comes to write code for your test? This is where the problem would come into play, and the importance of clear code is vital. Along with the avoidance of confusion Petri makes two more points:

  • If our tests are easy to read, it is easy to understand how our code works.
  • If our tests are easy to read, it is easy to find the problem if a test fails (without using a debugger).

On the post is also offered a list of other blog post about writing clearly that I plan to explore at a later date. However the reoccurring theme is short, clear, and concise is the best way to write your tests. Through the tools offered by Petri, and further knowledge learned in class I plan to evolve my testing clarity to be immaculate. After all if you keep it clean it’s in the best interest of the rest of the team.

-Andrew

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

Agile Testing

For today’s blog I am writing about agile testing. I found this blog on agile testing called “A Coach Guide to Agile Testing”. The blog talks about the different types of agile testing and the different types of teams/groups/personalities that use agile testing in different ways. The article mentions that people who use traditional ways of testing usually do not like agile testing because they consider it a threat to their job, which is to identify discrepancies between the working system and the specifications. This is different from agile because agile does not have specification documents that are detailed enough to help the tester do their job.  Something I found interesting about this article was when they were talking about the traditional testers and their approach of “follow specifications and report how the system differs from these specifications”. The article says that checking to see how closely the program follows the specifications does not actually say anything about the quality of the program. I think this point really hit home, because you can make a program that follows the specifications to a tee, and it can still be a poorly designed or poorly running program.

For an example, say you are building a program to manage someones bank account. You would need methods to deposit, withdraw, check balance, transfer money, etc. Now let us say the only specification for the program is that it compiles and runs. We could write a program that compiles and runs and in the sense of traditional software testing, we have a passing program. However, what if the method for deposit didn’t actually add money into the account, or the method for withdraw added money instead of taking it out? According to traditional software testing we have a functional program, when in reality we know our program does not do what it is supposed to. This is where agile testing comes in handy. Agile testing will test every method in our program (not just the specifications) to make sure that our methods actually do what they are supposed to. This is why I like agile testing, and try to do it in all my programs. It is a good way to assure you have a quality product that functions as designed and has also been tested and passed. I hope to continue using agile testing in my future programs and reading this article has given me some new tips and tricks to think of when doing agile testing.

Here’s the link: http://www.softwaretestingmagazine.com/knowledge/a-coach-guide-to-agile-testing/

 

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

B4: Test-Driven Development

https://www.imaginarycloud.com/blog/test-driven-development/

          This week I’ve decided to write about a blog post that talked about Test-Driven Development (TDD) and its benefits as well as its drawbacks. The post begins by explaining that TDD is the writing of automated tests before actually writing a feature for the product. It gives an example using social networking software and how a coder would first write an automated test and then write the minimum amount of code to pass that test. It uses the “red/green/refactor mantra” to show if tests have passed or failed. The post goes into the benefits of TDD by explaining that sometimes new code can break previous features. This is similar to regressions in the software development path. Using TDD, you are able to test the code before integrating it into the system to see if it will actually work. The blog explains that even though TDD can double check a new feature integration using automated tests, these tests have their drawbacks. One drawback that the post focused on was the overall cost of these automated tests that increased the cost of development cycles compared to those that continue on without them. It continues to say that automated tests aren’t a requirement for every single feature since there is no formal test plan.

            I chose this article because I had read about Behavior-Driven Development on my last blog post and it was constantly compared to Test-Driven Development. I wanted to gain a better understanding as to what TDD was and why it was compared to BDD. I found that this content answered those questions very well by explaining what TDD was while giving its strengths and weaknesses. I enjoyed how the post used examples from software development tracks in real situations to explain this concept. It allowed me to better understand why it is a safer system from new feature integration. I was able to grasp an understanding of when to use this development tactic while also learning that there are times to be cost-efficient as well. I found the parts that talked about how much is really needed with TDD to ensure cost-efficiency very interesting because it really puts into perspective how important budgeting is. I learned a lot from this blog including what TDD is and when to properly use it. I found that the examples were a great resource to understanding the term within context. This blog is a great source of information about TDD and I found it very interesting.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Spending Testing Time Effectively

For this weeks blog for the topic Quality Assurance and Testing, I read an article titled “5 Reasons you are wasting your testing time.” That is not to say that testing is a waste of time, but rather as the first sentence says, “Not all our testing time is spent effectively.”

The blog goes on to list the five reasons that a programmer might be using their testing time ineffectively, which are as follows: (1) “You don’t set a clear goal for your testing task;” (2) “You don’t understand the value of the feature for your End User;” (3) “You do not keep track of what you tested, your findings and the other ideas you got while testing;” (4) “You do not consult existing information to get insights into your test;” And (5) “You do not do post-test reviews and feedback sessions with your peers.”

These are all straightforward ideas, but I’m sure most programmers testing their code have fallen into several of these, if not all. This list provides a framework to avoid these pitfalls. In class, we have been going over ways to be more methodical when testing. This list is a little more elementary than what we have covered, but it is good information to use nonetheless.

A key takeaway is to treat testing more like a science than throwing it together willy-nilly. There has to be a method to the madness. You have to know what you want the test to do. You should have a clear understanding what the end product should look like and how it should look to the end user.

The final section in the article said testing isn’t “Rocket Science, but it is not a trivial task either.” It should not be seen as something that could be done by almost everyone, which is a common belief in the industry. This is not true. It is an important job that should be done right. It requires being very organized and staying on top of things. There are many things that can be done haphazardly. Testing is not one of them.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Java Singleton Design Pattern Best Practices with Examples

This week blog post is about Java Singleton design pattern. The reasons for Singleton pattern are to restricts the instantiation of a class and ensures that only one instance of the class exists. This article explains and show examples of the many different approaches of Singleton pattern implementation, the problems with the approach.

The approaches of Singleton pattern implementation:

  1. Eager initialization – pros: easiest way to create a singleton class | cons: instance variable is created even though it might not be used.
  2. Static block initialization – Similar to eager initialization but provides option for exception handling.
  3. Lazy initialization – This is the approach that was we used in class and it’s a completely fine for a single threaded environment, but potential can cause problems for a multi-threaded environment.
  4. Thread Safe Singleton – resolutions for Lazy initialization but reduces performance. Requires synchronization.
  5. Bill Pugh Singleton implementation – Best method for singleton implementation. Contains a inner static helper class by doing so the instance is not created unless someone calls on the getInstance() method. Doesn’t require synchronization.
  6. Using Reflection to destroy Singleton Pattern – This approach destroyed the singleton pattern.
  7. Enum Singleton – resolution for reflection method. Not flexible. Any enum value is instantiated only once.
  8. Serialization and Singleton – Use to store it in file system to retrieve it later. Cons: when deserialize it creates a new instance of the class.

I found this article very helpful with understanding Singleton design. This article explains to me when to use and the consequences that comes with each different implementation. The content of this blog was the best. The example code of this article was very clear and made easier to understand the materials. This change my way of using this method because I now know which method to choose in certain situation. The lazy initialization will be used more while I’m in school, but I think Bill Pugh method will be used more in the future because it’s very popular and it’s easy to understand. I agree with all the contents, but I read the comments of the other readers and they had some issue with some of the content which I have to read more about the subject to find out what’s right and wrong.

https://www.journaldev.com/1377/java-singleton-design-pattern-best-practices-examples

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

What is Behavior-Driven Development?

This week’s topic has to do with behavior-driven development, which a strategy of software development that focuses on the communicating narrative between developers so as to ensure that all members understand the specifications and other requirements of a program. I found an insightful article at the following website: https://airbrake.io/blog/software-design/behavior-driven-development. This blog post is one of a few in a series explaining different development techniques that work together as part of the software development life cycle.

As explained in the article, behavior-driven development, or BDD, works hand-in-hand with other strategies, such as test-driven development, which entails the execution of a failing test and then subsequently writing a minimum amount of code in order to pass the test. The BDD of tests becomes different from this technique when it relies more on the desired behavior of the program, rather than simply writing initially failing tests for all parts of the program, as utilized with test-driven development. BDD defines behavior specifications with user stories that outline various scenarios for the program to be executed or tested. These stories take on a narrative tone that states who and what are involved in each scenario, as well as the conditions that must be met in order for the scenarios to be successfully implemented. By using a common language understood and easily communicated by everyone on a development team, members can easily collaborate to define these specifications and perform tests based on the definitions given with the user stories.

This topic stuck out to me because it somewhat combined what I have been learning in both my Software Design and Software Testing courses this semester. This post discusses different methods of designing programs and their tests, and I thought that BDD clearly incorporated both, with the description of designing the behavior specifications to be met, as well as the concept of testing these specifications. We’ve somewhat been starting to take on both of these roles in the classroom by determining the purpose and desired functions of our programs, and then performing tests to ensure that the functions are working successfully. While we haven’t written out user stories to more specifically outline the behaviors, I think that this process is more implicit for us at this point.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Test Automation

https://abstracta.us/blog/software-testing/test-automation-patterns-and-good-practices/

This blog post discusses good practices to use with test automation. Automating tests can save time and decrease the amount of work that has to be done. Following these practices will help ensure that you get the most value out of automation.

Test Code Review

  • All levels of testing should be reviewed to examine their quality. This will help the tester discover bad practices or mismatches in the tests.

Apply Assertions

  • Assertions should be used to identify problems.
  • An assertion that’s too generic can create false negatives and false positives, so pay special attention in the definition of assertions.

Behavior-Driven Development (BDD)

  • A common language should be created for the business and engineers to be used as a starting point for development and testing.
  • User stories are defined and used as input for test cases.
  • BDD gives developers clear specifications and brings testability to a system.

Page Object Pattern for UI Testing

  • The use of design patterns increases scalability and maintainability
  • The page object pattern allows you to reuse knowledge of the structure of an application while having a minimal impact on tests.
  • This pattern strengthens tests by decoupling the structure of the user interface from the test code

Data-Driven Testing

  • With data-driven testing, automated tests are parameterized so that the same steps can be carried out with diverse amounts of test data
  • Adding data to the file creates new test cases

Parallel Execution of Tests

  • Using parallel execution options like Selenium will reduce testing time by running several tests at the same time.

I thought this blog was very interesting. While I have learned a little about test automation I haven’t used it enough to learn the best practices for it. It is important to learn these practices because the whole point of automation is to save time, and if you don’t do it correctly you will end up spending more time trying to fix your errors.

I thought the most interesting part of this post was the section on the page object pattern. This is a design pattern that I’ve never heard of. It seems to be very useful because it helps prevent you from breaking your tests when you change your code. This is a topic that I would like to learn more about and will keep in mind when I work with automated testing. Overall I thought this was a useful and well-written blog post.

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