URL: http://www.codingblocks.net/podcast/episode1
So for the second blog, I did end up sticking to the same website and people I had listened to last week. The reason for this was, I had found a couple other podcasts I had liked, but they were harder to hear, and I just felt like I wasn’t as interested in hearing just one person talk. I really like the setup that Coding Blocks has with three people. So the topic I chose for this week was interfaces, which I know doesn’t completely have to do with computer construction, design and architecture, but from working in Eclipse from last week, I felt like it was just a good idea to watch another kind of “back to the basics” video. Also, interfaces was just another topic I have always had a hard time understanding and I felt like it just helped me a lot with the understanding, just like encapsulation. Now, just like last week, the speakers started off with a simple definition of what an interface was, “A contract of what you have to adhere to in your program, if there is something in the interface, you have to make it do something”. Pretty much, how you should interact with that piece of data. A good way that one of the men put it was that it is like two different kinds of people, there is Joe who visits his grandma, and the joe who goes to the bar. They are still Joe, but just different portrayals at the appropriate times and places. After that, they went on to describe the differences between an abstract class and an interface. In an abstract class, you want to provide some implementation as part of it, but you want to make sure some concrete information is defined and you want that user of the class to add on to that with their specific use cases and needs. Storage is assigned for members that the coder wants to have available public or private, while interfaces don’t have that and only have a declaration. Also, abstract classes have to be inherited. What I found really interesting about this podcast though is that when they mentioned when implementing an interface, it will almost always be public, but there is that slight chance that it isn’t. This is the explicit interface case. The example that was given was that there were two different interfaces with the same method. The class needs to implement both interfaces, but when the class can’t define them both with the same method, one of them has to be defined by default will be private. I hadn’t ever heard of that before, and It was nice how in depth the podcast went on about that. Overall, another really good podcast. The setup of CodingBlocks just makes it very user friendly, and I am able to understand what they are saying without getting too lost. With each podcast I listen to, I feel a little bit more confident in my computer science grammar knowledge and just feel more prepared for when I do have to write more complex code.
