OOP vs PP for algorithms_问答_开发者_运维开发者技术经验分享

Which paradigm is better for design and analysis of algorithms? Which is faster? Because I have a subject called Design and Analysis of Algorithms in university and have开发者_开发技巧 a time limit for programs. Is OOP slower than Procedure programming? Or the time difference is not big?

Object-Oriented programming isn't particularly relevant to algorithms. Procedural programming you will need, but as far as algorithms are concerned, object-oriented programming is just another way to package up procedural programming. You have methods instead of functions and classes instead of records/structs, but the only relevant difference is run-time dispatch, and that's just a declarative way to handle a run-time decision that could have been handled some other way.

Object-Oriented programming is more relevant to the larger scale - design patterns etc - whereas algorithms are more relevant to the smaller scale involving a small number (often just one) of procedures.

IMO algorithms exist separat from the OO or PP issue.

Neither OO or PP are 'slow', in either design-time or program performance, they are different approaches.

I would think that Functional Programming would produce cleaner implementation of algorithms.

Having said that, you shouldn't see much of a difference whatever approach you take. An algorithm can be expressed in any language or development paradigm.

Update: (following comments)

Apparently functional programming does not lend itself to implementing algorithms as well as I thought it may. It has other strengths and I mostly mentioned it for completeness sake, as the question only mentioned OOP (object oriented programming) and PP (procedural programming).

the weak link is liekly to be your knowledge - what language & paradigm are you most comfortable with. use that

For design, analysis and development: definitely OOP. It was invented solemnly for the benefit of designers and developers. For program runtime execution: sometimes PP is more efficient, but often OOP gets reduced to plain PP by the compiler, making them equivalent.

The difference (in execution time) is marginal at best.

Note that there is a more important factor than sheer performance: OOP provide the programmer with better means to organize his code which results in programs that are well structured, understandable, and more reliable (less bugs).

Object oriented programming abstracts many low level details from the programmer. It is designed with the goal

to make it easier to write and read (and understand) programs
to make programs look closer to the real world (and hence, easier to understand).

Procedural programming does not have many abstractions like objects, methods, virtual functions etc.

So, talking about speed: a seasoned expert who knows the internals of how an object oriented system will work can write a program that runs just as fast.

That being said, the speed advantage achieved by use PP over OOP will be very marginal. It boils down to which way you can write programs comfortably.

EDIT:

An interesting anecdote comes to my mind: in the Microsoft Foundation Classes, message passing from one object to the other was implemented using macros that looked like BEGIN_MESSAGE_MAP() and END_MESSAGE_MAP(), and the reason was that it was faster than using virtual functions.

This is one case where the library developers have used OOP, but have knowingly sidestepped a performance bottleneck.

My guess is that the difference is not big enough to worry about, and the time limit should allow using a slower language, since the algorithm used would be what's important. The purpose of the time limit should IMO be to get you to avoid using for example a O(n³) algorithm when there is a O(n log n)

To make writing code easy and less error prone, you need a language that supports Generics - such as C++ with STL or Java with the Java Collections Framework. If you are implementing an algorithm against a deadline, you may be able to save time by not providing your algorithm with a nice O-O or Generic interface, so making the code you write yourself entirely procedural.

For run time efficiency, you would probably be best writing everything in procedural C - see e.g. the examples in "The Practice Of Programming" - but it will take a lot longer to write, and you are more likely to make mistakes. This also assumes that all the building blocks you need are available in their most up to date and efficient from in procedural C as well, which is quite an assumption these days. Most likely making use of the STL or the JFC will in practice save you cpu time as well as development time.

As for functional languages, I remember hearing functional programming enthusiasts point out how much easier to use their languages were than the competition, and then observing that those members of the class who chose a functional language were still struggling when those who wrote in Fortran 77 had finished and gone on to draw graphs of the performance of their program. I see that the claims of the functional programming community have not changed. I do not know if the underlying reality has.

Steve314 said it well. OOP is more about the design patterns and organization of large applications. It also lets you deal with unknowns better, which is great for user apps. However, for analyzing algorithms, most likely you are going to be thinking functionally about what you want to do. In that case, I'd stick to more simple PP and not try to create a fully OO design, when you care about the algorithm. I'd want to work with C or Matlab (depending on how math intensive the algorithm is). Just my opinion on it.

I once adapted the Knuth-Morris-Pratt string search algorithm so that I could have an object that would take a character at a time and return a match/no-match status. It wasn't a straight-forward translation.