Today I will be talking about a design pattern known as the observer pattern. In a blog put out by the website javapapers.com, the observer pattern is used when multiple objects depend on the state of one object. For example, Class A and Class B rely on the state of Class C and Class D to run. If Class C is in state 0 and Class D is in state 1, Class A will execute and Class B will not. If Class C is in state 1 and Class D is in state 0, Class B will execute and Class A will not. Class A and Class B need to be aware of the state of Class C constantly, and need to know when there is a change in the state of Class C. We can use do this by using observers for Class A and Class B. However, java does not support multiple inheritances; that being a class can’t inherit from more than one parent class. We can use the observer pattern to create observers for objects, which will help objects be aware of the state of different objects.

The blog uses an example using the relationship between a blog and a subscriber. The blog user subscribes to a blog for updates. When a new blog is added, users will be notified of the new blog. In this case, the user is the observer. The UML diagram for this example points out that a subject can have many subscribers. Both the subscribers and the users have implementation classes, which notify the classes of each other’s states. The implementation classes are “observers” in the UML diagram. The subject implementation observer gets and sets the state of the subject, while the user implementation observer updates to see if there are any new changes to the state of subject.

I selected this article to expand on my knowledge of software design patterns. I think they are useful tools to have, and each one has its ideal uses. The observer pattern is good for classes that are related and depend on each others states to function. I learned how I can implement observers for objects for these types of relationships. Now, instead of having the object looking for updates constantly working to search for updates, the observer will do it for them. This leaves the object totally out of the loop, and is only notified when the observer finds a change in state. I hope to implement this pattern in my future projects, as I think it is a great way to keep code efficient, neat, and organized.

Here’s the Link: http://javapapers.com/design-patterns/observer-design-pattern/

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Today I will be discussing the adapter design pattern. According to a blog by journaldev.com, the adapter pattern is a design that is used to make two unrelated interfaces work together. The example used in the blog by journaldev.com refers to phone chargers and sockets. In this example, a phone battery needs 3V to charge, and the wall socket can either be 120V or 240V. So how do we take either 120V or 240V and convert it to 3V to charge the phone battery? The article suggests using an adapter, which would be the phone charger. In this example, the two interfaces are 120V and 240V, while the adapter interface is the phone charger. I feel it is important to note that according to the article, there are two approaches to the adapter pattern; object adapter and class adapter. The object adapter uses Java composition to adapt and the class adapter uses Java inheritance to adapt. However, the article points out that both approaches will result in the same conclusion. For this article, I want to focus on the class adapter approach.

The class adapter implements a public Class called SocketClassAdapterImp, and it extends the Socket interfaces and implements the SocketAdapter. This Class contains methods to override the different voltages using get() methods, and within the get methods it will convert the voltages supplied to the correct voltage, and return the converted voltage. The test class will check to see if the conversions were done correctly; that being if the test class calls for Volt v3 = getVolt(socketAdapter, 3);, it should return the correct voltage (3).

I chose this article because I wanted to expand on my knowledge of different design patterns, and this one seems to be rather important (especially since I didn’t know anything about it). I learned a lot from this article. I have never run into a situation where I have needed two different interfaces to communicate and work together. I think that this is a great approach, and it seems to be rather simple and straightforward. I learned that in order to “link” two different interfaces together, that all I need to do is create an adapter for them, which will provide some sort of conversion method to satisfy the subclass. I hope to implement this in my future works, should I run into a situation where this is applicable. I definitely think it will save a lot of space, time, and headache.
Here’s the link: https://www.journaldev.com/1487/adapter-design-pattern-java

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Today I will be talking about an article called “Builder Design Pattern” put out by JournalDev.com. According to the article, the builder design pattern is used to fix some issues that arise when the factory and simple factory design patterns are implemented. The article points out three major problems that come up when using the factory patterns. The first problem is that there can be too many arguments to pass to the factory, which causes error due to the factory not being able to keep track of order. The next problem is that all the parameters must be passed to the factory. If you don’t need to use the parameter, you still need to pass null to it. The last problem occurs when object creation is complex. The factory will become complex, and it will difficult to handle. So what’s the solution to all of this? The builder pattern.

So what is the builder pattern? The builder pattern builds objects by individual step, and uses a separate method to return the object when it has been created. This is a great way to implement a “factory” pattern when the object you are trying to create has a large number of parameters. The article uses an example of the builder pattern by writing a java program that builds computers. Two classes, Computer and ComputerBuilder are used. The Computer class has a private Computer constructor, which has the required parameters as arguments. The Computer constructor sets all of the parameters, including the optional ones. Then the ComputerBuilder class is called; note this is a nested class. This class, in addition to being nested, is also static because it belongs to the Computer Class. The ComputerBuilder Class has a ComputerBuilder method which is public, and this method sets the parameters as this.parameter. The ComputerBuilder Class has two other methods used to set the optional parameters as this.parameter. The final method is a builder method, which in this case is public Computer build(), and this method will call the this.parameter arguments to build a computer object. Then it will return the object.

I chose this topic because I have experienced the problems mentioned above when using the factory pattern. If there are a lot of parameters to be passed, it can become extremely tedious to code. It also becomes very difficult to keep track of what’s happening as the code becomes more cumbersome to handle. I will definitely have to try implementing the builder pattern because it seems to function like the factory pattern, but in a simpler, easier to understand way. I really like the idea of only having to worry about required parameters and being able to set optional parameters outside of the constructor class. This eliminates having to pass null to the constructor, which should help with the compile time errors. This article uses java example, and it helped me really understand the code as well as the idea behind the code.

Here’s the link: https://www.journaldev.com/1425/builder-design-pattern-in-java

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Today I read a blog called “Creational Design Patterns: Factory Pattern”. I chose this because I was interested in furthering my understanding of the Factory Pattern, which we recently learned in class. The blog talks about how it is a creational design pattern, which means it deals with object creation. A good creational design pattern makes objects for a specific use; which is what this blog talks about. The blog describes the differences between the factory pattern (which is what this blog is discussing) versus the simple factory pattern as the factory pattern being a more complex version of the simple factory. The factory pattern has ways to abstract underlying classes from their superclasses. The blog uses a real life factory as an example to give the readers a way to understand the process. The factory is used to make objects for a user, without the user having to care about the internals of what happens in the factory. Basically, all the user has to do is ask the factory to make the objects, and the factory already has the instructions to make the object inside; relieving the user from having to feed the factory instructions on how to make the object. Another good thing about this point, is that now the factory can mass produce the objects. Say the user wants to make 100 objects from the factory. Instead of the user having to feed the factory instructions on how to make that same object 100 times, the user only has to tell the factory to make them 100 of the object, and the factory will do the rest.

I learned a lot from this article. I believe that it helped me further my understanding of the factory pattern. Why write the same code over and over again if you don’t have to? The example pointed out in the article is authors versus publishers. They point out that there are many different kinds of authors and many different kinds of publishers. Despite this, both authors and publishers of all kinds perform some of the same tasks, that being writing or hiring a writer, etc. So rather than having the same methods for each type of publisher and each type of author while overriding the rest to suit the specific author/publisher classes, we can take these generic “standard” classes and abstract them into factories that each type of author/publisher can inherit from, while each author/publisher class at the individual level will still have its own methods that are specific to that class. This will help me understand what I’m doing the next time I try to implement the factory pattern. I learned that I don’t have to repeat code over and over between classes, but rather I can just pull it out and make it a factory. I think it should be used whenever possible. It advocates for clean code, which is key to good programs.

Here’s the link: https://airbrake.io/blog/design-patterns/factory

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Today’s blog post is about the Strategy design pattern. I found a blog on the Strategy pattern called “Design Patterns: Strategy”. This blog talks about the pattern, what it is, and how to implement it. The Strategy pattern is a way to get classes to interact nicely with each other, and keep code somewhat clean and manageable. The author of this blog uses the video game Overwatch as an example to showcase how the Strategy pattern works. In the Overwatch game there is a superclass Player, and Player has many attributes. In this demonstration, the author labels these primary_ability, secondary_ability, and ultimate_ability. These are all subclasses to the superclass Player. This seems like a pretty simple relationship that is easy to manage, which is true until you find out that there are 21 forms of playable characters. This, in essence, means that now all of those classes get multiplied 21 times. This makes code very labor intensive and difficult to organize. There should be a way to connect each of the 21 different character classes to only one primary_ability, secondary_ability, and ultimate_ability classes; rather than write those classes out 21 times. Additionally, each of the 21 classes would have to be overriden to cater to the different character classes. To remedy this, the author creates a series of classes (or “Strategies”) to keep from having to write out the classes 21 times, uniquely each time. Now, each version of the character class can inherit the Strategies, which hold the basic methods, and tailor them to the specific character by overriding them. Then, the character gets passed to the Player class. In the end, the Player class just gets passed a character, without having to know any specifics of attributes.

I chose this article because we just finished learning about the Strategy pattern in class, and we have an assignment coming up which uses this. I want to fully understand this before I take on the assignment, because I want to do the assignment correctly. The Strategy pattern is a rather straightforward software design, but it is extremely effective. I think that this reinforced my understanding of the Strategy design, and helps me to clearly see how the classes relate to each other. Before reading this article, I had a good understanding of the pattern, but the examples presented in this article helped me really get what the Strategy pattern is all about. I hope that now I will be able to implement the Strategy pattern without any issues, when dealing with a parent classes that have a multitude of similar subclasses.

Here’s the link to the blog:

https://www.madetech.com/blog/design-patterns-strategy

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.