When not to use Object Oriented Programming?

[Atli]

You are probably right. Like I say, I don't have any practical experience with these languages (C/C++ and other such compiled languages) so this is all theoretical to me.
I mostly use PHP, which a interpreted language, where you actually have to sacrifice performance to use OOP. That's probably the source of my confusion.

But if my assumption is not valid, what would the "Appreciati on of when not to use Object Oriented Programming." be? Seems to me that if procedural and OO programing cost the same performance vise, OOP would be the logical choice most, if not all of the time. (Unless, of course, you prefer procedural)

[JosAH]

OOP isn't the end of the line; there's also functional programming, logic programming and then some. Nor are OOP and procedural programming orthogonal concepts, e.g. there exist functional programming languages that are very well capable of modelling classes, objects, inheritance, polymorphism and the entire shebang that comes with OOP.

A lot of interpreted languages added OOP capabilities to the language as an afterthought; that's exactly one cause of the slowness. OOP features require additional code, lookups and what have you then. That additional work isn't needed in, say, Objective C or C++ or Java or C#.

Please don't stare at OOP in admiration, it is just an aspect of programming, not a one size fits all shoe. Not all OOP supporting languages use procedural, or structural, programming concepts either.

kind regards,

Jos

[JohnBoy2]

OO as a philosophy suffers from drawing a certain academic personality type - the type that can't put the textbook down and actually *do* something with what they've learned. Many of the OO ideals taught in schools and books sound beautiful and elegant, but, like poetry, cannot and should not be used in real-world dialog.

I'll give you an example: once we had a need to enhance an existing report to provide totals at the bottom. The report code iterated through a List of items,
pulling out each bean and displaying it in the report. Pretty simple stuff. The guy who went to make the enhancement for adding totals approached me, confused: "I can't seem to find a sum() or total() method on the List object." I kid you not! Poor guy - I guess from a naive, ivory-tower OO-perspective, it might seem like a List object ought to know how to total itself. But come on, what a joke! Just declare a variable called total, initialize it to zero before the loop, and then inside the loop just put a line like total += item.getAmount( ) or whatever. Boom! Done! Should be a ten minute task, including unit-testing. It just goes to show you how an ideal like OO can imbreed to the point where it is too feeble to face problems from outside itself.

OO brings some nice tools to the table, which should be used when appropriate. But you do need to know when to draw the line, and yes, OO languages encourage programing solutions that tend to be less efficient in execution and require more memory. Which is a killer for high-performance apps. (games), as well as highly-scalable apps.

John

[JosAH]

OO brings some nice tools to the table, which should be used when appropriate. But you do need to know when to draw the line, and yes, OO languages encourage programing solutions that tend to be less efficient in execution and require more memory. Which is a killer for high-performance apps. (games), as well as highly-scalable apps.

Well, that's a nice bunch of non sequiturs: first you mention someone who can't program himself out of a wet paper bag and then you draw this conclusion?

kind regards,

Jos

[NeoPa]

OO as a philosophy suffers from ...
John

John,

Do you have any experience with programming OO at all? It doesn't seem to me like you have much of an understanding of the subject. It can be a culture shock to those steeped in procedural programming I know.

It's probably not a great idea to make comparisons though, until you have a better grasp of the subject. That works quite generally I find.

[JohnBoy2]

lol, yes many years programming in C++ and Java, and recently a little dabbling in PHP, the latter versions of which have some OO support.

Don't get me wrong, I didn't mean to come off sounding anti-OO. But I have seen it taken to what I consider to be illogical conclusions. In the example I posted about above, the OO extremists would want to extend the java.util.List class to include a method that would total the contents of the List (very much an OO principle). And while this might sound like a good idea, what it would mean is that after iterating through the List of objects to render them in the report, it would then be iterating through the List again to do the total when you invoke the method at the end. So then you'd be looping through the List twice instead of just once.

No big deal for small Lists, in small apps., with few users. But as you scale this up, you will definitely see problems. Multiply that inefficiency out times millions of concurrent users, with larger data sets, and you will see unacceptable response times, and a grumpy JVM which might run out of heap space. (Ask me how I know...)

This example exaggerates to make a point - but I've seen that pattern of thinking pervade the OO community. It's just something that you have to keep an eye on.

John

[NeoPa]

Personally, I come from a position of not being a great OO expert at all.

I have just learned from long experience that as soon as someone draws conclusions from a perceived flaw in the design, someone else pops up to explain why the problem is restricted to a particular approach and not the concept as a whole. It just takes a different way of thinking to perceive the better approach (or someone telling you of course :D).

This is life experience more than OO specifically of course, but I've seen it so often in relation to OO that I just felt the need to interject.

As far as taking things to their logical conclusions in the absence of common sense is concerned, I agree that's a bad idea. It's just that sometimes it's difficult to determine when this is hapenning. There are always ideas we may not be aware of waiting to expand our horizons.

Welcome to Bytes!

[Atli]

[...]And while this might sound like a good idea, what it would mean is that after iterating through the List of objects to render them in the report, it would then be iterating through the List again to do the total when you invoke the method at the end. So then you'd be looping through the List twice instead of just once.

Or, rather then count the list when the total method is called, create a private variable and modify that as each list item is added/removed.
Then return that value when the total method is called.

I realize this was perhaps just an example to make a point, but I just wanted to demonstrate the there is usually a way around these sort of situations.

[JohnBoy2]

... the problem is restricted to a particular approach and not the concept as a whole.

Nicely stated, and absolutely true.

Or, rather then count the list when the total method is called, create a private variable and modify that as each list item is added/removed.
Then return that value when the total method is called.

This is not bad, but it suffers from the possibility that in many cases, even for the same List of objects, you may not need the total. But you're adding globally to the cost of inserting/deleting/updating objects in the List. It's still cheaper to just tally the total only when needed, and on the fly when you are iterating through the list already for some other reason.

* * *

The OP just wanted to know when not to use OOP, and the answer of course is a big fat "it depends". But it does not surprise me at all to see a bullet like "Appreciati on of when not to use Object Oriented Programming." in a shop that produces games, flight sims., or highly scaled apps. I think what they're getting at there is not necessarily that they don't want you to use OOP at all, but just know when you are using an OOP principle in a way that is inefficient because it really matters in high performance software.

Welcome to Bytes!

Thank you!

John

[JosAH]

If you only anticipate for the possibility that every member of a list needs some form of processing then the following interface (Java) springs to mind:

public interface ElementProcessor<R, T {
   public void process(T element);
   public R result();
}

Your original code just has to maintain a list of ElementProcesso rs and call them when a new element has arrived. It is a breeze to come up with a TotalProcessor without any overhead in processing time. This scenario allows for expansion of the idea when a customer wants to have, say, a standard deviation of all the numbers or whatever; there would be no need to fiddle diddle with the original code again: simply implement the interface shown above, feed it to your original code and voila.

kind regards,

Jos

[JosAH]

Or, rather then count the list when the total method is called, create a private variable and modify that as each list item is added/removed.
Then return that value when the total method is called.

I realize this was perhaps just an example to make a point, but I just wanted to demonstrate the there is usually a way around these sort of situations.

Yep, (also see my previous reply); good OO systems are very fast when it comes to memory allocation and the creation of just one object at the beginning doesn't take any noticable time. The 'solution' (mind the quotes) that John came up with in his story is just ludicrous; a bit of thinking might have shown why.

There is no (noticable) overhead in OO programs; it's just that people don't know how to use it efficiently but if they want Fortran they know where to find it.

kind regards

[Plater]

fortran I believe is still one of the best at doing floating point math. That's surely not OOP

[JohnBoy2]

The 'solution' (mind the quotes) that John came up with in his story is just ludicrous; a bit of thinking might have shown why.

Ok, I have to ask: why is the 'solution' I came up with ludicrous?

John

[Atli]

Ok, I have to ask: why is the 'solution' I came up with ludicrous?

John

Because of the reasons you yourself gave us.
It's extremely wasteful to count the list every time the total() method would be called.

[JohnBoy2]

Even that depends. The same list of objects might be being used by another part of the system that does not need totals, so you don't want to be incrementing/decrementing a static total for the List every time an object is inserted/deleted/changed.

See what I mean? It just depends. Beyond simple and obvious algorithmic improvements, most decisions like that are a trade-off of some sort.

The other thing you need to consider is what developers are likely to be supporting/maintaining the codebase once you are gone. That's another discussion, but it may be related to what the OP was inquiring about, and may also be the motivation for the bullet in the job posting by the game company.

John