Blog #5 – Observer Design Pattern

I decided to write this week’s blog on Observer Design Patterns because I am going to be writing a tutorial on this in class next week. I chose a tutorial posted by author Santosh Kumar on the blog “WalkingTechie”. I chose this blog about the Observer Design Pattern because Kumar gives an in-depth explanation of what an Observer Design Pattern is, how it’s implemented and gives UML and code examples of it which I found to be extremely helpful.

Kumar starts by giving a definition for the Observer Pattern, which he states “defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.” He also states that this is a part of the Behavioral Design Pattern.

Kumar furthers explains the Observer Design Pattern by giving a real-world example with a newspaper subscription. There are two variables – Subject and Observer. In this example, the newspaper publisher is the subject and goes into business by publishing newspapers. The observer is the subscriber who subscribes to a particular publisher, and everytime a new edition comes out it gets delivered from them. A user can unsubscribe which will stop papers from coming.

Kumar then implements the Observer Design Pattern. He defines a Subject interface that has a method to register, remove/unregister user and notify users when the object changes state. There is also a DisplayElement interface that has a display method, and an Observer interface and all concrete classes – BinaryObserver, OctalObserver, and HexObserver.

After constructing a UML diagram, Kumar goes through the code implementation step by step.

In the first step, the Subject interface is created. This contains the registerObserver and removeObserver and notifyObserver methods.

In the second step, the Observer interface is created. This includes the update method,

In the third step, the DisplayElement interface is created, which has the display method.

In the fourth step, a concrete class DecimalData is created and implements the Subject interface. Then a concrete class is created that implements the Observer and DisplayElement interface. And finally, the ObservePatternDemo class is created to use DecimalData and concrete objects to test observer design patterns.

I enjoyed Kumar’s blog explaining the Observer Design Pattern because he went in depth by defining the Observer Design Pattern, giving a real-world example, and implemented it by creating a java project. This really helped me understand the Observer Design Pattern more and it will come in handy when I do my tutorial on it.

Advertisements

Blog #4 – Design Patterns in Real Life

This blog that I chose to write about this week was a blog post titled “Design Patterns in Real Life” where the author Karthik Kumar creates his own examples of design patterns modeled after real-world situations to help him and the reader understand design patterns better.

http://karthikkumar.me/design-patterns

I chose this blog because I think it is important for those learning new programming concepts to get examples that relate to the real world because it helps them understand these concepts a lot faster.

Kumar begins his blog by explaining how after reading a popular book “Design Patterns”, he noticed that many of the examples used in the book were hard to relate to and the “Known Uses” of each chapter were outdated. To help understand the design patterns better, he created his own examples for each design pattern. In this blog, he explains patterns with his tangible, real-life examples.

Kumar starts off by explaining “Creational Patterns” which deals with how objects are created. They control how objects are built and can have a huge impact on improving the design of the system, it can also allow a system to be independent of how its objects are created.

He then goes into detail of a creational pattern called the Builder Pattern. This pattern separates how an object is constructed from its actual representation. It allows us to use the same general construction process to create different representations.

The real-world example Kumar uses for the Builder Pattern is the car manufacturing industry. In this example, he explains how when building a certain car according to specification, the manufacturer chooses several options about the car. This could include the color, engine, and any additional features. In this example, the client interacts directly with the builder to manufacture cars. The advantage of using the builder pattern is that we can construct cars with different characteristics using the same builder, and by specifying different parameters to the builder.

Kumar then explains Structural Patterns with deal with how classes and objects are built and composed as part of a larger system. He continues with the structural pattern the “Facade Pattern” which provides a single unified interface that encompasses several interfaces in a subsystem. It acts as a funnel to expose a single interface to many clients, and hides the actual subsystem that’s responsible for doing the work requested.

The example Kumar uses for the Facade pattern is Amazon’s 1-click ordering system. When ordering items, a customer is presented with a simple interface to purchase an item, but there are several complex processes running to enable an item to be purchased, and the user doesn’t see that.

Kumar takes these design patterns that may be hard for us to understand and uses everyday real-world examples to make understanding each design pattern easier, which I really like. I hadn’t looked at these design patterns in depth before and this blog helped me understand them quickly thanks to the examples provided.

Blog #3 – “Factory Design Patterns”

A topic we recently discussed in CS-343 was Factory Design Patterns. The factory design pattern is an object-oriented design pattern that deals with the problem of creating objects without specifying the class of the object that will be created. Creating an object usually requires complex processes, which may lead to a lot of code duplication and an insufficient level of abstraction. Factory design patterns handle problems like this by defining a separate method for creating objects.

http://javadesign-patterns.blogspot.com/p/factory-desig.html

I chose to write this week’s blog on this example of a Factory Design Pattern because I thought it was a simple example that makes understanding Factory Designs easy and also gives readers a straightforward understanding of Factory Designs.

The blog lists when to use factory patterns in a straightforward manner by stating that you can use factory patterns when a class does not know which class of objects it must create, a class specifies its sub-classes to specify which objects to create, or when at runtime you need to create an object based on input parameter.

The blog then gives a good example of Factory Design by imagining that we want to develop a Media Player application, which should play mp3 and mp4 format audio and video files.

In the example, the author creates a Decoder interface, a MP3Decoder class, a MP4Decoder class, and a player class. The problem that arises is that the classes MP3Decoder and MP4Decoder are tightly coupled with the Player class. This could become a problem if Player needs to support a new format because then a new decoder needs to be added to the Player class, so every time you would have to modify the Player class.

To fix this problem, the factory design pattern can be used. The author applies the factory pattern in this example by introducing a DecoderFactory class and moves the Decoder objects from the Player class to this new one, then by modifying the Player class to use the new factory class. With this new implementation, if the Player class needs to support a new format then no modification is required in the Player class because you will only need to put the new type of decoder in the Factory class.

I chose this blog because it efficiently explained the Factory design pattern, which we are learning in class right now, and gave a new example that helps further my understanding of the design pattern even more. It was simple and straightforward and did not leave me confused when trying to understand it.

Blog #2 “Design Patterns: Strategy”

A topic that we recently discussed in class is Strategy Design Patterns which is defined as a family of algorithms that are each encapsulated and made interchangeable. Strategy lets the algorithm vary independently from the clients that use it. It is best to use when many related classes differ only in their behavior and when you need different variants of an algorithm.

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

I chose to write this week’s post on a blog written by Scott Mason which is also on Strategy Design Patterns. I chose this blog because Masson explains Strategy Design Patterns by using a popular video game, Overwatch as an example and shows how Strategy Design Patterns are needed to make the game more efficient. This blog stood out to me because of the Overwatch example since I’ve played the game before.

The blog poses a problem. In Overwatch, players have the choice of playing as 21 different characters, and each character has 3 different attributes unique to them. During the game, the user is able to switch between characters when they die, so the game needs to run smoothly.

Mason shows what a poorly designed code would look like, where you have a class for each ability, but create an if statement for all 21 characters. This would result in 63 different cases which is too repetitive.

Mason poses the solution which is to create a series of classes known as strategies, one per unique character, that defines how each of the characters implements their abilities. This makes it so the Player class doesn’t need to know the specifics of how each character implements each of their abilities, and we can just pass a particular character to it. The new code that’s shown in the blog cleans up the program significantly so that new characters can be added with ease by creating different strategies with the same methods.

This was a nicely written blog that explains Strategy Design Patterns efficiently because it thoroughly went through transforming messy, inefficient code to code that uses strategy and is efficient. And what made this blog more appealing to me was that it used a video game I play as an example, which made it easier for me to understand everything going on in the code. This won’t appeal as much to people who haven’t played Overwatch though, but I enjoyed the blog and it helped me understand Strategy Design Patterns even more than I did before.

Blog Post #1 – “Unwanted Modeling Language”

https://blog.codinghorror.com/unwanted-modeling-language/

For this week’s blog post, I chose a blog from Codding Horror where the writer, Jeff Atwood discusses his opinion on Universal Modeling Language (UML). Atwood offers an interesting opinion on UML, because he does not think that it is an effective tool for organizing code.

I picked this blog because we just went over the section on UML in class and why it is an effective tool to use. Since we’re learning it for our course, we are given mainly the positives about UML and how it can help us code. So I think it’s interesting that there is someone out there who has tried UML before and isn’t a fan of it.

Atwood states that his problem with UML is that it can be interpreted as subjective, which he feels doesn’t fit with programming since it is not subjective. Another point the writer brings up is that UML isn’t bidirectional and that if UML changes the code isn’t automatically changed and vice versa. Atwood also believes that UML does not have any advantage over other forms of documentation. However, these are all one person’s opinions. That does not make everything Atwood is saying about UML a fact, but it’s an interesting opinion to read about.

It’s interesting to get another perspective on UML after learning about it in class, and I think that Atwood is valid to feel this way because the same form of documentation is not going to work for everyone. People prefer different ways to document code and will work with what suits them best. Atwood doesn’t speak for everyone when it comes to using UML and his opinions on it aren’t the only opinion. There are many people out there who think that UML is an effective tool to organize.

This blog does not deter me away from using UML because I haven’t tried using it in depth yet so I can’t say if I will find UML effective or not, but from what I read about UML in class, it seems like a helpful modeling tool to make planning code more effective. I may love UML and use it for all of my programs in the future, or I could be like Atwood and prefer something else.