My 17 year old little brother, Gian Dionisio, is currently working on getting into college to pursue a computer science degree and has always expressed a genuine interest in software engineering. I'm on his back 24/7 when it comes to good grades, school etc. so it was a pleasant holiday present when he showed me his senior term paper in which he received a 98 out of 100. Glad he hasn't caught "senioritus" like his older brother did! I'm posting this more for selfish reasons as it's something I'd like to point people to for a totally objective view when it comes to object oriented vs. procedural programming. I've probably given Gian about a 1 minute dump of my own thoughts on the subject but as you'll read, his essay is based entirely on his own research. so here it is, good work Gian, very good work.
Strengths and Weaknesses of Object-Oriented and Procedural Programming by Gian Dionisio
The process of designing a program is broken down into four steps: analysis, design, implementation, and maintenance. Analysis refers to determining if a problem is solvable, design refers to the process of determining how to solve the problem, implementation is the actual coding of the program, and maintenance refers to the debugging and modification of the program. As the process progresses from one phase to the next, costs rise higher and higher, with maintenance being the most expensive (Lambert). Currently, many programmers use one of two paradigms of programming when designing and implementing a program: procedural and object-oriented. However, many programmers have begun to stray away from procedural programming in favor of object-oriented
because of the way object-oriented programs handle data, which allows for more dynamic and flexible programs. Even though object-oriented programming offers more flexibility than procedural programming, programmers should not perceive procedural programming as obsolete because both paradigms have strengths and weaknesses that do not make one necessarily better than the other.
Procedural programming is best described as a one-way system, using only variables and functions, with no major data grouping, which is the primary strength of object-oriented programming (gabehabe). This paradigm emphasizes on conciseness and reaching the end result as quickly as possible, solving only the problem presented and nothing more, making procedural programs very straightforward (Weisfield). John Barton of IBM notes that generations of programmers have essentially been taught to create a list of instructions for the
machine on how to read data (gather ingredients), how to use equations and functions with subroutines (cook the meal), and how to display the product (a finished meal) (Waldrop).
While the design and implementation of a procedural program may be straightforward, especially in smaller scale projects, as the programs grows larger in scale, both design and implementation become increasingly more difficult as different subroutines are being performed on the same set of data at the same time (Waldrop). When the program is finally functional, modification is made either difficult or impossible because changes in one part of the program may affect the rest of the program as a whole (Archwing). Because procedural programs are not able to be readily modified, maintenance costs become very high. For example, think of a 10-story apartment complex with 10 apartments on each floor, and a development lot for 100 houses; the lots of houses may cost more to construct than the apartment complex, but the houses are, for the most part, self-contained with their own
utilities and walls, versus an apartment, which shares utilities and walls, therefore adding another house would be far less expensive than adding another apartment to an apartment complex (Orr). This problem of modification is solved with the principles emphasized in object-oriented programming.
The main strength of object-oriented programming is its ability to handle data by taking advantage of the way we perceive of environment with the use of objects (Parr). Objects can be seen as separate entities, each with their own characteristics. These entities all share two characteristics: states and behaviors (Sun). For example, a
dog has 'states' (name, color, breed) and 'behaviors' (barking, fetching) (Sun). Objects "encapsulate" these qualities, meaning that they contain data, otherwise known as states, and methods, otherwise known as behaviors (Orr). These objects inherit these qualities from blocks of code known as "classes"; a class can be seen as a blueprint or template of an object, much like how biologists group organisms into classes such as "bird" or ”mammal” (Waldrop). This use of objects gives a solution of designing large scale programs by writing small-scale software units that communicate with each other, rather than a huge system (Parr). This tactic of "divide and conquer” is employed in both procedural, with the use of subroutines, and object-oriented programs, with the use of objects (Nemirovsky). However, in a procedural program, the programmer must tell the computer how to perform an action and when to execute it, in contrast to an object-oriented program, where the programmer only tells the object what to do, and then the object performs it (Sherer). This means that a programmer doesn't need to know how or why an object works, but merely what it does; demonstrating the principle of information hiding, a method of encapsulation in which only certain details are able to be seen (Orr). Information hiding allows for large scale projects to run much more smoothly because programmers don’t need to know the implementation of a class to use it, and allows changes to be made without drastically affecting the entire program, as well as a certain degree of consistency within the application, as programmers working on the project are using the same base classes
(Lindsay).
When code is segmented into smaller sections, each with their own separate individual functions, programs become easier to work with. For example, in an object-oriented program, if a program needs to know the month in a two-digit format, it sends a message to a Date object with the message asking for the date in that format, rather than accessing the date from a variable floating somewhere within the program (Waldrop). Within that same program, another object can ask for the date in a three-letter format by sending a message that corresponds to that demand to the same Date object, and the Date object would return that date. Object-orientation also allows the developer to assemble his or her code in the same manner that he or she thinks about the problem (Waldrop). The developer can create an object named ”Airfoil” and define a function that instructs the object how to handle data, and then the developer can send a message to the Airfoil object to calculate something, such as wind resistance (Chastain). By developing and debugging small components independent from the program, developers are able to isolate and test code more efficiently, and can assume that the program works as advertised, rather than guess where problem may lie (as with the case of a procedural program) (Chastain). By breaking up code into smaller pieces, object-oriented programs become easier to modify, and because of this many companies are interested in reaping the benefits of the object-oriented approach, that is, reusable and easily modifiable programs (Patrizio). Object-oriented programming can be considered better at representing the real world than procedural programming because object-orientation allows for more intricate and dynamic interactions as well as allowing non-technical workers to better understand and participate in the maintenance of a program because objects better appeal to the natural human cognition patterns (Archwing). An example of an object-oriented program’s ability to be modified can be demonstrated in a payroll program; if the program was written procedurally, the area that assesses the employee's paycheck would be in an "if-then" form, versus an object-oriented program, which would send messages to all the employee objects, which would then calculate all the paychecks (Sherer). Any modifications done to the procedural program might cause a chain effect in the program, making unintentional changes. Object-oriented programs also become easy to build upon in case the scope of the project grows larger
because of the principles stressed in object-oriented programming, such as encapsulation and inheritance, allow the application to expand quickly, and pre-existing classes do not have to be modified in any way because objects interact with each other through their methods and messages (Chastain).
Object-orientation offers many tools and principles that allow programmers to create dynamic programs; however, learning to use these tools can prove difficult. An entire way of thinking was built off of the procedural method, and “reprogramming” the programmers may take a lot of effort on the developer’s part before they can fully reap the
benefits of clarity and reusability (Waldrop). Procedural programming is action-oriented and solves problems through a series of logical steps, versus object-oriented programming, which looks at the entire problem as a whole and then derives a solution with the use of a series of reusable classes (Patrizio). The object-oriented approach presents a radically different method of method approaching software: code and data become merged into one single, cohesive unit— the object, and is an abstraction of a set of real-world things, such as "date" or "employee" (Archwing). Systems are made up of multiple objects, such as date, or processing, and make requests with messages which ask for specific pieces of information (Archwing). This different way of thinking can be met with resistance by some, as in the case or Chevron’s programming staff, who have difficulty grasping the concepts (Moser).
A method for tackling the problem of learning how to use object-oriented programming and concepts is through the use of graphical user interfaces (Moser). Graphical user environments have been in use by high school computer classes in hopes to intrigue students to Iearn object-oriented programming by showing the fun, enjoyable side of programming without having to touch the dense terminology of the industry (Demski). For example, many high schools have begun to use the BlueJ graphical user interface, which displays coded boxes and arrows that allows students to watch the concepts in action, and allows them to get a clear understanding of the concept (Dernski).
However, learning how to use object-oriented programming is not the only problem, but when to use it. Object-oriented programming, while very good at managing data complexity, is difficult to apply, which may be a major reason for programmers not to adopt object-oriented programming. Marc Funaro, a computer programmer, made a blog post detailing his experience in trying to incorporate object-oriented programming principles into his own programs, and stated that by doing so, had almost ruined his business (Funaro). Marc was under the impression that by incorporating aspects of object-oriented programming, his programs would become much more efficient and reusable (Funaro). However, this is only partly true, because in order to fully take advantage of object-orientation, one needs to learn how use object-oriented analysis and design; using an object-oriented language will not yield the promised benefits unless one learns to think in the appropriate manner (Buckier). Brian Carr, a seasoned software architect, stated that programmers who use an object-oriented language but are not thinking in an object-oriented way are essentially procedural programmers; additionally, learning how to use object-oriented programming does not make one a better programmer, but rather, adds another tool to the programmer's disposal
(CF OOP Debate). Carr also notes that object-oriented programming is better than procedural in one aspect: managing complexity. Funaro also complained about design and implementation time when using object-oriented programming, and that a project done procedurally would be completed much more quickly (Funaro). Mike Chandler, another object-oriented programmer, commented on this, saying, “There are some projects that procedural programming would be better suited than OOP, especially those that are smaller scale. When you’re designing a program, you really need to think about the customer’s needs. Will he wants to modify or extend the program? That’s when you need OOP” (CFOOP Debate).
In this age of technology, advancements are being made very quickly, however just because progress is being made, doesn’t mean we should abandon older methods. Object-oriented programming, though powerful and very flexible, is not without its drawbacks, suffering from longer design and implementation times. Procedural programs, though inflexible, are quick to design and implement, and may even prove superior to object-oriented programming is smaller scale projects if fast delivery is key. However for the mid to enterprise level software systems, the object oriented approach does cost a little bit more up front but extraordinary gains are realized during the maintenance and enhancement phase, which is where most cost is incurred.
No comments:
Post a Comment