Developer Forums | About Us | Site Map
Search  
HOME > TUTORIALS > SERVER SIDE CODING > PERL TUTORIALS > THE ROAD TO BETTER PROGRAMMING: CHAPTER 5 MODULES AND OBJECTS


Sponsors





Useful Lists

Web Host
site hosted by netplex

Online Manuals

The road to better programming: Chapter 5 Modules and objects
By Teodor Zlatanov - 2004-03-01 Page:  1 2 3 4 5 6 7 8

Why is OOP a strong methodology?

Returning to our original topic of how OOP is a strong methodology, we can see now that OOP incorporates several key concepts that make it difficult to apply in a mix with procedural and functional programming (PP and FP). First and foremost, neither PP nor FP have the concepts of inheritance or class polymorphism, since there are no classes in PP and FP. Encapsulation in PP and FP does exist, but only on a procedural level, never as a class or object attribute. Going to the trouble of using these essential OOP tools means that programmers are generally more likely to stick to OOP for the whole project rather than mix incompatible methodologies.

Some would argue that all programs are eventually reduced to a procedural execution of instructions, and so every OOP program, no matter how purely implemented it is, contains procedural code in its functions (a.k.a. methods) and in the code that creates the first object(s) that do the rest of the work. Even a language as close to pure OOP as Java can't avoid requiring a main() function. Therefore, it would seem that OOP is just a subset of PP. But this reduction of OOP into sequential instructions is of no more concern to a system architect or a programmer than the actual assembler instructions executed for every operation. Remember that OOP is a methodology, not an end in itself.

OOP does not work well with the procedural programming methodology because it concentrates on objects, while procedural programming is based on procedures (we will loosely define procedures as functions available without OOP techniques, and methods as functions available only from within objects). Procedures, just like methods, are just functions invoked by the user, but there are some differences between the two.

Procedures don't have object data to work with. Either they must be passed the data in their parameter list, or they must use data in their scope. A procedure can access any data passed to it during its invocation, or even global data for the whole program. Methods should access only their object's data. In effect, the function scope for a method is usually the object that contains the method.

Procedures are often found using global data, though this should be done only when absolutely necessary. Methods that use global data should be rewritten as soon as possible. Procedures usually invoke other procedures with several parameters. Methods should only have a few parameters, and they invoke other methods more often than other procedures.

Functional programming (FP) does not mix well with OOP for several reasons. The most important reasons are that FP is based on a detailed functional approach to solving a problem, while OOP uses objects to express concepts, and that FP procedures are meant to be used everywhere, as opposed to OOP methods which can be used only from within the object that holds them.

With all that said, we can now explain why Perl is one of the best languages for mixing OOP, FP, and PP methodologies.



View The road to better programming: Chapter 5 Modules and objects Discussion

Page:  1 2 3 4 5 6 7 8 Next Page: How does Perl mix OOP with procedural and functional programming?

First published by IBM developerWorks


Copyright 2004-2017 GrindingGears.com. All rights reserved.
Article copyright and all rights retained by the author.