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.

Design Patterns: Behavioral

URL: https://www.codingblocks.net/podcast/episode-16-design-patterns-part-2-oh-behave/
Like last week, I will again be talking about Design Patterns. Last week was the first podcast, specifically about Creational Design Patterns, of four that will be about Design Patterns. This weeks topic is all about Behavioral Design Patterns. Allen, Michael and Joe talk about three different kinds of Behavioral Design Patterns: Template, Strategy, and Null Object. Ironically my class started talking about Creational Design Patterns the week I had listened to that podcast, so it was cool hearing a summary about it, and then going more in depth with it. With this week’s topic, we have not yet talked about it, but it is a main subject that will be brought up in this class probably sooner than later.
So let’s first talk about Template Design Patterns. Template Design Patterns define the program skeleton of an algorithm in an operation, deferring some steps to subclasses. The example they give for this is that say a main method has an abstract class called Game. Inside that method you call to run, they have initialize some call, make move call, is end of game call and print winner. You can subclass this abstract class and override any of these methods and when you do that, the flow will always be the same. Essentially the flow is the same but each step can be customized by the sub class. This justs allows people when they write these other classes know that they are going to have to adhere to these guidelines, but then let them do what they want with these call methods. Pretty much Templates have you implement what you need and are very consistent. You need a header, body, and footer and every class that subclasses that class needs that same thing. It is more about a method, and a method already has a bunch of calls to other methods. The expectation is that you will override those other methods. Template Design Pattern is also referred to as the HollyWood Principle: Don’t call us, we will call you. The cause for this is because if you override that thing, when you call those abstract classes the wrong name, for instance, then it’s going to know based off of whatever the overrides were. It is just going to call those subclasses overridden, method call to it happens in the base class, automatically and never doing it in your own stuff.
Strategy Pattern is different and encapsulates a family of algorithms that are similar and makes them interchangeable within the family. SO pretty much, you can each of these classes contain just the algorithm and you can pass that class and change them around and call classes. The only thing is that these classe have to meet a common interface on execute method. Strategy Design Pattern is a pattern that ha probably been used before in people’s coding but was never thought about when creating that code.
Last was Null Object Pattern. If you want to provide a safe implementation that does nothing, Null Object Pattern is the right one to use. There are a couple reasons why Null Object Design Patterns are favorable. First, when you want to abstract null away from your client, you don’t want your callers to have to worry about null. You want to allow them to call your method and have it return something. It will always be safe and will work without a problem. AN example mentioned was that say you have a method and that method returns a list. Based on some condition, it does not return a list of anything in it for some reason. In that case, it returns an empty list, but in that way the caller could just automatically throw that into a for-each loop and try to iterate into it. Because the method does not call on anything, nothing happened and no harm no foul. “It almost leads you to feel safe” and kind of tricks you into not checking for null. They also mention how SIngletons and Null go together for Design Patterns. This was a bit confusing for me to understand so I am unable to go deeper into that topic. The way they end with Null is that is cleans up your code and gets rid of all the null checks. The simplicity of it is its beauty and the need for doing if-statements is lowered.
To conclude, I actually liked this podcast a lot more. Even though I liked the first podcast, it was really long and I had a hard time following along to what they were saying. There was just a lot of information to take in. This podcast was shorter by a half hour but I was able to retain a lot of it. For obvious reasons, I chose this podcast because it is what we are/will be learning in class. Although I feel like I understand a lot about what we are doing in class and what type of designs are doing what, it is nice to listen to a summary of it. In class I am learning specifically what code would look like if using that certain Design Pattern, while in the podcasts, I am learning about what they are capable of, and what they do as a whole. Also, of course, I am excited on how to use this Design Pattern in the future and how I will be able to implement it into future coding projects.

From the blog mrogers4836 by mrogers4836 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.

Levels of Testing

Source: https://blog.testlodge.com/levels-of-testing/

Another week into my blog for CS 443 this week I decided to look up blogs about levels of testing. While I was searching the web, I found a blog testlodge by Jake Bartlett he wrote a blog post titled “Levels of Testing In Software Engineering” here he talks about the levels of testing in software engineering. There are 4 levels of testing he talks about. Unit testing, integration testing, system testing, and acceptance testing. The first testing that most people do is unit testing. It involves testing pieces of code to make sure each one is right. With unit testing it helps verify internal design and internal logic, internal paths, as well as error handling. Unit testing is usually done by the developer who wrote the code. The second level of testing is called integration testing. This level of testing test how well each of the code works together. Each class is usually combined and tested as a group. This way it identifies interface issues between modules. The third test is called system testing with this kind of testing it test the entire application. This is done in a test kind of environment where the program would be sent out to. With this kind of test, the application is tested from beginning to end. This test is usually done by the testing team and includes a combination of automated testing and manual testing. Finally, the last test is called accepting testing. With this level of testing it test if the software is ready to be released. This kind of testing is mostly done by the business user and end user. With these levels of testing it show that testing is not just a onetime thing it is multiple test just like my other blog talks about. You have to make the right kinds of test and test often.

I chose this blog because I wanted to stay on the same topic I did for my last blog and keep with testing. I liked this blog a lot because it makes things easy and clear to understand and breaks each testing in to different levels and gives a clear description of what each of the testing is about. With testing ideas, I learned that you will never have enough tests. So, to make sure you are efficient when testing you have to break down your testing into different levels. I think the blog will help me a lot in the future because I will be testing a lot of code for class, school, work, and personal projects. Know what to these how to test and when to test is the best way to use my time efficiently.

 

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