The very apparent feature of OOP that I noticed was how the whole idea is easy to understand as a human being because I can relate objects in programming to actual objects in real life. Just like the real world, objects in programming have attributes (properties that objects have) and methods which can be seen as the behaviours (what they can do and what they can be done to). Although not much, with these two characteristics of objects, I feel a lot of sophisticated acts can be done.
Creating one's own object, or an instance, requires a class, and one creates his own class. I found Danny's clever analogy between a class and a factory, from last week's lecture, quite interesting. Anyways, once a class is created, an object of the class can be instantiated and assigned to a variable. This makes me wonder what will happen if there is no such thing as a variable. I guess without it, nothing stored can be accessed easily, and therefore one cannot create anything, or at least it would be difficult. But then again, I may be very wrong. Maybe during my time in CSC148, I will learn about how computers and program languages work.
Inheritance, in my opinion, is a crucial part of OOP. This seems to be what makes the whole paradigm so clean and efficient so to speak. I do not actually know if using inheritance is efficient in terms of how a computer processes informations. Nevertheless, inheritance will create a very complex mapping of classes. Although inheriting different classes is exciting, if I am not careful, especially when I change something in a class, I may find myself in a world of trouble. I should always be careful when changing anything.
The terms "superclass" and "subclass" is somewhat confusing to me. In certain times, the two words are intuitive--a subclass is called by its name because it has been derived from another class, a superclass. For example, in the week 3 lectures, the derived class IntStack is a more restricted class of its superclass, Stack. In this case, calling IntStack the subclass and Stack the superclass makes sense. However, let us suppose we create a class A and another class B, such that class B is derived from class A and class B has additional attributes and/or methods. Then, my mind tends to think class B as the superclass and class A the subclass, since class B contain what class A has plus some more. I just hope this confusion does not occur often.
The terms "superclass" and "subclass" is somewhat confusing to me. In certain times, the two words are intuitive--a subclass is called by its name because it has been derived from another class, a superclass. For example, in the week 3 lectures, the derived class IntStack is a more restricted class of its superclass, Stack. In this case, calling IntStack the subclass and Stack the superclass makes sense. However, let us suppose we create a class A and another class B, such that class B is derived from class A and class B has additional attributes and/or methods. Then, my mind tends to think class B as the superclass and class A the subclass, since class B contain what class A has plus some more. I just hope this confusion does not occur often.
I feel the real challenge of using OOP is not the programming itself, but rather, tackling a given problem to solve using OOP. Just like many other acts of creation, the key is the blueprint. I sometime find myself that my blueprint is flawed, which makes me very frustrated. When encountered with this situation, I noticed that, although very difficult and heart breaking, creating a new blueprint from scratch is the best way to solve the problem, rather than trying to fix the flaw in the original blueprint. In order to be able to withstand such unfortunate possibility, I should give myself ample time to program.
No comments:
Post a Comment