Object Oriented Paradigm
Object Orientation, in general, models the real world or at least the problem being solved, by decomposing the problem into smaller discrete pieces called “Objects”. What makes an “object” unique is the formal and explicit combination these smaller pieces’ behavior with its’ data into a single entity. Traditional structured approach, models the real world or the problem being solved, by determining the steps and the order of those steps that must be followed in order to reach a desired outcome or specific program state.
Software tries to model the real world in some way: Object orientation, boils down to what a group of objects do I have and how do they relate to and interact with each other. Procedural programming, boils down to what steps do I need to take to get the program in a certain state. But as the requirements grew, it was seen that the programs were getting larger and larger and it became difficult to debug. So functions were introduced to reduce the size of the programs and improve readability in them. Still that was not enough.
One of the major problems with the “Structured Paradigm” was that data was treated as a stepson and functions were given more priority. Whereas, it is the other way. In this procedure the original data could easily get corrupted, as it was accessible to all the functions, making the resulting system very difficult to modify, expend, test and maintain, and almost not quite possible for large scale projects for team development. This is where the object oriented paradigm enters the picture.
One of the primary advantages of the object−oriented paradigm is the ability to build components once and then use them over and over again. Just as you can reuse a toy building block in a castle or a house, you can reuse a basic piece of object−oriented design and code in an accounting system, an inventory system, or an order−processing system.
We can summarize the other benefits of the object oriented paradigm when we use it together with unified modeling language (UML) for system development as follows:
- A single paradigm
-
- Single language used by users, analysts, designers, implementers
- Facilitates architectural and code reuse
- Models more closely reflect the real world
-
- More accurately describe corporate data and processes
- Decomposed based on natural partitioning
- Easier to understand and maintain
- Stability
-
- A small change in requirements does not mean massive changes in the system under development
