Object Oriented Programming Philosophy

Part 1 -- Basic Understanding & Encapsulation

Introduction

• I hope that I don't scare you with the term "philosophy".

• Well, forget about that. Welcome back!

Introduction

• Speaking the terms of "philosophy" means the deep understanding of something. Therefore, OOP philosophy here means (for me) a deep understanding of OOP.

• So, I hope, after following this tutorial, you will be able to see clearly the gems behind OOP. Why it is preferred by so many people and why it is said to be a better solution in solving things.

The Understanding

• Hey, what does OOP mean? Yeah, we know its abbreviation, but what it is all about? It's a programming style that based its thinking into objects in the real world.

• That's how it got its name. In "normal" way in thinking programs, we usually think about the functionality of a program. It's like this: oh, this program calculate the degree of students. So, we usually divide the program based on its functionality, for example:

The Understanding

• So, we usually divide the program based on its functionality, for example: We might build a procedure to get the students marks.

• Then, we build another function to determine calculate the final marks from that. Then we build a function to determine the grade of that particular final mark.

The Understanding

• And so on. This kind of habit severely infects our mind so that we cannot think into another perspective.

• These typical symptoms are usually suffered by imperative language programmers, i.e. Pascal / C programmers, etc.

• However, there is no easy way to get rid of the old mechanism of thinking and "reformat" it with a new perspective.

• Now, how's the new paradigm work? First of all, we should determine the objective of the program. What is to be accomplished by the program you'd like to make. Try not to divide it as the functionality.

• Otherwise, you would fall into the pitfall I mentioned before. If you make a large project, try to think its general purpose as a whole first before dividing it.

• Then, we should base our thinking in the objects rather than in terms of functionality.

• From our example above, rather than thinking the program that way, we should rethink the program in terms of the students (the subject), the marks, and the reports. See the difference?

• However, thinking this way is definitely not easy.

Encapsulation

• After you think which objects are involved in your program, you should list the following:– What is the characteristics of that objects– What values or properties convey that object– What can the object do or what can be done to

the object– How is the interaction between objects– How is the classification of the objects

• Of course you should list the ones that is relevant to your program. You can list that students can play football, but that's nothing to do with grade report program. :-) Students do some exams? Ummm yes... but it's not relevant either

• Since students are not active in determining the grade, we should think the other way. Aha! Students can receive the report.

• What values or properties are of the students and they are needed in reporting grade. Aha! That's easy, you said:

• Name• Student ID number• Address (probably needed if the report sent

through the mail)• Marks (of course, this is the essence of the

program)• Major (this may be needed by the advisor to

advise that student)

• Enough for now. So, what is the relationship of these things anyway, you asked?

• Well, in OOP approach, we have to ENCAPSULATE the things that the object can do or the things that can be done to that object along with its conveying values or properties.

• That's encapsulation. Hurray, you now understand the first idiom of OOP!

• In real world of programming, the things that the object can do or the things that can be done to that object are made into functions or procedures.

• These function and procedures are now called methods.

• The values or properties are usually stored into the variables of the object and they are called properties or fields.

• And the object itself is later called class. Classes can only have methods and fields.

• The methods of the object usually process its own fields or, accessing the methods of another object passed into as a parameter. Like the Student.Receive(Report); above.

• The method Receive acceptReport which is a class. Later on in the body of Receive method, it can access the methods of the Report class.

Public or Private

• Declaring things as public means that it is accessible by outsiders. The other hand, declaring things private means that it is invisible by outsiders, thus making it unable to be accessed by anyone but the instance internal.

• What is the "public" and "private" here means? They serve as access keywords. They determine the grant policy of the accesses into that particular thing.

Public or Private

• Beside public and private, there is another access keyword: protected, which will be discussed later.

• All things -- methods and properties -- must have access rights. In Object Oriented Pascal, all things inside the class are public by default. (Note: I think Borland Pascal manual has mistakenly stated that it is private by default).

• OK, where should I put those access keywords? Here is a rough idea:

Public or Private

• How can we decide which methods or properties should be declared public and which ones should be private?

• Well, it depends on your need. However, there is a good rule of thumb: Usually, methods are declared public, unless the methods are internal to the instance (e.g.: helper methods) which will never be used outside the instance.

Public or Private

• Then, usually, properties are declared private. If some other class or instances want to access that particular variable, it has to access the accessor methods described above.

• The accessor methods are therefore have to be declared public. There are only two reasons that force you to make the properties public:

Public or Private

• It is a constant, so the values never changed anyway

• To improve speed if the property is often accessed. However, this is a bad habit. This job's usually been taken care of by the compiler better, so you won't need to do that.

• OK, that's all for now folks. It will be continued later in part 2. I'll try to be as clear as possible.

Constructors

• Naturally, when we want to create an instance of an object, we would like to initialize some things (like assigning variables to some values, allocating some memory for buffers, etc) prior to utilizing the object.

• The OOP has this. We would have to make a constructor to do it. What is a constructor?

Constructors

• Constructor is basically a method, specially invoked during the creation of the object instance. To make a constructor in Pascal is very simple just declare a method with a keyword constructor.

• That's it. Usually the method name is Init, but you can name it your own. Just keep in mind though, that Pascal's creation of constructor is somewhat unusual compared to other languages like C or C++.

Destructors

• Destructors behaves much similarly as constructors. Constructors are called during the creation of the object, but destructors are called during the destruction of the object. The purpose of having destructor is to destroy any memory allocation created by constructors.

• Suppose you have a constructor that allocates some memory for a buffer and store it in pointer p.

Destructors

• After the object get destroyed, you have to destroy p as well. Otherwise, that portion of memory will floating around and occupies some space unused. The destructor then come in, invoked when the object got destroyed and clear such memory allocations.

• The declaration of destructor is very similar.