Situations where OOP is not the right tool

Hi everyone,
I do have experience in object oriented programming.
Specifically I would like to know what context I couldn't apply object oriented programming and why I couldn't apply object oriented concepts.

Thanks and regards,

Nuwan Arambage

One example I could think of are programs which run on devices with limited memory/processing power. These applications are extremely small compared to enterprise applications, and the benefits OOP offers don't make up for the costs of object creation, late binding, etc.

yes it's true. Embedded programming doesn't deal with object oriented paradigm.it is a separate area of programming I mean when it comes to enterprise software development, object oriented programming is not the right tool for all the situations.

In enterprise software development context, what circumstances doesn't allow you to use OOP as a programming paradigm.

Thanks & Regards,

Nuwan Arambage.

Nuwan Arambage wrote:
In enterprise software development context, what circumstances doesn't allow you to use OOP as a programming paradigm.

Legacy systems written in a language that doesn't support OOP, e.g. COBOL, C, RPG..? Applying the principles of OOP could be possible in non-OOP languages, but beyond a point it becomes difficult...

I saw an interesting talk by Richard Hickey about how most implementations of OOP are not the right tool for modeling things other than Identities. (and how Clojure is).

for this discussion, an identity is an entity that has a state, which is its value at a point in time. And a value is something that doesn't change. 42 doesn't change. June 29th 2008 doesn't change. Points don't move, dates don't change, no matter what some bad class libraries may cause you to believe. Even aggregates are values. The set of my favorite foods doesn't change, i.e. if I prefer different foods in the future, that will be a different set.

Here is the video.

Functional Programming uses immutable values. This is pretty easy to understand when dealing with a value like 42 or even a Date object and gets a little harder (for me,anyways) when thinking about the above set of favorite foods.

OOP unifies identity and state: To get the state without also grabbing the identity of your object, you need to copy it. You can't copy it or even observe it without placing a lock on the object so no other processes can change it.

So a purely functional language like Clojure turns the IS A relationship between identity and state into a HAS A relationship. An Identity has a state. The state is immutable. Later, it will have a different state. When I read the state in a concurrent environment, there is no reason to protect it because it is immutable. In java terms, everything is "Atomic" by default

to put it another way:

Instead of modelling me as an object whose internal state
changes as I change (from moment to moment), you instead model me as a
reference which points to a different immutable value as I change.

I mostly paraphrased from the following article:
http://clojure.org/state