When is Object Oriented not the correct solution?

问题:

I've encountered lately some opinions saying that Object Oriented design/programming should not always be used.
Do you know some use-cases that will not benefit from and should not use Object Oriented design?

For example: there are some problems (concerns) that will benefit from AOP.

回答1:

Some problems are best expressed using other paradigms such as Functional Programming. Also, declarative paradigms allow more robust formal reasoning about the correctness of the code. See Erlang for a good example of a language with certain advantages that can't really be matched by OO languages due to the fundamental nature of the paradigm.

Examples of problem domains where other language paradigms have a better fit are database queries (SQL), expert systems (Prolog, CLIPS etc.) or Statistical computing (R).

回答2:

In my experience one of the places that does not benefit from OO design is in low end embedded systems. There is a certain amount of overhead required to do OO and there are times you cannot afford this overhead. In a standard PC the overhead is so minimal it’s not even worth considering, however in low end embedded systems that overhead can be significant.

回答3:

Cross-cutting concerns benefit from Aspect Oriented Programming (AOP). By cross-cutting, I mean functionality that could benefit various parts of the application and that really do not belong to a particular object. Logging is usually given as an example. Security could be another. For example, why should a Person object know anything about logging or who should be allowed access to it?

回答4:

One that easily comes to mind... Database-y web applications.
In such a scenario, it makes more sense to conform to an accepted framework.. rather than eek out a nice OOP design. e.g. if you have to do some kind of complex query with JOIN and ORDER BYs .. SQL will kick object butt.

Choose the solution based on the problem... instead of hammering the problem till it fits a solution.

回答5:

The fundamental principle to understand here is that there is no universal methodology, paradigm or approach that can be applied to all problem domains. These are typically designed to cater for a particular set of problems and may not be optimized for other domains.

It is just like an algorithm for a typical type of problem (e.g. Sorting). There cannot be a universal algorithm that is applicable to all possible scenarios or datasets.

Same for OOP. I would not apply it to a problem that is essentially AI related and can be better solved using declarative programming. I would certainly not apply it to develop device drivers that require maximum performance and speed.

回答6:

OOP and AOP are not mutually exclusive, the are complementary.

As for OO, there are certainly case where it's less apllicable. If there weren't all we would have is OO languages. For purely number crunching tasks, many people still prefer Fortran. Functional languages are useful when you're dealing with concurrency and parallelism.

Also when your app is mainly just a database with a GUI over it (like a CRM app, for instance) OO isn't very useful, even though you might use an OO language to build it.

回答7:

The advantages of OO design are expandability and maintainability. Hence, it's not of much use where those features aren't needed. These would be very small apps, for a very specific short-term need. (things that you would consider doing as a batch file or in a scripting language)

回答8:

I wouldn't bother with OOP if the programming language that you are using doesn't easily allow you to use OOP. We use a BDL at my workplace that is made to be procedural. I once tried to do some OOP, and well, that was just a big oops. Shouldn't have bothered.

回答9:

Not good enough? I don't know if I can come up with an example of that, but I do know that some REALLY simple applications might not see any "benefits" in the beginning of using a fully object oriented design model. If it is something truly procedural and trivial, however, in the end, it might need to be re-visited.

回答10:

I would sudgest you visit wikipedia and read their articles about different types of programming languages.

Saying that a type of programming "isn't good enough" doesn't make any sense. Each type has a purpose. You can't compare them. They're not made to do the same thing.

回答11:

Any time you can't think of a good reason for OO is a good time to avoid it. (Sounds facetious, but I'm serious.)

回答12:

OOP could be a little too much if you're creating an incredibly simple application or procedural application, as other posters have said. Also, I don't think AOP necessarily needs to replace OOP, if anything it helps to reinforce good OOP design.

回答13:

Echoing Nigel, SQL seems almost implicitly to be incompatible with any kind of abstraction (including subqueries and functions).

回答14:

Well, OOP is not especially orthogonal to anything (except perhaps other ways of getting polymorphism) so...uh...whatever.

回答15:

Object Oriented programming is good solution if you make good design.