wood burning stoves*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Situations where OOP is not the right tool Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Situations where OOP is not the right tool" Watch "Situations where OOP is not the right tool" New topic
Author

Situations where OOP is not the right tool

Nuwan Arambage
Ranch Hand

Joined: May 05, 2010
Posts: 76
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


Thinker
Nuwan Arambage
Lorand Komaromi
Ranch Hand

Joined: Oct 08, 2009
Posts: 276
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.


OCJP 6 (93%)
Nuwan Arambage
Ranch Hand

Joined: May 05, 2010
Posts: 76
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.
Lorand Komaromi
Ranch Hand

Joined: Oct 08, 2009
Posts: 276
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...
Tim McGuire
Ranch Hand

Joined: Apr 30, 2003
Posts: 820

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
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Situations where OOP is not the right tool
 
Similar Threads
OOP,Pointers,Inheritance in Java
AOP vs OOP
AOP or OOP
Exact Difference between c and java
Pattern Used for log4j