oop.asciidoc 16 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330
  1. [[oop]]
  2. == Object Oriented Programming
  3. In all the programs we wrote till now, we have designed our program around functions i.e. blocks of
  4. statements which manipulate data. This is called the _procedure-oriented_ way of programming. There
  5. is another way of organizing your program which is to combine data and functionality and wrap it
  6. inside something called an object. This is called the _object oriented_ programming paradigm. Most
  7. of the time you can use procedural programming, but when writing large programs or have a problem
  8. that is better suited to this method, you can use object oriented programming techniques.
  9. Classes and objects are the two main aspects of object oriented programming. A *class* creates a
  10. new _type_ where *objects* are *instances* of the class. An analogy is that you can have variables
  11. of type `int` which translates to saying that variables that store integers are variables which are
  12. instances (objects) of the `int` class.
  13. .Note for Static Language Programmers
  14. [NOTE]
  15. --
  16. Note that even integers are treated as objects (of the `int` class). This is unlike C++ and Java
  17. (before version 1.5) where integers are primitive native types.
  18. See `help(int)` for more details on the class.
  19. C# and Java 1.5 programmers will find this similar to the _boxing and unboxing_ concept.
  20. --
  21. Objects can store data using ordinary variables that _belong_ to the object. Variables that belong
  22. to an object or class are referred to as *fields*. Objects can also have functionality by using
  23. functions that _belong_ to a class. Such functions are called *methods* of the class. This
  24. terminology is important because it helps us to differentiate between functions and variables which
  25. are independent and those which belong to a class or object. Collectively, the fields and methods
  26. can be referred to as the *attributes* of that class.
  27. Fields are of two types - they can belong to each instance/object of the class or they can belong
  28. to the class itself. They are called *instance variables* and *class variables* respectively.
  29. A class is created using the `class` keyword. The fields and methods of the class are listed in an
  30. indented block.
  31. [[self]]
  32. === The +self+
  33. Class methods have only one specific difference from ordinary
  34. functions - they must have an extra first name that has to be added to
  35. the beginning of the parameter list, but you *do not* give a value
  36. for this parameter when you call the method, Python will provide
  37. it. This particular variable refers to the object _itself_, and by convention, it is given the name
  38. `self`.
  39. Although, you can give any name for this parameter, it is _strongly recommended_ that you use the
  40. name `self` - any other name is definitely frowned upon. There are many advantages to using a
  41. standard name - any reader of your program will immediately recognize it and even specialized IDEs
  42. (Integrated Development Environments) can help you if you use `self`.
  43. .Note for C++/Java/C# Programmers
  44. [NOTE]
  45. The `self` in Python is equivalent to the `this` pointer in C++ and the `this` reference in Java
  46. and C#.
  47. You must be wondering how Python gives the value for `self` and why you don't need to give a value
  48. for it. An example will make this clear. Say you have a class called `MyClass` and an instance of
  49. this class called `myobject`. When you call a method of this object as `myobject.method(arg1,
  50. arg2)`, this is automatically converted by Python into `MyClass.method(myobject, arg1, arg2)` -
  51. this is all the special `self` is about.
  52. This also means that if you have a method which takes no arguments, then you still have to have one
  53. argument - the `self`.
  54. [[class]]
  55. === Classes
  56. The simplest class possible is shown in the following example (save as `oop_simplestclass.py`).
  57. [source,python]
  58. --------------------------------------------------
  59. include::programs/oop_simplestclass.py[]
  60. --------------------------------------------------
  61. Output:
  62. --------------------------------------------------
  63. include::programs/oop_simplestclass.txt[]
  64. --------------------------------------------------
  65. .How It Works
  66. We create a new class using the `class` statement and the name of the class. This is followed by an
  67. indented block of statements which form the body of the class. In this case, we have an empty block
  68. which is indicated using the `pass` statement.
  69. Next, we create an object/instance of this class using the name of the class followed by a pair of
  70. parentheses. (We will learn <<init,more about instantiation>> in the next section). For our
  71. verification, we confirm the type of the variable by simply printing it. It tells us that we have
  72. an instance of the `Person` class in the `__main__` module.
  73. Notice that the address of the computer memory where your object is stored is also printed. The
  74. address will have a different value on your computer since Python can store the object wherever it
  75. finds space.
  76. [[methods]]
  77. === Methods
  78. We have already discussed that classes/objects can have methods just like functions except that we
  79. have an extra `self` variable. We will now see an example (save as `oop_method.py`).
  80. [source,python]
  81. --------------------------------------------------
  82. include::programs/oop_method.py[]
  83. --------------------------------------------------
  84. Output:
  85. --------------------------------------------------
  86. include::programs/oop_method.txt[]
  87. --------------------------------------------------
  88. .How It Works
  89. Here we see the `self` in action. Notice that the `say_hi` method takes no parameters but still has
  90. the `self` in the function definition.
  91. [[init]]
  92. === The `__init__` method
  93. There are many method names which have special significance in Python classes. We will see the
  94. significance of the `__init__` method now.
  95. The `__init__` method is run as soon as an object of a class is instantiated. The method is useful
  96. to do any *initialization* you want to do with your object. Notice the double underscores both at
  97. the beginning and at the end of the name.
  98. Example (save as `oop_init.py`):
  99. [source,python]
  100. --------------------------------------------------
  101. include::programs/oop_init.py[]
  102. --------------------------------------------------
  103. Output:
  104. --------------------------------------------------
  105. include::programs/oop_init.txt[]
  106. --------------------------------------------------
  107. .How It Works
  108. Here, we define the `__init__` method as taking a parameter `name` (along with the usual `self`).
  109. Here, we just create a new field also called `name`. Notice these are two different variables even
  110. though they are both called 'name'. There is no problem because the dotted notation `self.name`
  111. means that there is something called "name" that is part of the object called "self" and the other
  112. `name` is a local variable. Since we explicitly indicate which name we are referring to, there is
  113. no confusion.
  114. Most importantly, notice that we do not explicitly call the `__init__` method but pass the
  115. arguments in the parentheses following the class name when creating a new instance of the
  116. class. This is the special significance of this method.
  117. Now, we are able to use the `self.name` field in our methods which is demonstrated in the `sayHi`
  118. method.
  119. [[class_obj_vars]]
  120. === Class And Object Variables
  121. We have already discussed the functionality part of classes and objects (i.e. methods), now let us
  122. learn about the data part. The data part, i.e. fields, are nothing but ordinary variables that are
  123. _bound_ to the *namespaces* of the classes and objects. This means that these names are valid
  124. within the context of these classes and objects only. That's why they are called _name spaces_.
  125. There are two types of _fields_ - class variables and object variables which are classified
  126. depending on whether the class or the object _owns_ the variables respectively.
  127. *Class variables* are shared - they can be accessed by all instances of that class. There is only
  128. one copy of the class variable and when any one object makes a change to a class variable, that
  129. change will be seen by all the other instances.
  130. *Object variables* are owned by each individual object/instance of the class. In this case, each
  131. object has its own copy of the field i.e. they are not shared and are not related in any way to the
  132. field by the same name in a different instance. An example will make this easy to understand (save
  133. as `oop_objvar.py`):
  134. [source,python]
  135. --------------------------------------------------
  136. include::programs/oop_objvar.py[]
  137. --------------------------------------------------
  138. Output:
  139. --------------------------------------------------
  140. include::programs/oop_objvar.txt[]
  141. --------------------------------------------------
  142. .How It Works
  143. This is a long example but helps demonstrate the nature of class and object variables. Here,
  144. `population` belongs to the `Robot` class and hence is a class variable. The `name` variable belongs
  145. to the object (it is assigned using `self`) and hence is an object variable.
  146. Thus, we refer to the `population` class variable as `Robot.population` and not as
  147. `self.population`. We refer to the object variable `name` using `self.name` notation in the methods
  148. of that object. Remember this simple difference between class and object variables. Also note that
  149. an object variable with the same name as a class variable will hide the class variable!
  150. Instead of `Robot.population`, we could have also used +self.__class__.population+ because every
  151. object refers to it's class via the +self.__class__+ attribute.
  152. The `how_many` is actually a method that belongs to the class and not to the object. This means we
  153. can define it as either a `classmethod` or a `staticmethod` depending on whether we need to know
  154. which class we are part of. Since we refer to a class variable, let's use `classmethod`.
  155. We have marked the `how_many` method as a class method using a <<decorator,decorator>>.
  156. Decorators can be imagined to be a shortcut to calling a wrapper function, so applying the
  157. `@classmethod` decorator is same as calling:
  158. [source,python]
  159. --------------------------------------------------
  160. how_many = classmethod(how_many)
  161. --------------------------------------------------
  162. Observe that the `__init__` method is used to initialize the `Robot` instance with a name. In this
  163. method, we increase the `population` count by 1 since we have one more robot being added. Also
  164. observe that the values of `self.name` is specific to each object which indicates the nature of
  165. object variables.
  166. Remember, that you must refer to the variables and methods of the same object using the `self`
  167. *only*. This is called an *attribute reference*.
  168. In this program, we also see the use of *docstrings* for classes as well as methods. We can access
  169. the class docstring at runtime using `Robot.__doc__` and the method docstring as
  170. `Robot.say_hi.__doc__`
  171. In the `die` method, we simply decrease the `Robot.population` count by 1.
  172. All class members are public. One exception: If you use data members with names using the _double
  173. underscore prefix_ such as `__privatevar`, Python uses name-mangling to effectively make it a
  174. private variable.
  175. Thus, the convention followed is that any variable that is to be used only within the class or
  176. object should begin with an underscore and all other names are public and can be used by other
  177. classes/objects. Remember that this is only a convention and is not enforced by Python (except for
  178. the double underscore prefix).
  179. .Note for C++/Java/C# Programmers
  180. [NOTE]
  181. All class members (including the data members) are _public_ and all the methods are _virtual_ in
  182. Python.
  183. === Inheritance
  184. One of the major benefits of object oriented programming is *reuse* of code and one of the ways
  185. this is achieved is through the *inheritance* mechanism. Inheritance can be best imagined as
  186. implementing a *type and subtype* relationship between classes.
  187. Suppose you want to write a program which has to keep track of the teachers and students in a
  188. college. They have some common characteristics such as name, age and address. They also have
  189. specific characteristics such as salary, courses and leaves for teachers and, marks and fees for
  190. students.
  191. You can create two independent classes for each type and process them but adding a new common
  192. characteristic would mean adding to both of these independent classes. This quickly becomes
  193. unwieldy.
  194. A better way would be to create a common class called `SchoolMember` and then have the teacher and
  195. student classes _inherit_ from this class i.e. they will become sub-types of this type (class) and
  196. then we can add specific characteristics to these sub-types.
  197. There are many advantages to this approach. If we add/change any functionality in `SchoolMember`,
  198. this is automatically reflected in the subtypes as well. For example, you can add a new ID card
  199. field for both teachers and students by simply adding it to the SchoolMember class. However,
  200. changes in the subtypes do not affect other subtypes. Another advantage is that if you can refer to
  201. a teacher or student object as a `SchoolMember` object which could be useful in some situations
  202. such as counting of the number of school members. This is called *polymorphism* where a sub-type
  203. can be substituted in any situation where a parent type is expected i.e. the object can be treated
  204. as an instance of the parent class.
  205. Also observe that we reuse the code of the parent class and we do not need to repeat it in the
  206. different classes as we would have had to in case we had used independent classes.
  207. The `SchoolMember` class in this situation is known as the *base class* or the *superclass*. The
  208. `Teacher` and `Student` classes are called the *derived classes* or *subclasses*.
  209. We will now see this example as a program (save as `oop_subclass.py`):
  210. [source,python]
  211. --------------------------------------------------
  212. include::programs/oop_subclass.py[]
  213. --------------------------------------------------
  214. Output:
  215. --------------------------------------------------
  216. include::programs/oop_subclass.txt[]
  217. --------------------------------------------------
  218. .How It Works
  219. To use inheritance, we specify the base class names in a tuple following the class name in the
  220. class definition. Next, we observe that the `__init__` method of the base class is explicitly
  221. called using the `self` variable so that we can initialize the base class part of the object. This
  222. is very important to remember - Python does not automatically call the constructor of the base
  223. class, you have to explicitly call it yourself.
  224. We also observe that we can call methods of the base class by prefixing the class name to the
  225. method call and then pass in the `self` variable along with any arguments.
  226. Notice that we can treat instances of `Teacher` or `Student` as just instances of the
  227. `SchoolMember` when we use the `tell` method of the `SchoolMember` class.
  228. Also, observe that the `tell` method of the subtype is called and not the `tell` method of the
  229. `SchoolMember` class. One way to understand this is that Python _always_ starts looking for methods
  230. in the actual type, which in this case it does. If it could not find the method, it starts looking
  231. at the methods belonging to its base classes one by one in the order they are specified in the
  232. tuple in the class definition.
  233. A note on terminology - if more than one class is listed in the inheritance tuple, then it is
  234. called *multiple inheritance*.
  235. The trailing comma is used at the end of the `print` statement in the superclass's `tell()` method
  236. to print a line and allow the next print to continue on the same line. This is a trick to make
  237. `print` not print a `\n` (newline) symbol at the end of the printing.
  238. === Summary
  239. We have now explored the various aspects of classes and objects as well as the various
  240. terminologies associated with it. We have also seen the benefits and pitfalls of object-oriented
  241. programming. Python is highly object-oriented and understanding these concepts carefully will help
  242. you a lot in the long run.
  243. Next, we will learn how to deal with input/output and how to access files in Python.