Saturday, January 25, 2014

Object Oriented Programming

In Python, as in many other programming languages such as Java, C, and etc., object-oriented programming is a fundamental characteristic of the programming language. Objects are created by initiating an instance of an class, with a set of data known as attributes that consists of data types such as int, float, boolean, string, and etc. As well, object have a set of defined methods called functions that acts upon the attributes of an object. Functions can be used to modify, manipulate, or return the data of an object. The data of an object is typically created when a class is initiated. However, it should be noted that in Python, the data of an object can be set outside of its parameters such as in the console. There is not such thing as private/public variables as is the case in Java, though changing the attributes of an object outside of its parameters as defined in its class is in general considered bad coding practice. In Python, every abstract data type is an object.

Object-oritented programming utilizes a concept known as encapsulation, whereby the code of an object is "hidden" from other parts of the code, such that the modification of the code of one object does not interfere with the code of another object. By "partitioning" the code into separate sections, code organization is improved. Through this method of "information hiding", programmers need not fear that changing one section of their code can lead to unexpected changes in another section of their code.

To better understand object-oriented programming, we can look at some real world equivalents of an object. Take for example the vending machine. The vending machine has a set of internal mechanisms that allows it to dispense soft drinks. However, the user of a vending machine does not need to understand the inner mechanisms behind the vending machine in order to use it; the user simply needs to understand the interface of the object to operate the machine. The designer can tinker with the internals of the vending machine and implement a new design for it, but so long as the interface remains the same (or at least similar enough such that the user is still familiar with how to operate the machine), this will not pose a problem. As well, if the designer tinkers with the internals of a single instance of a vending machine, this will not lead to system-wide changes in all vending machines in the world. This same sort of logic applies with object-oriented programming. The implementation of an object can be hidden from the user; the user simply needs to know what the object does in order to use it. We can change the internals of a single object and not expect this to lead to changes in other objects that exists in our code.

For those that are still confused about how object-oriented programming works, I found that the entry on Wikipedia was quite useful to in better understanding the concept of object orientation. The reading is informative, relatively concise, descriptive and explained in a language that is simple to understand. Of course, the best way to understand object-oriented programming is to actually use it in practice, though having some background knowledge in the matter never hurts ones understanding.

Link: http://en.wikipedia.org/wiki/Object-oriented_programming#Overview

Please feel free to make any comments or suggest any changes to the entry below! I'm quite curious as to what sort of sentiments other people in CSC148 feel with regards to Object-Oriented Programming, as I myself find it to be a much more "pleasing" method of programming that appeals to my need for organization and code management. Let me know below in the comments! As well, a note for fellow classmates in CSC148: feel free to link my posts to your blog if you wish to do so (for whatever reasons). Cheers!

Week 3

In week 3...

We covered some basics of object oriented programming in Python with regards to raising exceptions and inheriting new classes. One of the ways we can inherit from a class is by extending a base class using the declaration:

class NewClass(OldClass):
...

Sometimes when writing functions, using a return type to communicate special cases or errors is not appropriate in all circumstances i.e. when your function returns numeric values, which leads to the problem of distinguishing between "error" values and normal "expected" values. This is when the use of exceptions comes in handy, because it allows us to clearly communicate what had gone wrong with our function/program through the use of methods such as raising a ValueError. We can even output our own customized messages when raising exceptions by inserting our own strings into the parentheses of either the preloaded exception methods that comes with Python or in ones that we define in our module through inheritance, thereby creating a even more detailed response to the problems experienced by the use of our function.

We also touched briefly on modifying the "__methods__" of our newly defined classes, such as mutating the "__repr__" object to represent your object as a string.

 I enjoyed some of the materials that touched on recursive programming, as I find it to be an interesting way of looking at problems that has elements of recursion. From an intuitive standpoint, recursion offers an elegant approach of simplifying a problem by reducing it to piece meals and allowing us ("the programmer") to solve each "section" of the problem individually until we arrive at a base case. In general, I look forward to implementing some recursive methods in our next CS assignment.



Sunday, January 19, 2014

First Entry on SLOG:

This blog is created to keep a log of my participation in CSC148H1 Winter 2014 at UofT. I will update this blog on a weekly basis to record progress I've made in this course.