Possible Duplicate:
Pitfalls of Object oriented programming
I recently had an argument with a friend who believed that every application should be designed in an OOP manner. I know that there are definitely applications where OOP would not fit well over the design but could not think of any specific example. Can someone give me an example where taking an object oriented approach to a problem would be cumbersome or otherwise suboptimal?
I've run into a few scenarios where OO doesn't hold together, but I still find it a very powerful if widely-misunderstood approach. Some weak areas I've observed are:
The real world is really populated with real objects.
Any software the purports to solve any real problem (any problem that really exists in the real world) must be object-oriented.
You can write such programs with non-object languages (like C).
However. When you read C code, you find that it contains objects. They just aren't formalized well by the language. But even a lowly C-language struct is -- in effect -- a shabby poorly-supported object. Even in classic BASIC, a collection of parallel dim arrays is a kind of list of objects.
I know that there are definitely applications where OOP would not fit well
Such a thing can't exist and still be an "application"
Even a "pure" mathematical function still deals with "number" objects.
You could object and say "an integer isn't an object". You'd be wrong, however. An integer is an object. It has methods (+, -, *, /) and an attribute. Actually it has several class-level attributes (maximum integer value, minimum integer value, etc.)
The only way to escape from the tyranny of objects is to escape from the tyranny of data.
To have a "purely procedure" thing, you could create a "meta-procedure" or "template" or "macro" that had no concrete data type. That would be the closest you could come to a non-object thing. But to do work, it would have to be bound to a data type, meaning that you now have objects.
Realistically, I'm sure most problems can be boiled down to some sort of OO pattern. Even second-order functions (functions which take functions as arguments) can be emulated by assigning those functions to a specific object which is passed around (I believe this is called the Visitor pattern?), and currying (partial function application) can be emulated, again, via objects.
That said, generally, those feel like ugly hacks. At the end of the day, it really comes down to the developer's skill and tendencies; the compiled code should perform similarly no matter of the paradigm it's implemented in.
Sometimes, you just need something quick & dirty to get the job done. I do this a lot with perl, for example - suck data in, process it, and spit it out. No OO needed for that.
A Proof of Concept (PoC) might come into this camp: if you're trying to prove something specific then adhereing to OOp might not be on the "critical path", if you know what I mean.
For one project I worked on we deliberately built the PoC is such a way as to discourage it being turned into the PROD system, because we knew we were doing a "quick-n-dirty" for specific ends and that it wasn't production quality.
i think one of the factors which you consider in designing an application is the size and scope of work that needs to be done. as the size of the project increases, i think oop leads to a more manageable and flexible software development. well you wouldn't really think of using oop when creating an application which only computes the sin of a number aye!? just a thought!
I think it has more to do with the programmer than with the problem. That's not to say some problems aren't inherently more suited to OOP than others, but just that I think the programmer's preferences and skills are generally more important in such design decisions.
For example, right now I would probably write any program more complex than "Hello, World!" using at least some degree of object-orientedness. But that's because OOP has become quite comfortable and 2nd nature to me. Other programmers with different backgrounds and experiences might choose to write the same programs in completely different ways. There are lots of ways to frame and model every problem and what's easiest for one programmer may not be easiest for another.
Others have mentioned quick-and-dirty programs. I would go further. I would not use OO when I'm writing a small utility to do one thing well, even if it's going to be around awhile and not considered "quick and dirty". OO only makes sense when you need the flexibility that things like encapsulation and polymorphism bring to the table.
I would avoid using much OO in heavily parallel, performance critical projects. The problem is that, if you need to scale to 24 cores (I do scientific computing work and I sometimes do), then you need to keep the amount of dynamic allocations you do down or GC/memory management overhead will eat you alive. For the most part, OO can't be done properly if you're not willing to make liberal use of the heap and garbage collector.
Data entry applications are usually better written with just procedural code. At least, that's been my experience.
Any program that needs to be formally proven to be correct. Formal proofs of programs that rely on assignment are much harder than proofs of functional programs.
DSLs are a good example of languages that do not need to be and have adevantages not being OO languages. DSLs need to be tailored to the problem they are solving without adding lots of cruft. DSLs that attempt to have all of the fixings of modern general purpose languages end up not being very domain specific!
Another set of problems are logic programs. These are needed when we have a set of constraints and we need to find a solution (and maybe optimize it). In a general purpose OO language we have to do a lot of lifting to solve these kinds of problems, but logic programming languages like Prolog do them naturally.
How about whenever you have to use a relational database? Though my answer in such situations would be to turf the database, it's often completely unfeasable.
I see a real need to not go with OOP when the resources (in particular CPU and memory) are scarce. For example, but not limited to, it is the case for the networked (switches, routers, ...) or embedded devices used in industrial computing.
The fake interview of Bjarne Stroustrup talks very well about it: http://harmful.cat-v.org/software/c++/I_did_it_for_you_all
Depends on the language. Some programming languages are inherent or syntactically OOP-only. Others have basic data types and APIs that suggest a procedural coding style.
Also sometimes you want to mix and match. It doesn't make sense to wrap funtions into classes, if these just compute individual answers without ever looking at object attributes.
If however there are already multiple domain classes in an application, it makes sense to wedge the remaining functions into objects as well. A coherent paradigm makes everything more readable.
Personally, I'm mostly mix and match. If you shoehorn everything into objects, it's most likely you follow the Cargo Cult programming paradigm, not object-orientation.
In my opinion, a lot of applications that are heavily reliant on complex relational data are not best suited to object-oriented programming. Sure, you can try to abstract it all away with a heavy ORM, but when you've got two dozen tables to join, possibly with some subqueries or recursive joins, and then you have to display this data in tabular format, you might as well just do it procedurally.
At it's heart, programming is the art and science of solving problems within a set of constraints. I believe most people recognize that multiple modes of thinking exists for solving problems, object-orientation being one such paradigm. In practice, a single problem/program may require multiple modes of problems solving, and may benefit from using multiple approaches to modeling different aspects of the problem. In answering this question, I also think it's important to differentiate a style of problem solving, from a particular kind of language. One can certainly program in a object oriented or functional style in a procedural language like C.
The "object-oriented" paradigm is but one approach of decomposing a problem into a set of smaller problems that are easier to reason about and whose correctness we wish to ensure. OO is characterized by the identification of discrete actors (objects) with well-defined responsibilities, which interact by passing messages (themselves often consisting of objects) between one another. OO has proven effective at addressing problems "in the large" - such designing solutions for large scale systems whose responsibilities cover a large domain.
Other modes of thinking about problems certainly exist - and offer different vantage points from which to examine how to solve them. For instance, some problems can be viewed as a transformation of information from one representation to another. Functional programming paradigms can be an effective way of tackling such problems - essentially the problem is decomposed into a sequence of transformations from the source representation to the output representation. Functional programming, by avoiding state an mutable data lends itself better for problems where we can exploit parallelism and sub-computation caching. Not that such programs cannot be created in other styles (they certainly can) - it's just that the constructs and idioms provided by functional languages often are easier to compose with one another for such problems.
We should also be cognizant of the limitations and overhead that are introduced by certain programming styles. The approach of treating a problem as a set of interacting "objects" (whether they are materialized using language constructs or merely conceptualized in the mind of the programmer) requires establishing boundaries and constraints on how a program behaves. Such constraints may actually prove to be a barrier to effective construction of certain solutions. Take device drivers for instance. A common expectation of device drivers are that they need to be efficient in their operation. OO design does not necessarily improve efficiency of operations - in fact, OO tends to introduce additional layers of indirection and abstraction primarily to aid in maintinability and extensibility - neither of which is necessarily as important in the creation of device drivers. Similarly, programs designed in a functional style often require more memory or steps to process information due to the immutable nature of how such programs represent data.
So, to summarize my thoughts above, I would say that:
Finally, let's address the core of your question: where would an object oriented approach to a problem be cumbersome or otherwise suboptimal?
For specific examples, I would suggest that: