When not to use Object Oriented Programming?

[Curtis Rutland]

I was reading through some job postings on a game developer's web site (without any real interest of applying). One of the ones that I saw had this bullet point in the requirements:

• Appreciation of when not to use Object Oriented Programming.

I've done almost all my work in OO languages...so can someone enlighten me? When do you not want to use OOP?

[JosAH]

I've done almost all my work in OO languages...so can someone enlighten me? When do you not want to use OOP?

Object oriented programming isn't the one and only 'truth' (mind the quotes). There are quite a lot of problems that are easier, and more naturally, expressed by using a functional programming language or a logic programming language. Don't get stuck in one single paradagm; you'll think that the whole world is OO; it isn't. On top of that: most people program OO-ish, not pure OO (see C++ or Java for examples); and please don't ask me for a strong definition of 'pure OO' ;-)

kind regards,

Jos

[NeoPa]

Maybe they're after someone coming in to say confidently that they don't see any scenario where OOP is less appropriate than procedural programming.

I was thinking of specific interrupt handling - but if anything, that is quite similar to OOP in its design. It's more of a stretch for those with procedural training (so much so that I found myself quite unable to convince an otherwise intelligent programmer of why his code wasn't able to work reliably within the interrupt space).

[weaknessforcats]

This all depends upon what you call OOP.

In C++ all execution occurs within a function. It doesn't matter whether you pass the address of the object as an argument (regular function) or whether the compiler does it (member function) so you can't say that OOP is using member functions. In this context C is object-oriented.

Maybe you say OOP is substituting one object for another (using polymorphism). However, you can't do this in C++ since C++ does not support the Liskow Substitution Principle. As implemented, C++ permits substituting only the address of the object but not the actual object itself. In this context C++ does not support OOP.

etc...

[JosAH]

I was thinking of specific interrupt handling - but if anything, that is quite similar to OOP in its design.

I don't understand that; care to elaborate? Please write slowly, I'm a slow understander ;-)

kind regards,

Jos

[NeoPa]

Procedural programming typically expects the flow to be sequential. Essentially one stream of logic.

OOP doesn't seem to require it work this way so much. It expects that triggers may arrive from all different sources.

Similarly, interrupt processing requires an understanding of the code not necessarily flowing from top to bottom in such a simple fashion.

Does that make sense?

[JosAH]

Does that make sense?

Yes it does but your mixing up event driven programming with just OOP; OOP doesn't say anything about asynchronous events or the like. OOP can be as procedural as can be.

kind regards,

Jos

[Curtis Rutland]

I think you're mixing event-driven programming with OOP. OOP can be procedural, and I think that non-OO langs can be event-driven.

EDIT: LOL, great minds think alike, Jos...

[NeoPa]

I think you're mixing event-driven programming with OOP.

Very possibly. I stopped progressing when OOP came along. I've picked up a little of the concepts here and there but make no claims to a proper understanding of the principles.

[JosAH]

Very possibly. I stopped progressing when OOP came along. I've picked up a little of the concepts here and there but make no claims to a proper understanding of the principles.

No problem; OOP is basically about structuring not only code (procedural programming) but also the data on which the code acts. We create 'things' or 'objects' with that and add a whole lot of hulla baloo on top of it (inheritance, polymorphism, data hiding and what have you). The topping is mainly because humans tend to make a mess out of every discipline. The programming part (normally the procedural part) can be anything: functional, logic or even just assembly code.

kind regards,

Jos

[Atli]

I was reading through some job postings on a game developer's web site (without any real interest of applying). One of the ones that I saw had this bullet point in the requirements:

• Appreciation of when not to use Object Oriented Programming.

I've done almost all my work in OO languages...so can someone enlighten me? When do you not want to use OOP?

Keeping game development in mind, I would imagine that a less complex OO structure might help increase performance.

For example, when you get into OOP you tend to tear the code up into pieces, creating methods for all tasks, even tasks that may in fact only be called from a single point in the entire application. It makes sense from a design point of view.

But from a practical point of view, simply removing the method and placing the code at that single point would reduce the overhead of calling the method, and every minor tweak counts in game development.

[JosAH]

But from a practical point of view, simply removing the method and placing the code at that single point would reduce the overhead of calling the method, and every minor tweak counts in game development.

C++ and Java HotSpot compilers are very good at inlining your code for you.

kind regards,

Jos

[Studlyami]

For example, when you get into OOP you tend to tear the code up into pieces, creating methods for all tasks, even tasks that may in fact only be called from a single point in the entire application. It makes sense from a design point of view.

But from a practical point of view, simply removing the method and placing the code at that single point would reduce the overhead of calling the method, and every minor tweak counts in game development.

You MAY gain a slight performance advantage, but how many times have you had to go back and change a few lines of code, or have to do the same functionality in another location (after the initial piece of code is written). The point is we are not perfect programmers and things do change. If you have separate methods, the time it takes to change and modify the code is considerably less than the time it would take you if you didn't create the methods. Also correct me if I'm wrong, but isn't that the point of inline functions?

[Atli]

I would imagine that, in game development, sacrificing the time it takes to edit multiple copies of the same code snippet is an acceptable loss, even if it only increases the performance by a tiny amount.

I'm no game developer myself, and I don't really use the languages preferred by them, so this is all theoretical in my mind. It could very well be that my example is rendered void by using the right compilers, I don't know.

But my point is still valid, even tho my example may be off target. OOP adds a layer of complexity to the application, which may degrade performance. Knowing when not to add more on top of that is probably what that ad is referring to.

[JosAH]

But my point is still valid, even tho my example may be off target. OOP adds a layer of complexity to the application, which may degrade performance.

You point isn't valid: OOP does not add a layer of slowing down complexity to an application; it just structures the code as well as the data in contrast with procedural programming that just structures the code. Granted, some processors may execute an 'indirect subroutine call' a bit slower than a 'direct subroutine call' but those processors aren't worth the sand they were created with.

What causes a much larger slowdown are bad algorithms and silly implementations thereof. OOP offers a way to efficiently implement good algorithms. I've had similar discussions about dynamic memory allocation with Fortran fanatics; they fiddled with common blocks and overlays thereof while not realizing that all that fiddling caused a worse slowdown than any mallow/new, free/delete could've caused.

Languages that cause a slowdown when they're handling classes and objects are silly languages; better use another language/tool that does handle those concepts more efficiently. Also OOP doesn't cause larger program executables; programmers do and they shouldn't be programming using an OOPL.


kind regards,

Jos