Sie sind auf Seite 1von 5

Object oriented programming (OOP), as the name suggests, is a paradigm where we focus real life objects while programming

any solution. By focusing real life objects we mean that over solutions revolves around different objects, which represent respective objects in real life situation. We not only write programs to process data, we actually write behaviours of our programming objects, those behaviours are called methods in objected oriented programming. The data elements on which those objects behave, are called data-members/ fields. In a more in-depth view towards OOP using domain specific terminology, following are the fundamental features we get: Encapsulation Inheritance Re-usability Information Hiding Encapsulation: The way we make a logical boundary around behaviours (methods) and data (properties) they work on is called Encapsulation. Inheritance: As in real life, objects in OOP relate to each other in one way or another, the relationship in most of the case is parent/child relationship. The child objects inherent all the functionalities (methods) and data (properties) of their parents. Re-usability Along with inheritance, some other phenomena like method overloading and overriding, provide codereuse, which is known to be a very basic feature of object oriented programming. Information Hiding When we have ways to reuse our code through one way or other, we are also in need of some security regarding our source code. To protect it from unauthorized access/ alteration. In object oriented programming, this is called Information Hiding and is achieved through "Access Modifiers" which lets us restrict access to all or some parts of our objects methods and/or data. Anonymous

3.1 OOP: Class Hierarchy

In object-oriented programming, a class is a template that defines the state and behavior common to objects of a certain kind. A class can be defined in terms of other classes. For example, a truck

and a racing car are both examples of a car. Another example is a letter and a digit being both a single character that can be drawn on the screen. In the latter example, the following terminology is used:
y y y

The letter class is a subclass of the character class; (alternative names: child class and derived class) The character class is immediate superclass (or parent class) of the letter class; The letter class extends the character class.

The third formulation expresses that a subclass inherits state (instance variables) and behavior (methods) from its superclass(es). Letters and digits share the state (name, font, size, position) and behavior (draw, resize, ...) defined for single characters. The purpose of a subclass is to extend existing state and behavior: a letter has a case (upper and lower case, say stored in the instance variable letterCase) and methods for changing the case (toUpperCase, toLowerCase) in addition to the state that it already has as a character. However, a digit does not have a case, so the methods toUpperCase, toLowerCase do not belong on the common level of the Character class. There are methods that are special to the digit class. For instance, a digit may be constructed from an integer value between 0 and 9, and conversely, the integer value of a digit may be the result of say the intValue method. Subclasses can also override inherited behavior: if you had a colored character as subclass of the character class, you would override the definition of the draw method of the character class so that color is taken into account when drawing the character on the screen. This leads to what is called in OOP jargon polymorphism: the same message sent to different objects results in behavior that is dependent on the nature of the object receiving the message.

A category of items that can be found in the public interface of objects is exceptions. Exceptions have two different definitions: * an event that causes suspension of normal application execution, and * a set of information directly relating to the event that caused suspension of normal application execution. Exceptions can be contrasted with an older, less reliable technology: "error codes." The idea behind error codes was fairly simple. You would request that an application, or part of an application, accomplish some work. One of the pieces of information that would be returned to the requester would be an error code. If all had gone well, the error code would typically have a value of zero. If any problems had occurred, the error code would have a non-zero value. It was also quite common to associate different non-zero values of an error code with specific errors. Error codes suffered from two major problems: * No one was forced to actually check the value of returned error codes. * Changes (additions, deletions, and modifications) in the meanings of the special values assigned to error codes were not automatically passed on to interested parties. Tracking the effects of a changed error code value often consumed a significant amount of resources. To understand how exceptions directly address both of these issues, we first need to understand how exceptions typically work: * Exceptions may be defined by the environment or by the user. * When an exceptional (but not unforeseen) condition occurs, an appropriate exception is activated. (People use different terms to express the activation of an exception. The most common is "raise." Less commonly, people use the terms "throw" or "activate.") This activation may be automatic (controlled by the environment) or may be expressly requested by the designer of the object or application. Examples of exceptional conditions include trying to remove something from an empty container, directing an elevator on the top floor to "go up," and attempting to cause a date to take on an invalid value like "February 31, 1993." * Once the exception is activated, normal application execution stops and control is transferred to a locally defined exception handler, if one is present. If no locally defined exception handler is present or if the exception handler is not equipped to handle the exception, the exception is propagated to the next higher level of the application. Exceptions cannot be ignored. An exception will continue to be sent to higher levels of the application until it is either turned off or the application ceases to function. * An exception handler checks to see what type of exception has been activated. If the exception is one that the handler recognizes, a specific set of actions is taken. Executing a set of actions in response to an exception is known as "handling the exception." Handling an exception deactivates the exception; the exception will not be propagated any further. Unlike error codes, exceptions cannot be ignored. Once an exception has been activated, it demands attention. In object-oriented systems, exceptions are placed in the public interfaces of objects. Changes in the public interfaces of objects very often require an automatic rechecking of all other objects that invoke operations in the changed objects. Thus, changes in exceptions result in at least a partially automated propagation of change information.

Overriding is an important concept in Object Oriented Technology. In today's world you can't live without overriding. For example in most of the API's used for building windows based application you always need to override some parent window. Like in Java you may override methods and data of class Frame, in C++ CMainWnd, in QT Form etc. In many of your applications that you build using Inheritance you need to override some members of the parent class. Let's understand inheritance by an analogous example. Let S be the son of F. There can be many characteristics that C inherit from his/her father F. Like may be he also loves listening to music and so

does C, F is genius and so is C, F writes poems like C does. These all are inherited characteristics. But there can be situation like C writes romantic poems and his/her father used to write tragic poems. Here, C has overridden his/her father's characteristics of writing a poem. It was inherited from his/her father but he/she does it differently. The concept of overriding is same in Object Oriented Programming Languages. For overriding, there must be inheritance. Once you inherit, you can then override data member of methods of the parent class. In C++ ":" is used to tell C++ compiler that you want to inherit something. For example "Class MangoTree : public Tree " means class MangoTree is inheriting class Tree. The keyword public adds the information that only the public members are inherited. Once class MangoTree inherits class Tree, all the public members of class Tree are accessible from class MangoTree. Like is there is a data member "height" defined in class "Tree" you can directly use this variable in any method of class "MangoTree". Similar is the case with methods. But, sometimes you would like to change the implementation of some of the methods of the parent class. Like though there was a method called, "getFruitName()", you would write another method of the same name and parameter in class "MangoTree". The method "getFruitName()" of parent class is not visible in child class "MangoTree" now. It has its own now. It has overridden the method of its parent. Similarly, it can also override the data member of its parent. This is what known as overriding, a popular technique in object oriented paradigm.