Category Archives: Week 4

Turning the Big Ball of Mud into Modular Code

What Konrad Gadzinowski describes in the opening paragraphs of his post on “Creating Truly Modular Code with No Dependencies,” the “emotional rollercoaster” of developing software, is something that I’m sure anyone who has ever written a program has experienced. I certainly encounter this each time that I’m writing code for a project, whether it is an academic project or a professional one. Eager to begin a project, I often dive in and begin completing the simpler parts first. During this time, it seems that progress moves very quickly. After all of these easy, simple pieces are done, however, progress seems to slow or stall. As the requirements become more complex, I often find myself going back to previous code and rewriting things so that they integrate more seamlessly with the new element that I am adding. This problem is what Gadzinowski describes as the “big ball of mud.” Gadzinowski provides Apache Hadoop as an example of a program with the ball of mud interdependencies that slows further development and makes tracing the source of bugs more difficult. In the image below, each class is represented as a point on the outside of the circle, and the lines between the points are representative of a dependency.

(Image source: https://www.toptal.com/software/creating-modular-code-with-no-dependencies)

With so many interdependent classes, I imagine that untangling the web to trace bugs in Apache Hadoop would be a nightmarish task. Gadzinowski offers a solution to the problem of the ball of mud, however, that seems like sound advice. His suggestion is to use the element design pattern when developing software. This modular pattern aims to create reusable pieces of code that are independent of other classes. This is done through the use of element classes and element listener interfaces. In this way, all of the required dependencies for an element are encapsulated within that element. Outside classes that wish to utilize the element are not concerned with the underlying design of the element, they interact with the element’s listener. Gadzinowski presents this as a way to increase the flexibility of the element, allowing it to, for example, output to any number of different external environments through an identical listener call.

While I was immediately willing to listen to the post’s advice after it described a miserable situation that I’ve encountered countless times, I think that reading Gadzinowski’s explanations and examples of the element design pattern has certainly made me a believer. I think that what makes him so credible is his willingness to acknowledge the value in initially jumping into design without worrying too much about the big ball of mud that you may be creating. While this may not be the solution for a final release, it can get the ball rolling and allow for the element pattern to make your code more reusable and stable for production releases later on. I will keep Gadzinowski’s advice in mind the next time that I begin to worry that I have too many interdependent classes to make my classes reusable or easily maintainable.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

10/9/2017 — blog assignment Week-4

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.

10/9/2017 –Blog post Week 4

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.

B4: Multiton Design Pattern

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.

Builder Pattern

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.

Builder Pattern

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.

Anti-Patterns Part 2

So this week I have decided to pick up where I left off two week ago and discuss some more anti-patterns I have found. I find them to be quite useful as they are often easy to pick out/recognize, thus they are easy to avoid. This blog by Sahand Saba discusses several of them, but once again I will pick and choose a few as space is limited.

Have you ever been looking through some code and seen random, ambiguous numbers everywhere? I’m sure you have, so I am sure you know how annoying it is. These “magic numbers” make code hard to understand and can cause problems when trying to modify it later down the line. Always try to associate numbers with a variable or at the very least some sort of description to go along with it. It will prevent headaches and problems in the future. These “magic numbers” have always been a pet peeve of mine, so this just drives the point home further for me.

The next one I’ll admit I have a tendency to do, but after reading what Saba had to say about it, I am going to try and avoid doing it in the future. This anti-pattern is being afraid to add too many classes. The story goes, sometimes developers are afraid to add more classes and they think it will increase the complexity. However, in reality, it is just the opposite. Saba likens it to a tangled ball or yarns vs single strands of yards. Which is easier to work with? I think you know the answer. That example really made it clear to me that smaller, simpler classes really do make it easier and less complex.

Over analyzing is the last one I wanted to mention. This is basically thinking and discussing about a problem so much, that no work actually ever gets done on it. To avoid this, it is suggested that you break apart the problem into smaller pieces/iterations (a.k.a. Agile Software Development) and address them one step at a time. This way the overall problem is far less overwhelming and easier to deal with. I feel that this a very important skill to have and makes life a lot easier when dealing a massive, overwhelming issue. I always try to take this approach, although sometimes it can be easier said than done.

There are several other anti-patterns discussed including dealing with team meetings, management, etc., but since I am running out of space, I will leave them for another time. However, I wanted to reiterate that I feel anti-patterns are a great way to learn good coding practices. It is basically learning from other people’s mistakes and experiences, so hopefully their mistakes will allow you save some time and headaches in the future.

Link:

http://sahandsaba.com/nine-anti-patterns-every-programmer-should-be-aware-of-with-examples.html#magic-numbers-and-strings

 

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

Excuses Can Be the Death of a Product

As we find ourselves really getting into the thick of the semester, I still find myself going back to the same site to find stuff to write about for this class. I’ve found softwaretestinghelp.com to really useful and has provided me with some valuable advice. Now, about this week topic, which is “5 Excuses Every Software Tester Must Stop Giving”…

Excuses are wonderful thing when testing software as it often provides an out for when tests fail or don’t go quite as expected. It often takes a realist to get to the truth of the matter when it comes to finding the true bugs within a piece of software. This article discussed five in total, but there are two that stood out to me and since space is limited, I will focus on those.

The first one discussed is not having full control over a test environment. This allows one to blame the environment when a test doesn’t go as planned (i.e. claiming it wasn’t configured correctly). Although this can be frustrating, it can be beneficial as it gets your product out of the ideal, perfect scenario sandbox it has been developed it. It allows both the testers and developers to see how it can handle an environment closer to what it may actually be in when the product is released. Yes, technically it may not be configured correctly, but guess what, it probably won’t be in the real world either so it is important to see how it handles these situations. The article also mentions that if you really need control over the environment, you should work closely with whoever owns it. Either way, saying you don’t have control is really a poor excuse and I know personally, I will be sure to try and not use this as an excuse.

The other “excuse” that stood out to me is about not having the ability to do anything other than manual testing. In other words, you only have time to/are only allowed to do basic, by the book testing. The tester cannot collect metrics, run stress tests, etc. I agree that this often the case, but the article points out some good ways around this that I know I will take into account in the future. The main point of the work-arounds is that a lot of this “non-functional” testing may be able to be done while you are doing to regular testing. Instead of just running through the procedure, watch performance metrics at the same time for example. Maybe grab someone else to help with this rather than asking them after or doing it yourself. In other words, kill two birds with one stone. In may be a bit more challenging, but it can save time and allow for the testing to collect the information they need.

This blog provided some good detail on how to stop making excuses while testing. Excuses can kill a product as often time they are used in a way to avoid the truth. You may be able to push the truth off further down the road, but eventually it is going to come out, and one can only hope there will still be time to address the real problem.

Link:

http://www.softwaretestinghelp.com/5-excuses-every-software-tester-must-stop-giving/

 

 

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

Simple and Static Factories

http://coding-geek.com/design-pattern-factory-patterns/

 

This week’s blog, as with the last, will be about a topic directly covered in class.  And, more importantly, it’ll be necessary knowledge for the first assignment of my class making it a good choice to review.  The above linked article is about factory design patterns.  In class, we only covered the use of simple factories whereas this article covers factory method pattern, abstract factory pattern, and static factory methods as well.  Since I have a length limit, I’ll cover the most pertinent material first while focusing on things I learned outside of the classroom about their use.

Starting with the Simple Factory first.  The author informs us that a simple factory isn’t considered a pattern technically but notes that it’s prevalence requires covering.  They describe it as a tool that can be “to create/instantiate objects,” but it’s one that is rarely used.  More commonly a static factory would be used in java.  If the developer’s “factory method needs some instances to work” or “they need to instantiate the factory in order to use it,” then the simple factory works fine but a lazy static factory is still advised.

Since Static Factories are more resourceful it seems, lets discuss them in more detail.  The first use he notes is the static factory’s ability to replace a constructor to “create an instance. The first advantage I see from this is the fact that factories have names.  Any unique constructor name can only be used once in a class.  Any time a class would need multiple constructors with the same name, static factories can be used with more descriptive names to help anyone reading/working with the code.   Another convenience of static factories, as opposed to constructors, is that it doesn’t have to create an object when invoked.  This helps reduce creating duplicate or unnecessary objects.  One last noticeable boon is its ability to have stricter control over what instances exist.  Relating to the previous blog, this helps guarantee that a class is a singleton.

Although this concept was already covered in class, its importance requires mentioning.  A factory can return any subtype of its return type.  This, overall, adds great flexibility to the programmer.

The author does advise that factories (and most patterns) should only be used when necessary as they can make the code more difficult to understand.  Small personal projects most likely don’t require them but, they find good use when working in large projects.

This information, complimented with examples, was instrumental to my understanding of factory use and implementation.  Using factories seems like a great practice, when done appropriately.  It also is obvious that this is a core tool that I’ll need to have as a developer.  I know that this will be applicable to my immediate work.  But, beyond that, I’ll probably be using it on any project that requires me to create multiple instances of an object.  Especially when that allows me to avoid having to write nearly identical constructors repeatedly.  (Factories seem awesomely useful and a huge time saver.)

From the blog CS@Worcester – W.I.P. (Something catchy) by aguillardcsblog and used with permission of the author. All other rights reserved by the author.

Singleton has a Pattern of Landing Jobs

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.