Introduction to OOP
Class notation and definition (with graphical examples)A comparison between OOP and structure programming paradigms
Class relation types ( is a , type of, )
Problem Decomposition //Top-down Approach
The problem is decomposed into small units and they are further decomposed into smaller units over and over again until each smaller unit is manageable. The complex problem is simplified by decomposing it into many simple problems. It is applicable for simple and fairly complex problems.The top-down approach is also known as stepwise refinement, or modular decomposition, or structured approach, or algorithmic approach.
Structured programming approach supports the following features:
1. Each procedure has its own local data and algorithm.2. Each procedure is independent of other procedures.
3. Parameter-passing mechanisms are evolved.
4. It is possible to create user-defined data types.
5. A rich set of control structures is introduced.
6. Scope and visibility of data are introduced.
7. Nesting of subprograms is supported.
8. Procedural abstractions or function abstractions are achieved, yielding abstract operations.
9. Subprograms are the basic physical building blocks supporting modular programming
The main differences between object oriented programming and structured programming are illustrated in the following table:
The graphical notation of the class is shown in the following figure:
Class Relationships
Several relationships are found in the OOP that explained throughout this sectionA-Kind-Of relationship
Knowing the properties of class Point we can describe a circle as a point plus a radius and methods to access it. Thus, a circle is ``a-kind-of'' point. However, a circle is somewhat more ``specialized''. We illustrate this graphically as shown in following figure:
``a-kind-of'' relationship. INCLUDEPICTURE "http://www.desy.de/gna/html/cc/Tutorial/img11.gif" \* MERGEFORMATINET Is-A relationship
The previous relationship is used at the class level to describe relationships between two similar classes. If we create objects of two such classes we refer to their relationship as an ``is-a'' relationship.
Since the class Circle is a kind of class Point, an instance of Circle, say acircle, is a point HYPERLINK "http://www.desy.de/gna/html/cc/Tutorial/footnode.html" \l "679" INCLUDEPICTURE "http://www.desy.de/gna/html/cc/Tutorial/foot_motif.gif" \* MERGEFORMATINET . Consequently, each circle behaves like a point. For example, you can move points in x direction by altering the value of x. Similarly, you move circles in this direction by altering their x value.
The following figure illustrates this relationship. In this and the following figures, objects are drawn using rectangles with round corners. Their name only consists of lowercase letters.
Illustration of ``is-a'' relationship. INCLUDEPICTURE "http://www.desy.de/gna/html/cc/Tutorial/img12.gif" \* MERGEFORMATINET Part-Of relationship
You sometimes need to be able to build objects by combining them out of others. You already know this from procedural programming, where you have the structure or record construct to put data of various types together.
Let's come back to our drawing program. You already have created several classes for the available figures. Now you decide that you want to have a special figure which represents your own logo which consists of a circle and a triangle. (Let's assume, that you already have defined a class Triangle.) Thus, your logo consists of two parts or the circle and triangle are part-of your logo:
Illustration of ``part-of'' relationship. INCLUDEPICTURE "http://www.desy.de/gna/html/cc/Tutorial/img13.gif" \* MERGEFORMATINET Has-A relationship
This relationship is just the inverse version of the part-of relationship. Therefore we can easily add this relationship to the part-of illustration by adding arrows in the other direction as shown below:
Illustration of ``has-a'' relationship. INCLUDEPICTURE "http://www.desy.de/gna/html/cc/Tutorial/img14.gif" \* MERGEFORMATINET
Problem decomposition approaches
"A top-down approach (also known as stepwise design and in some cases used as a synonym of decomposition) is essentially the breaking down of a system to gain insight into its compositional sub-systems. In a top-down approach an overview of the system is formulated, specifying but not detailing any first-level subsystems." "A bottom-up approach is the piecing together of systems to give rise to more complex systems, thus making the original systems sub-systems of the emergent system. Bottom-up processing is a type of information processing based on incoming data from the environment to form a perception." In OOP, you first write a base class, and constantly derive new child classes from the existing base one (like a Car class will probably derive from a class called Vehicle). So, you start from the basic blocks and go on making it a more complex design. Program execution occurs in a top-down manner. So if your code has a main() method containing an instance of an object called Car, the computer would want to know what Car is. So, it'll then 'break it down' to see that Car has derived from vehicle.
2nd class Lect 2/OOP