Breakable Toys was an interesting pattern to read about. The premise is that in order to develop your skills, you should spend some time single-handedly developing small software projects. The example the text gave was maintaining a Wiki, which over time develops many skills in different areas. Ideally you will be able to find enjoyment in your toy so you can continue to grow from it. This toy is also something you can take with you, and something you can continue to learn from.
The idea of Breakable Toys was one I’d never really thought of before, but after reading it I can say that I’ve probably used the pattern to some extent. I can recall a time where I was learning HTML and CSS just to customize a web-page on an online game. At first, I had no idea what I was doing, but after some research and a lot of experimentation and trial and error, I began to have a much better concept on designing a web page. Meanwhile, I was enjoying the learning experience and the progress towards building something of my own. The ability to find enjoyment in what you learn is what eventually lead me to where I am in the first place.
After having read the chapter on Breakable Toys, I think I will try to be more intentional with my use of interesting and fun things that simultaneously develop my programming skills. One idea would be to develop a game in a new language, that way I can learn a new programming language and do something I enjoy. Eventually, I can also develop the same game for any new programming language I wish to learn, as an interesting way to see some of the differences and similarities between them.
Something I’m learning about a lot of these patterns is that they are all sort of things that people just tend to do naturally to try and aid their own development. I guess that’s the whole point of the patterns, but it is really insightful to have some of these ideas put into words.
The State Behavioral Design Pattern is one of the GoF Design Patterns. In his series on the Gang of Four design patterns, John Thompson wrote an article on the State Pattern, which he defines as “an important pattern that allows an object to change its behavior when it’s[sic] internal state changes.”
He opens the article by providing an example of a Vending Machine program that will need the State Pattern to be applied to it. One thing I like about the way he writes his examples is how he uses variable names to make it very readable. He could have just had the states as the integers themselves, but his simple and clever use of variable names has given me ideas of how to make my programs more readable in the future.
In order to transform his Vending Machine program from a “monolithic class” into a more adaptable program, John shows us how to implement the State Pattern. He separates each of the four states of the vending machine into their own classes. They each implement an interface that defines the behaviors of the vending machine. These state classes each detail how they handle the behavior in that state. Finally, the vending machine itself which handles the inventory of the vending machine and has methods a lot of methods to handle changing the state of the machine.
Due to designing the code with this pattern, you can add a new state by creating a new concrete class and modifying the vending machine class to handle it. However the currently written states are closed to modification as well, following Open Closed principle. When you compare the example before and after the State Pattern was applied, it becomes apparent why it is so beneficial to use this pattern when it’s appropriate: it makes your code more open to modification and more easily-understood. You don’t have to spend as much time reading and understanding code under the State Design Pattern, and so it helps make your program easy to maintain, especially when multiple people might be going back to the code later. Having more classes isn’t necessarily a bad thing.
The article I chose to cover for CS-443 this week is a research article titled Decision Graphs and Their Application to Software Testing by Robert Gold. This article goes in-depth on one of the subjects covered in our Activities, DD-path testing, as well as other decision-based testing methods. One of the things I like about this article is that it uses a lot of mathematical notation and logic to represent how the methods work. It also has very detailed proofs to show why the necessary branch/edge coverage is reached. There are several different examples of code that have corresponding decision graphs, to show the different parts of making a decision graph.
Looking at the example of the function f1 given in the article (Figure 3), there is something this article did with DD-path graphs that we did differently in class. whereas our DD-paths were just all the nodes in between with an in-degree and out-degree of 1, when Robert combines several D-nodes into one DD-path, he includes the first node that has an in-degree of 2 and the last node which has an out-degree of 0 along with the rest of the nodes. Therefore, his DD-Path graph for f1 is a lot simpler than what we would have made doing what we did in class. I’m curious which way is better. The article also dives into a topic about path testing we discussed but did not have an example of, that is when code branches into multiple different endpoints. In order to achieve branch coverage in these examples, you have to have multiple tests with different inputs that satisfy every branch.
Overall, the abundance of examples in both code and their associated graphs, as well as the very clear mathematical notation and rigorous proofs makes this article a really interesting read if you are a Mathematics major/minor. The conclusion at the end details a major application of this are modeling programs with flow graphs to represent programs. There are many different kinds of decision based testing methods that you can use, and if you have any questions about one of them or how they work, this is an amazing resource.