http://truptijethva.blogspot.com/2010/05/how-to-perform-decision-table-testing.html
This week we focus on decision table testing. Decision table testing is a black box testing technique, which, contrary to boundary value testing and EC class testing which tests for individual input conditions, tests for combinations of conditions. A more formal definition is that it is a table, which displays combinations of inputs and/or causes along with the associated outputs or actions. It is helpful for designing test cases. The advantage is that it ensures full coverage.
This blog post provides an example of decision table testing which takes us away from the common approach of using true or false as conditions. So, it gives a different perspective, demonstrating the versatility of the method compared to the other test methods mentioned before, which was boundary value testing and EC testing. The example is that with stub for flyer member and whether they are traveling in the business class or the economics class. The table rules uses yes and no, which is equivalent to true and false for the flyer member conditions, but business or economics class for the class condition. This shows that the conditions of whether the member is in the business or economics class can be collapsed into one condition, which is the class condition, instead of in two which would have been for example the business class and the economics class. This shows that the conditions from the assignments in class can be collapsed as well instead of creating equivalent classes which would make the rule counts more accurate and it would lessen the counts significantly as well.

For the stubs column the conditions are: for conditions we have flyer member and class. For actions we have upgrade to first and upgrade to business.

The rules are the following:
1. flyer member yes, class business, upgrade to first yes, and upgrade to business irrelevant.
2. flyer member yes, class economics, upgrade to first no, and upgrade to business yes.
3. flyer member no, class business, upgrade to first no, and upgrade to business irrelevant.
4. flyer member no, class economics, upgrade to first no, and upgrade to business no.

The question to ask is which rules follows these two test cases.
testcase1: Frequent flyer member, traveling in business class
testcase2: non-member, traveling in economics class

Matching the test conditions with the conditions and actions for the rules column, we have rules 1 and 4. This states that for testcase1 the following actions should apply: upgrade to first yes, upgrade to business irrelevant.
For testcase2 the following actions should apply: upgrade to first no, and upgrade to business no.

I chose this blog post because it is coming from a test lead in the software engineering field. So, this is an example of a real world application of decision table testing in software development. It gives an interesting perspective that decision tables can have conditions outside of the normal norm of yes or no and true or false and still provides to conditions of business and economics. This raises the question of whether or not a condition can have more than 2 variables in testing or is it more convenient to break up the solution into multiple conditions. In the latter case, this would increase the rule count. In the first case, it is using more than 2 variables in a single condition. The answer to this question probably depends on experiences with testing. But, it raises an interesting blog post topic of the advantages and disadvantages of breaking up conditions away from its normal norm of true and false. I chose this post because it gives a different perspective on decision table testing and raises some interesting questions on the topic about breaking up the conditions or not.

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

http://javarevisited.blogspot.com/2011/03/10-interview-questions-on-singleton.html
The topic for this week is on singleton patterns, but specifically for real world applications, on common interview questions that could catch any undergraduate students.
Let’s start with an introduction. Singleton pattern is a software design pattern that restricts class instantiations to one object, which implies that it restricts the class to global variables that can be accessed and changed anywhere in the code. Thus, the critics calls it an anti-pattern. Critics argues that it is overused in too many places where it is not beneficial. It introduces unnecessary restrictions where one single instantiation is not required, and it introduces global variables into the application. Thus, singleton patterns complicates the code. So, why is it useful? In Java, singleton design patterns are the most common patterns a software developer will see. It is heavily used in core Java libraries.
The article introduces 10 common interview questions and answers on singleton patterns in Java. I chose it because doing well on technical interviews is one of the most crucial aspect to landing a great career in this industry. This blog post is a learning step that any undergraduate students can reflect upon. We will only list 5 here, however.
The 1st question is the obvious: What is Singleton class? Have you used Singleton before?
The answer is the following: As stated above, Singleton is a class with only one instance. It provides global variables that are instantiated only once and can be accessed through the getInstance() method. The advantage is that it saves memory from having to instantiate the objects every time. Have I used singleton before? My background is mostly data analytics for the sciences. So, no.
The next question is: Which classes are candidates of Singleton? Which kind of class do you make Singleton in Java?
The author of this blog post commented that this is used to check whether or not the candidate has enough experiences with singleton usage or not. Are the candidates familiar with the advantages and disadvantages of singleton in Java?
The answer is the following: Any classes that would be available to the whole application and hold only one instance. An example is the Runtime class, since only one runtime environment is possible. Another is the utility classes like Popup.
The final question is, can you write code for getInstance() method of a Singleton class in Java? This tests the programmer’s ability to understand the code as well as the concept, since there can be many follow-up questions about the code that the candidate had written.
The answer is to not write the code with double checked locking until asked, since it is more complicated. Therefore, the chances of errors are greater. However, for more experienced programmers with deeper knowledge of double checked locking, volatile variable, and lazy loading, why not?
I chose this post as a reflection on interview questions that I could come across in the workplace. One of the most interesting questions I have been asked is what happens to a particle whose speed exceeds or reaches the speed of light. However, even in technical interviews for software development, I have never been asked questions about singleton patterns. So, this blog post was out of curiosity of the different interview questions that I could come across on singleton patterns in the workplace.

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

Multiton Patterns Explained

The article I chose this week explains a lot about the multiton design pattern which is very similar to the idea of the singleton pattern. It limits the number of instances a class can have by using a specific key for each instance and only one object can be made from that key. It uses a similar format to hash tables where there are values connected to specific keys. To be more specific, when an object is requested a key is passed to a static key generator method. If that key is brand new and never used before then the new object is instantiated and is returned after being linked to the key in memory. However, if that key has been used before than it will return the object that is already paired to that key. The article explains singleton as well by explaining that it ensures a class allows only one object to be created if there is only one access point. The key difference between the two being that singletons deal with one at a time while multiton allows the use of a map of named instances. The article then explains the design pattern using UML diagrams and specific examples.

I chose this article because we talk a lot about instantiation in class which is easier to digest as it involves simpler object-oriented ideas but these design patterns seemed a bit more complicated to me. The parallel this article drew to hash tables helped show off the similarities the system used with the concept of memory allocation. The content of this resource was quite dense as it was a lot of simple concepts woven together to create an intricate design which was difficult to understand at first. The first time I read the article, I didn’t understand any of it but after quite a few minutes it started to come together. The use of graphs and UML diagrams within the article helped with the basic understanding of what was happening to the objects. They also helped me learn the concept that a multiton pattern is essentially a group of singleton patterns all on a single map. This material affected me by explaining how multiton patterns work and how it uses instances of objects to create a key-object relationship. This all ties back to class where we will be learning about complicated patterns such as the multiton and singleton design patterns. These patterns will affect my future practice by helping my exposure to patterns and new ideas as this is my first time really dealing with patterns.

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

http://marxsoftware.blogspot.com/2013/10/too-many-parameters-in-java-3-builder-pattern.html

This blog post details a way to reduce the number of parameters required for a constructor: the builder design pattern. In this pattern an object called a builder receives each parameter step by step and returns the resulting constructed object at once. This blog post explains the pattern by using detailed code examples. First a Person class is shown without the builder pattern to demonstrate how too many parameters in a constructor can become a problem. Then a PersonBuilder class is shown which conveys the idea behind a builder class. Each variable is set in a setter method, then a createPerson method returns a new Person with the values from the setter methods as parameters. With this implementation, the values of a Person are set with methods as opposed to the parameters of the Person constructor. There is a lot more code, but it is much more readable than having a very large parameter list. The next few code examples show how a builder class can be nested and enhanced with the use of custom types and parameter objects.

The biggest advantages of the builder pattern are usability and readability.  Parameters are reduced and are provided in easy to read method calls. This approach also lets you acquire an object in a single statement and state. Also, it is even easier to apply an IDE’s code completion feature. The biggest drawback is that the number of lines of code are essentially doubled. Despite the fact that it is easier to read, the code is much more verbose. The author included examples of client code instantiating a Person with and without builders, which I thought was a good way to highlight the difference using a builder makes.

Instantiating with builders:

final Person person1 = new Person.PersonBuilder(
   new FullName.FullNameBuilder(
      new Name("Dynamite"), new Name("Napoleon")).createFullName(),
   new Address.AddressBuilder(
      new City("Preston"), State.ID).createAddress()).createPerson();

Without:

final person = new Person("Coltrane", "Rosco", "Purvis", null, "Hazzard", "Georgia", false, true, true);

As you can see, the builder implementation is extremely verbose but it is easier to read and harder to make a mistake. The more parameters there are, the more true this is.

I selected this blog after looking up design patterns in the gang of four book that we haven’t covered in class. I thought this blog did a good job explaining why this pattern would be used and the benefits and drawbacks of using it. I chose this topic because design patterns are one of the most useful things to learn as a software developer and if we end up covering this one in class I will be well prepared. I will definitely be applying what I’ve learned from this blog, as I’m sure every programmer knows how frustrating long parameter lists can be. I’m glad that now I know a design pattern that alleviates this problem.

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

http://marxsoftware.blogspot.com/2013/10/too-many-parameters-in-java-3-builder-pattern.html

This blog post details a way to reduce the number of parameters required for a constructor: the builder design pattern. In this pattern an object called a builder receives each parameter step by step and returns the resulting constructed object at once. This blog post explains the pattern by using detailed code examples. First a Person class is shown without the builder pattern to demonstrate how too many parameters in a constructor can become a problem. Then a PersonBuilder class is shown which conveys the idea behind a builder class. Each variable is set in a setter method, then a createPerson method returns a new Person with the values from the setter methods as parameters. With this implementation, the values of a Person are set with methods as opposed to the parameters of the Person constructor. There is a lot more code, but it is much more readable than having a very large parameter list. The next few code examples show how a builder class can be nested and enhanced with the use of custom types and parameter objects.

The biggest advantages of the builder pattern are usability and readability.  Parameters are reduced and are provided in easy to read method calls. This approach also lets you acquire an object in a single statement and state. Also, it is even easier to apply an IDE’s code completion feature. The biggest drawback is that the number of lines of code are essentially doubled. Despite the fact that it is easier to read, the code is much more verbose. The author included examples of client code instantiating a Person with and without builders, which I thought was a good way to highlight the difference using a builder makes.

Instantiating with builders:

final Person person1 = new Person.PersonBuilder(
   new FullName.FullNameBuilder(
      new Name("Dynamite"), new Name("Napoleon")).createFullName(),
   new Address.AddressBuilder(
      new City("Preston"), State.ID).createAddress()).createPerson();

Without:

final person = new Person("Coltrane", "Rosco", "Purvis", null, "Hazzard", "Georgia", false, true, true);

As you can see, the builder implementation is extremely verbose but it is easier to read and harder to make a mistake. The more parameters there are, the more true this is.

I selected this blog after looking up design patterns in the gang of four book that we haven’t covered in class. I thought this blog did a good job explaining why this pattern would be used and the benefits and drawbacks of using it. I chose this topic because design patterns are one of the most useful things to learn as a software developer and if we end up covering this one in class I will be well prepared. I will definitely be applying what I’ve learned from this blog, as I’m sure every programmer knows how frustrating long parameter lists can be. I’m glad that now I know a design pattern that alleviates this problem.

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

The Singleton pattern is a great topic choice for me this week. I sought to find a blog to strengthen my understanding of the Singleton pattern. But at the same time, I hoped it would offer insight as to what “Singleton related” questions may be asked in future job interviews. It turns out that such a blog does indeed exist, covering both of these inquiries!

Core Java Interview Questions: The Singleton Design Pattern by Sam

Sam begins by explaining the fundamentals behind design patterns. For nearly all programming languages across the board, design patterns are the conceptual structure and layout of our code, which establish themselves over time for being “tested and well-proven.” Not only are design patterns consistently brought up during job interviews, they are an intricate part of both object-oriented programming, and software development in general. This is important to me because I am always looking for ways to further my programming experience, for both myself and my future career.

So what is a prime example of a “conceptually tested and well-proven” design structure? According to Sam, knowledge of the Singleton design pattern is one of the primary requisites that employers tend to look for when interviewing potential candidates.

Most importantly, the job interviewer is likely to ensure whether or not the candidate knows what a Singleton is, and when/why we would want to use it. We can apply the Singleton pattern when we want to limit the creation of an object to a single instance. For an example of why this may be useful, Sam explains that it can make logical sense for the developer to have “a single go-to place in your application to get data on something.” I believe another reason why the Singleton pattern is useful is that it seems to make the layout of our code look elegant in a neatly structured way. I also feel that if we can limit the creation of needless objects, especially in large projects, this can free up a lot of memory that would otherwise be wasted.

Sam also notes that job interviewers may go a step further and ask the candidate how we create a Singleton pattern, perhaps in Java for example. Objects are created using constructors. Since the goal of a Singleton is to eliminate this ability, this can be achieved by creating a private constructor for the Singleton class. We can then provide a getInstance() method to make the Singleton object available.

I strongly suggest checking out Sam’s blog regarding the Singleton design pattern. I gave a basic summary on the subject, but Sam goes into further details regarding how to instantiate a Singleton pattern, as well as the strengths and weakness of this particular design. My main takeaways from this blog are the concise explanations and insights regarding the Singleton design pattern. Since it seems to be widely considered during interviews, hopefully my further solidified knowledge regarding this topic (due to Sam’s blog) will help me land a good job in the future!

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