Skip to main content

Facade Design Pattern


For this week’s blog on Software Architecture and Design, I will revisit the same assignment that I have blogged about before. For the assignment, I had the option between three design patterns to write a tutorial for. I picked the proxy design pattern, and then I blogged about the decorator design pattern. Now, I would like to watch a tutorial on the third design pattern, facade, so that I might learn about all three.

I chose to use the same YouTube, Derek Banas, that I used before for the other blog. I found his videos engaging and informative that I would like to learn about it again. I also like that it is fairly concise (11.5 min), which makes it much easier to rewatch sections that I don’t get the first time around. 

It turns out that I did not understand it after finishing Derek’s video, so I turned to another video by another Youtube channel by Christopher Okhravi. Derek went straight into coding, whereas Christopher just drew diagrams and did not code. I needed more of an overview to understand it, not an example of code.

The thing that confused me about Derek’s example is that I did not see how it was in any way different from code that I have written in the past. In fact, he said, “You may have used this pattern already, but you may not have realized it.” When I watched his video, I did not know why it was so special.

Christopher’s video made it make sense. I used him for the original “proxy tutorial” assignment, and he was the one that made proxy design pattern make sense. His videos tend to run on the longer side. At 16.5 minutes, this one wasn’t too long, but the proxy video was almost forty minutes.

Christopher’s diagrams were helpful to explain what made the facade pattern what it is. I also now understand why it is called a “facade” pattern — one class acts as a “facade” to every other class and interface. The end user only interacts with the facade class, which calls what it needs from the other classes. The advantage to this is everything is highly uncoupled. 

Although I think this concept is something I intuitively knew, it was helpful learning about this. Now I know there is a name for it.

Derek Banas: https://www.youtube.com/watch?v=B1Y8fcYrz5o
Christopher Okhravi: https://www.youtube.com/watch?v=K4FkHVO5iac
Labels:

Comments

Post a Comment

Popular posts from this blog

Sprint 5 Retrospective (Capstone)

It is a shame that we are so close to the end of the semester. We were gaining so much momentum. It took us a while for us to get off the ground, but once we did, we never stopped gaining speed. I feel we will be able to keep this up through this last sprint. My hopes at the beginning of the semester for what we could accomplish were unrealistically high, but I am not disappointed with what we accomplished. We have not completed a full working component quite yet, but we are very close. I think our efforts are best spent finishing the one we are currently working on and doing it right. If we divided our efforts into starting something new, we run the risk of not fully completing anything. In the sage words of Ron Swanson, “Never half-ass two things. Whole-ass one thing.” If we are able to get the tabs working beautifully, I will be happy with our effort. I have felt that our group has done a phenomenal job this sprint and every sprint before with our communication. We have a few ...
Post a Comment
Read more

Testing: Like Destroying Sandcastles

https://joecolantonio.com/testtalks/223-testing-dream-journaling-smashing-sand-castles-with-noemi-ferrera/ In this blog for software quality assurance and testing, I decided to return to the “Test Talks” podcast, presented by Joe Colantonio, for another episode (#223). In it, he sat down with Noemi Ferrera, a software tester for a Chinese mobile gaming company to get her take on the subject. Noemi gave a few interesting metaphors that I appreciated for how to look at testing. In one, she gave the example of going to a movie where you had already read the book. It was different than how you imagined it while reading it, and testing is a way of making the “movie version” fit the way you envisioned it playing out.  The other metaphor for testing that she gave was, if you were children at the beach, the developers would be the ones building the sandcastles, whereas the testers would be the ones destroying them. I don’t know if that would be the most accurate way of lookin...
Post a Comment
Read more

Apprenticeship Pattern “Practice, Practice, Practice”

The apprenticeship pattern framed the problem is that if you do not have room to make mistakes in your day to day programming, you will not have room to grow. The next line hit close to home, “It’s as if you’re always on stage.” I learn quite a bit from my school assignments, but I don’t always think I have mastered each area before moving on to the next topic. The problem arises when I know my code could be improved upon, but it’s currently working. I don’t want to restructure my code too much, because I’m afraid of making it worse. The term comes to mind, “If it ain’t broke don’t fix it.” I have problems with this way of thinking, but when you’re pressed to make something work before the impending deadline, “good enough” is sometimes feels like the only option I have left. This pattern champions a different approach to this kind of mentality. I like the idealized version that they have laid out based on the research of K. Anders Ericsson. This describes where a mentor would ass...
Post a Comment
Read more