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.
