We have an assignment coming up where we have to choose a particular design pattern and write a tutorial about it. I chose the Observer Design Pattern because the whole concept, a “Subject” notifying its “Observers” of changes, looked quite useful to me in real-life situations. To learn more about this pattern, I found a great multimedia article entitled Observer Design Pattern Tutorial by Derek Banas.

Derek states that the observer pattern is comprised of a Subject and Observers. Based on his explanations, I feel this a great design to use when we need objects to continuously receive updates when something changes, such as another object. He uses the stock market as an example, where the Subject is the “publisher” sending information of various stocks to the Observers (“subscribers”). The Observers can choose which stocks to view and if any of these are updated by the Subject (“publisher”), the Observers are notified. Using this scenario as an example was helpful to me because it helped validate the “real-life” necessity and importance of this design.

Derek provides a video giving a step-by-step procedure of how to translate his “stock market” example into an “observer pattern” code implementation. I found it very easy to follow and his explanations of the code very informative. Based on his explanations, I will give my interpretation of the related classes created and used within his code:

Subject is an interface that handles registering, unregistering and notifying observers of any changes.  StockGrabber is a concrete class that implements Subject’s given methods, along with ways to set and update a few example stock prices.

Observer is an interface that provides an update method which is called whenever the Subject changes. StockObserver is a concrete class implementing Observer. It allows the ability to assign each observer with a unique ID as they are created. Furthermore, the constructor keeps track of the total number of observers. This allows the Subject to know how many “subscribers” (Observers) it has, and what stocks they are subscribed to. The importance of this is that the Subject (“publisher”) must know which observers it should send updates to when necessary, and what updates it should send.

Finally, there is a main class GetTheStock that puts the above classes to use in such a way that we can see what the Observer pattern code is doing.

I have a few ideas of how I could implement my own version of the Observer pattern. Right now I am thinking of using this design pattern to keep track of the creation and updates of blog entries. For example, perhaps I will have a “BlogPublisherSubject” notify each “SubscriberObserver” whenever a blog entry has been updated.

Based on what I have learned reading Derek’s article and watching his provided video, I feel I have a solid understanding of the Observer pattern, which will surely help me in my upcoming project. I am confident that I will frequently implement this design pattern during my professional career as well.

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

In this article, Manoj Verma describes (in his own words) “an exhaustive list of factors to consider” in the choice of testing technique.

But let’s back up a bit.

I chose this article to write about (and this topic) because in our work last week we were tasked with testing a small play problem; and shortly after starting I realized that for all of my practice with different testing methods, I didn’t know where to begin.  So when I went to write my weekly blog post, that’s where I looked.

Verma’s list of factors is as follows:

1. Risk assessment — how tolerant to failure is the product?
2. Client requirements — did the client specify a testing technique?
3. Time/budget constraints — how long do we have to test?  How much money can we spend on testing?
4. Industry guidelines — does the product need to fit into some kind of regulation? Which ones?
5. Documentation — does documentation for the product exist?  Does it contain testing history?  Does it contain logical constructions such as decision tables or state graphs?
6. Objective of test — what are we testing for?  What does the product need to do, or need to never do?
7. Software development lifecycle — how is the development process managed?
8. Models used to develop the system — how was the software system built?  Are there logical models that can be adapted into testing techniques or cases?
9. Tester experience — how experienced is the tester?  How accurate is their assessment likely to be?
10. Flexibility — does the devlopment process model involve a lot of flexibility?

Verma also concludes that choosing the right technique “is not child’s play”.  It isn’t easy, and he doesn’t offer hard metrics, but his guidelines serve as a way for me to ask myself a series of questions and discover the method that may work the best.

My search for answers, as it turns out, did not give me any that are truly satisfying.  It led me to more questions.  Software testing in general can be seen as the act of asking questions of both the design and implementation.  It seems natural that software testing techniques and methods should also be subject to questioning; in fact, software testers should subject themselves to similar questions.

So what can I take away from this?  How can it help me move past the brand-new-problem paralysis?  That I should start by asking questions of the problem I’ve been presented with, and of myself and my own testing experience.

Article link.

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

In this article, Manoj Verma describes (in his own words) “an exhaustive list of factors to consider” in the choice of testing technique.

But let’s back up a bit.

I chose this article to write about (and this topic) because in our work last week we were tasked with testing a small play problem; and shortly after starting I realized that for all of my practice with different testing methods, I didn’t know where to begin.  So when I went to write my weekly blog post, that’s where I looked.

Verma’s list of factors is as follows:

1. Risk assessment — how tolerant to failure is the product?
2. Client requirements — did the client specify a testing technique?
3. Time/budget constraints — how long do we have to test?  How much money can we spend on testing?
4. Industry guidelines — does the product need to fit into some kind of regulation? Which ones?
5. Documentation — does documentation for the product exist?  Does it contain testing history?  Does it contain logical constructions such as decision tables or state graphs?
6. Objective of test — what are we testing for?  What does the product need to do, or need to never do?
7. Software development lifecycle — how is the development process managed?
8. Models used to develop the system — how was the software system built?  Are there logical models that can be adapted into testing techniques or cases?
9. Tester experience — how experienced is the tester?  How accurate is their assessment likely to be?
10. Flexibility — does the devlopment process model involve a lot of flexibility?

Verma also concludes that choosing the right technique “is not child’s play”.  It isn’t easy, and he doesn’t offer hard metrics, but his guidelines serve as a way for me to ask myself a series of questions and discover the method that may work the best.

My search for answers, as it turns out, did not give me any that are truly satisfying.  It led me to more questions.  Software testing in general can be seen as the act of asking questions of both the design and implementation.  It seems natural that software testing techniques and methods should also be subject to questioning; in fact, software testers should subject themselves to similar questions.

So what can I take away from this?  How can it help me move past the brand-new-problem paralysis?  That I should start by asking questions of the problem I’ve been presented with, and of myself and my own testing experience.

Article link.

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

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

The decorator pattern is used to “decorate” or extend objects with added functionality at run-time. This gives developers the ability to compose objects that are purpose driven for the current demands of their users.

In the blog post How the Decorator Pattern Saved My Day on CodeFX, Nicolai Parlog gives a real life example of how the decorator pattern was useful. He describes a scenario that involves a UI that triggers many different responses depending on the user’s interaction with it. However, different panes may have slightly different responses or needs. He then describes several different ways to implement this:

• Using one class which activates and deactivates different responses with flags
• Using inheritance
• Using the decorator pattern

In the first scenario you would end up with a behemoth of a class that would be hard to write, test, understand, and modify.

The second scenario is a better solution than the first one, however all it did was simulate flexibility, making it seem like you can pick and choose but you couldn’t. When he was trying to replace JEditorPane with FX’ WebView, he realized that WebView automatically triggered some of the responses that were implemented in the second scenario. This caused the whole system of classes to collapse. So he refactored the previous implementation to use the decorator pattern, replacing the original classes with the right combination of decorators. By using decorators instead of inheritance, the classes are easier to understand, it’s easier to test because there are fewer things happening in each unit, and it made the code reader for future changes. Instead of having to figure out where to put new functionality, all you need to do is create a decorator and add it where it’s needed.

The reason I chose this blog is because I have an assignment coming up on this particular design pattern and I didn’t really know what the decorator pattern was and what it was used for in a real world scenario. So I went to search for an example. This blog helped me understand when the pattern should be used and the benefits of using it over other methods like inheritance.  It also reminded me that just because you’re using a pattern doesn’t mean that your code is going to be cleaner or more efficient, but that you have to remember to only use it when necessary, which you can only do if you understand it.

Source: https://blog.codefx.org/design/patterns/decorator-pattern-saved-my-day/

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

The decorator pattern is used to “decorate” or extend objects with added functionality at run-time. This gives developers the ability to compose objects that are purpose driven for the current demands of their users.

In the blog post How the Decorator Pattern Saved My Day on CodeFX, Nicolai Parlog gives a real life example of how the decorator pattern was useful. He describes a scenario that involves a UI that triggers many different responses depending on the user’s interaction with it. However, different panes may have slightly different responses or needs. He then describes several different ways to implement this:

• Using one class which activates and deactivates different responses with flags
• Using inheritance
• Using the decorator pattern

In the first scenario you would end up with a behemoth of a class that would be hard to write, test, understand, and modify.

The second scenario is a better solution than the first one, however all it did was simulate flexibility, making it seem like you can pick and choose but you couldn’t. When he was trying to replace JEditorPane with FX’ WebView, he realized that WebView automatically triggered some of the responses that were implemented in the second scenario. This caused the whole system of classes to collapse. So he refactored the previous implementation to use the decorator pattern, replacing the original classes with the right combination of decorators. By using decorators instead of inheritance, the classes are easier to understand, it’s easier to test because there are fewer things happening in each unit, and it made the code reader for future changes. Instead of having to figure out where to put new functionality, all you need to do is create a decorator and add it where it’s needed.

The reason I chose this blog is because I have an assignment coming up on this particular design pattern and I didn’t really know what the decorator pattern was and what it was used for in a real world scenario. So I went to search for an example. This blog helped me understand when the pattern should be used and the benefits of using it over other methods like inheritance.  It also reminded me that just because you’re using a pattern doesn’t mean that your code is going to be cleaner or more efficient, but that you have to remember to only use it when necessary, which you can only do if you understand it.

Source: https://blog.codefx.org/design/patterns/decorator-pattern-saved-my-day/

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

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

Factory Design Pattern

To begin exploring Factory design pattern, first of all, we need to know what factories are. Factories are simply functions that create objects and return them. In most cases you can use factories to design to code instead of classes, and they are much simpler and more readable than classes.

Even though classes have a lot of better performance, it is a good idea to use factories unless otherwise you are in a situation that requires you to instantiates many objects.  For example, factories will take averagely 0.0004 milliseconds to create an object in most case while class will take 0.0002 milliseconds to create an object; classes will reduce the time to half way as compare to factories. This comes to matter when you are creating about thousands of classes but when your classes are not that much you will never notice the difference and hence, will not be necessary.

Why do we need factory design pattern?  Now let think of it this way; in our codes, we uses a lot of objects. We have classes that instantiate object from class and we use them in many difference ways. In a strategy pattern, we use dependency injection where we imagine ahead of time what the objects will be doing. But at some point in our programming, that imagination has to be constructed. That is we need to instantiate our objects and the question is, where do we do that? This is what factory pattern try to address. In this regards, we say, when you are about to instantiate, let encapsulate them such that it span uniformly across all places so that you can use factory whenever you want to instantiate and the factory is responsible for instantiating appropriately.

Factory pattern gives you the ability to create objects without specifying the exact class of object that will be created; a class is chosen at run time using polymorphism.

For the matter, one will want to use factory pattern design when a method returns one of several possible classes that share a common super class. It is also a good idea to use factory design pattern to design your code when you do not know ahead of time what class object you will need. It is again useful when all of the potential classes are in the same subclass hierarchy and when you do not want the user to have to know every subclass in your code.

I chose to explore this topic as because I was unable to understand it on the go when we were treating it in class and I also got confused as to which pattern to use for my upcoming project and I decided to write this blog on factory pattern because I am impressed how you can use factories instead of classes to provide a clear code. I am actually redesigning my previous code using the factory pattern and I can figure out that everything looks simple at this point.

Reference: https://airbrake.io/blog/design-patterns/factory

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

The blog that I chose this week was written by Trish Khoo.  She was previously a manager on an engineering team for Google Maps until she decided to leave and return home to Australia.  Her blog post (http://trishkhoo.com/2017/08/yes-all-testers-should-learn-how-to-code/) discusses the need for all testers to be able to effectively know how to code.  I was going through some of her blog posts when this post caught my eye.  I never realized that there was as big of a split as the poll showed that there is.  The Twitter poll showed that 55% of the voters believed that all testers should be learning how to code.  45% felt that is was not necessary.  This shocked me because up until now I was so rooted in the opinion that all testers should know how to code or be learning coding skills that I didn’t realize that it was even possible to be a software tester without having coding skills.  I believe that testers should have coding skills because it will help when writing tests and analyzing code to find the bugs.  If you don’t have coding skills then all you can really do is run pre-written tests and report back if it passed or failed.  With coding skills you can rewrite codes that may improve your test results and productivity.  Also if you are running white-box testing instead of just finding the bugs you can realize what the error is and what caused the failure.  Then while you may not be authorized to change the code at that time it can help you learn more and help advance your career.  Trish Khoo feels the same way and states her suprise that anyone would consider programming not essential in today’s software development workforce.  She has done some research and found that programming is being entered into the school curriculum in Australia, the U.K. and the U.S.  In some places even down to the elementary school level.  In a world that is constantly becoming more computerized and connected I’m glad to see that here in the U.S. we are seeing a basic level of programming as a necessary tool for entering the workforce.  At the end Trish Khoo also gives her reader two sites that are excellent starting points to start learning code.  The resources are both free and easy to navigate with step by step instructions on a wide range of languages and instructions for users of all ages.

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