Today I will be talking about the decorator pattern. I found a blog on the decorator pattern by Bambielli’s Blog. The decorator pattern, according to the blog, allows objects to have new responsibilities at runtime without changing any code in their underlying classes. The blog writer then makes a point to favor composition over inheritance because it can reduce the frequency of runtime errors. It also conforms to the “open for extension closed for modification” rule of good programming. Decorating a class is essentially extending objects to add functionality at runtime. This allows things to be more current and up to date for user demands. In the UML diagram provided by the blog, the abstract decorator class extends the abstract component, which gives the abstract decorator the implementations to be used in place of the component implementations. The decorator classes extend the abstract decorator class, and provide the abstract decorator class with the current overriden methods.
The blog uses a pizza shop as an example. Pizza can come in a variety of toppings and crusts. The decorator pattern allows us to construct any combination of pizza toppings. Concrete classes DeepDish and ThinCrust extend Abstract Class Pie. The decorator pattern comes into effect with the topping decorator. The Abstract Class ToppingDecorator extends Abstract Class Pie, and the ToppingDecorator class has two decorators, PepperoniDecorator and CheeseDecorator.
The blog points out some disadvantages to the decorator pattern, one being that decorating objects manually is a hassle due to the large number of parameters to pass. The solution to this? Use the factory pattern in combination with the decorator pattern to make the objects for you, eliminating you having to manually pass all the parameters.
I chose this pattern because I am always looking to learn how to improve my code and make it more efficient. Learning different design patterns is a great way to help my cause. The only thing about design patterns is that they aren’t always widely applicable. Most design patterns are specific for a small number of cases, so learning more design patterns helps me to overcome more situations that I face when coding. I think this blog really helped my understanding of the decorator pattern. I had looked at a few before this one, and the decorator pattern seemed to be pretty vague to me. The pizza example in this one really helped solidify my understanding of this pattern. All the examples from the other blogs had lots of code samples, and not a lot of explanation. Though simple and basic, I really liked the pizza topping example. I hope to apply this in future practice. I would like to have a program that allows users to make a number of different combinations (such as a sandwich topping program, or a car customizer program (color, size, etc.)). This pattern seems to be really effective with being able to create whatever combination of choices the user asks for.
Here’s the link: http://www.bambielli.com/posts/2017-04-02-decorator/
Angular’s OnPush strategy is used to change detection strategy. This is used to reduce the number of checks angular makes when there is a change in an application. When the author applies this to his application, he is able to reduce the number of checks. How does he apply this to the code? All he has to do is change the detection strategy by adding a few lines of code in the BoxComponent (part of the application that draws the boxes). He uses something along the lines of “…changeDetection: ChangeDetectionStrategy.OnPush…”. He then exports his components, which are now implementing the OnPush detection strategy. After rerunning his code, the optimized runtimes are now ranging from 21ms – 44ms, a drastic improvement over the default code.
I chose this blog because I have a project to do in angular, which I am very new to. I have always been a fan of optimized, clean, and readable code. Nobody likes code that takes forever to run, and nobody can understand code that is a big mess of spaghetti. I have always strived to make my code minimal, clear, and concise. This is because it makes it easier for me to go back and fix, review, or do whatever I need to my code. I think optimizing code is super important, because slow programs aren’t practical. I hope to implement this strategy when I make my angular project. Even if I don’t get the chance to tinker with the detection strategy, I would at least like to look into Chrome’s devtools and measure my project’s performance.
Here’s the link: https://blog.thoughtram.io/angular/2017/02/02/making-your-angular-app-fast.html
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/
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
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
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
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: