URL:https://www.codingblocks.net/podcast/design-patterns-iterators-observers-and-chains-oh-my/
I know it may be a little redundant, but again like the past two weeks, my blogpost for this week will be about Design Patterns, but it will part three of four of the Coding Blocks Design Patterns Saga. This time though, the podcast did not focus on a specific kind of Design Pattern, but instead their favorites. In this week's blog I will be explaining what was discussed on the podcast in detail, examples that go along with it and what I had learned from it. The three Design Patterns summarized today are Observer Pattern, Chain of Responsibility, and Iterators. So, Observer Patterns maintains its dependences by notifying them of events by calling a method on the dependent. So in a nutshell when an object, which is called a subject in this case, maintains a list of its dependents and notifies them automatically of any state changes usually by calling one of their methods. The downside of this is that it can cause memory leaks. The class that is adding these response headers to this element has got a strong hold of these objects. If they are never disposed of or the garbage collector never gets them properly, all these objects just stay alive and never get taken away. An example is a notification example on your phone. It doesn’t care what someone else’s phone does with notifications. Notifications are sent from the server to my phone that I am subscribed to and I am notified of events in some way. I don’t care what happens on other people's phones, but I respond in a certain. Visualize a pubsub environment, each responder of each element can happen independently from the other and it doesn’t matter how they respond. The other downside is the abstraction layer hopping. It is pretty much when the layers in between are ignored and shortcutting the system. The second Design Pattern was Chain of responsibilities and there is no strong use case. So to start off with an example, you are part of a large company. THis company had a purchasing request. If the request was under $50, it is approved. If it is greater than $50 but under $250 the manager has to sign it off. If it is greater than $250 but under $500 the accountant takes care of it and if it is under $5000 but greater than $500 the CEO decides. So while this is a bad example of inheritance, you inherit from manager, manager inherits from accountant, and accountant inherits from CEO, so it is still inheritance. So you say if it’s greater than 50, pass to next part, and greater than 250, pass it up until you get to the designated area. What I thought was really interesting though, was when they mentioned a real world example which is exception handling. The last one mentioned today was Iterators, which I had heard of before this. Iterators are a pattern in which the iterator is used to traverse a container and access the container's elements but the pattern decouples the algorithms from the container. So algorithms are container specific and cannot be decoupled. It provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation and not exposing what that data is. A good example is the fibonacci sequence, since it technically does not have to do with any lists or arrays. When you want to sequentially traverse whatever that collection might be and you want to decouple that traversal algorithm away from the container, you don’t want the user to know how you’re containing that data. You still want the user to be allowed to traverse through the data. The consequence of this is that sequentially has to keep track of its location, and can have two loops accessing the same iterator. The last thing mentioned in the podcast as usual was its resources which as always I love. It just gives me more resources that I cn had to my little library and will help me a lot in the future. Now honestly, this podcast was not as interesting as the first two for me. With the first two, I was learning about them in class, so it was cool to compare and contrast was was said on the podcast to what I was learning in my class. With these three Design Patterns, I hadn’t ever really hear of them, except iterators, and they just were a little hard to completely understand without a visual representation. I think like the other two though, knowing these Design Patterns in general will help me with my future coding and that is what is more important.
