Monday, 23 February 2015

Monday, 9 February 2015

Summary of OOP

OOPs. I never posts these at the regular schedule that I want to. Speaking of OOP (Thanks, I know it's an amazing transition), let's talk about Object Oriented Programming! So in my opinion Object Oriented Programming is just as it sounds, you make a program based around thinking its an object rather actions/logic. For example, think of a car. A car has attributes such as color, engine, number of doors, etc. Just like a class, there could be a car class with the same attributes surrounding that object. Additionally, the car class may or may not be able to offer services such as being able to move a certain speed. Similarly, we can make a method for the car class that allows it to move at that speed.

If you think about it this way, OOP can be applied to how we classify things as well. The 'car' class that we just made can have a parent class and sub-classes as well. We can classify a generic vehicle class as a parent class, and we can also classify a specific brand car as a class, for example a BMWclass. With OOP, programs are revolved around creating an instance of an object, where classes are the instructions of how to make the object, and then there can be instances in other people's code. Hopefully my crappy metaphor made some sense, if not here check out this video, it helped me when I was learning about classes!

CLICK ME!

Furthermore there are many benefits to OOP! One of them is its modularity and re usability. The objects created from classes can easily be reused in other code, and also be modified just as easily to better suit the task through implementation (making a subclass). Because of its modularity, parts of a certain class can be changed without syntax issues or compatibility issues (if modified correctly that is). This allows for older versions of code to be modified easily without repercussions.

However, personally the most important benefit of OOP is its design concept. Complex large programs are naturally very difficult to write, but thanks to OOP, it divides the problem into smaller more manageable problems. Because of this, there should always be an extensive planning process reduce the number of possible flaws. Even with those flaws, because of how code is separated into classes (ie. different objects), flaws are easy to fix and locate.

Monday, 2 February 2015

Recursion and A1

Wow this week went by hella fast! Time flies when you're having fun I suppose. Anyways assignment 1 was loads of fun to make. It was a bit hard to get started because the assignment was initially very vague so we had to design our own classes and how they would interact. Personally I found that it wasn't the coding part that was difficult, but more so when you have partners. I was in a group of 3 and we had different ideas of how the classes should interact with each other, so it was difficult to coordinate and align our code together. Next time, we're gonna start planning specifically for each class and then start coding once all the planning is set in stone.

Now for recursion, it was pretty fun, definitely a lot of brain power was required for it. I found that tracing recursion was a breeze, however thinking about our own recursive functions was definitely difficult. I wasn't even able to finish the recursive function for the lab! For those who don't know, a recursive function is basically a function the calls itself to resolve a command. In a physical sense, it's almost like painting a wall. Paint() is going to paint the entire wall, but it's going to call itself within the function to paint smaller portions of the wall so that in the grand scheme of things everything is painted. Hopefully that made sense because it sounded a lot better in my head. I can't wait to learn more about recursion in class, especially since right now it's my weak point. See you guys next week!