When not to use Object Oriented Programming?  | Forum Leader | | Join Date: Apr 2008 Location: San Antonio, TX (USA)
Posts: 2,605
| |
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?
|  | Expert | | Join Date: Mar 2007
Posts: 10,611
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by insertAlias  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
|  | Administrator | | Join Date: Oct 2006 Location: London - UK
Posts: 15,675
| | | re: When not to use Object Oriented Programming?
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).
| | Moderator | | Join Date: Mar 2007 Location: North Bend Washington USA
Posts: 5,366
| | | re: When not to use Object Oriented Programming?
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...
| | Expert | | Join Date: Mar 2007
Posts: 10,611
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by NeoPa 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
| | Administrator | | Join Date: Oct 2006 Location: London - UK
Posts: 15,675
| | | re: When not to use Object Oriented Programming?
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?
| | Expert | | Join Date: Mar 2007
Posts: 10,611
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by NeoPa 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
| | Forum Leader | | Join Date: Apr 2008 Location: San Antonio, TX (USA)
Posts: 2,605
| | | re: When not to use Object Oriented Programming?
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...
| | Administrator | | Join Date: Oct 2006 Location: London - UK
Posts: 15,675
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by insertAlias 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.
| | Expert | | Join Date: Mar 2007
Posts: 10,611
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by NeoPa 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
|  | Moderator | | Join Date: Nov 2006 Location: Iceland
Posts: 3,741
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by insertAlias 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.
| | Expert | | Join Date: Mar 2007
Posts: 10,611
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by Atli 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
| | Expert | | Join Date: Sep 2007 Location: VA
Posts: 409
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by Atli 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?
| | Moderator | | Join Date: Nov 2006 Location: Iceland
Posts: 3,741
| | | re: When not to use Object Oriented Programming?
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.
| | Expert | | Join Date: Mar 2007
Posts: 10,611
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by Atli 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
| | Moderator | | Join Date: Nov 2006 Location: Iceland
Posts: 3,741
| | | re: When not to use Object Oriented Programming?
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 "Appreciation 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)
| | Expert | | Join Date: Mar 2007
Posts: 10,611
| | | re: When not to use Object Oriented Programming?
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
| | Newbie | | Join Date: Nov 2008
Posts: 8
| | | re: When not to use Object Oriented Programming?
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
| | Expert | | Join Date: Mar 2007
Posts: 10,611
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by JohnBoy2 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
| | Administrator | | Join Date: Oct 2006 Location: London - UK
Posts: 15,675
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by JohnBoy2 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.
| | Newbie | | Join Date: Nov 2008
Posts: 8
| | | re: When not to use Object Oriented Programming?
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
| | Administrator | | Join Date: Oct 2006 Location: London - UK
Posts: 15,675
| | | re: When not to use Object Oriented Programming?
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!
| | Moderator | | Join Date: Nov 2006 Location: Iceland
Posts: 3,741
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by JohnBoy2 [...]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.
| | Newbie | | Join Date: Nov 2008
Posts: 8
| | | re: When not to use Object Oriented Programming?
Quote:
... the problem is restricted to a particular approach and not the concept as a whole.
Nicely stated, and absolutely true. Quote:
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 "Appreciation 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. Thank you!
John
| | Expert | | Join Date: Mar 2007
Posts: 10,611
| | | re: When not to use Object Oriented Programming?
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 ElementProcessors 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
| | Expert | | Join Date: Mar 2007
Posts: 10,611
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by Atli 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
|  | Moderator | | Join Date: Apr 2007 Location: New England
Posts: 7,148
| | | re: When not to use Object Oriented Programming?
fortran I believe is still one of the best at doing floating point math. That's surely not OOP
| | Newbie | | Join Date: Nov 2008
Posts: 8
| | | re: When not to use Object Oriented Programming?
Quote:
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
| | Moderator | | Join Date: Nov 2006 Location: Iceland
Posts: 3,741
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by JohnBoy2 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.
| | Newbie | | Join Date: Nov 2008
Posts: 8
| | | re: When not to use Object Oriented Programming?
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
| | Administrator | | Join Date: Oct 2006 Location: London - UK
Posts: 15,675
| | | re: When not to use Object Oriented Programming?
Ludicrous may be pushing the point a bit far, but I certainly feel that a solution within the concepts of the current model is advisable where possible.
Mix-and-match is likely to introduce confusion when it comes to maintenance etc etc.
PS. Don't be too surprised if you encounter strong partisan feelings on this of all subjects. The discussion is likely to be intelligent and informed - but the feelings may get hotter than the subject matter would indicate.
| | Expert | | Join Date: Mar 2007
Posts: 10,611
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by 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. True, but you are changing the problem space now; something that's supposed to be in the list of requirements. The solution you described was just plain stupid; the solution I gave was the best you can get before you came up with the static list requirement.
Indeed if a list doesn't change much and one needs that list all the time, a precomputed total might be the best solution. It all depends on the requirements and feeding parts of the requirements piece meal is not fair play.
kind regards,
Jos
| | Moderator | | Join Date: Nov 2006 Location: Iceland
Posts: 3,741
| | | re: When not to use Object Oriented Programming?
How about if you... could pass a parameter to the method that lists the reports, and if set, the parameter would have that method count the total when listing the reports, return it via the parameter and set a private variable which the total function would return.
Efficient, no?
| | Newbie | | Join Date: Nov 2008
Posts: 8
| | | re: When not to use Object Oriented Programming?
Quote:
It all depends on the requirements and feeding parts of the requirements piece meal is not fair play.
It's absolutely not fair, but that is the way the world works. I have never - ever - experienced a project where all the requirements showed up in a nice organized pile right at the beginning of development. And even if you could get it that way, software requirements change over time. What worked last year doesn't fit the bill this year. New products, different ways of doing business, new laws, new taxes, new challenges. Software is a living thing. Quote:
Indeed if a list doesn't change much and one needs that list all the time, a precomputed total might be the best solution.
Yes, I agree, and that's the spirit! It just depends. What I've seen time and again is that what we implement during the initial development of a project is optimized for the way the we envision the software at that time. Not long after deployment, however, it becomes clear that the needs of the business change, and usually in ways that were difficult or impossible to foresee (or else we would surely have architected the software to accommodate it). And since the whole thing was optimized for the previous needs, we now have something that is going to be quite difficult to overhaul. Indeed, usually the software is thrown away and a whole new initiative is embarked upon.
Now that's wasteful. Quote:
How about if you... could pass a parameter to the method that lists the reports, and if set, the parameter would have that method count the total when listing the reports, return it via the parameter and set a private variable which the total function would return.
That's more like what I would have done, although it might have broken existing code. Since there was only one place that these totals were being asked for, I didn't feel the need to publish some api to encapsulate the totaling of these beans. As soon as we would have received a new set of requirements that dictated totals of these things all over the place, then I might invest the time in re-factoring to take advantage of organizing code that way. Note that what we're talking about now is not really an OO thing, but just good, structured programming.
Back to the OP's question: even optimized, straight-C routines are often nowhere near efficient enough to be used in the inner loops of some aspects of a game engine. I've written compilers that will take elements of the problem space and generate assembly code to get to where we needed to be performance-wise. The more sophisticated the features of a language get (OO or otherwise), the more room there is for the compiler to produce crappy code. It's a well-understood problem in certain areas of software development - games and other real-time sims. certainly among them.
Cheers,
John
| | Expert | | Join Date: Mar 2007
Posts: 10,611
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by JohnBoy2 Back to the OP's question: even optimized, straight-C routines are often nowhere near efficient enough to be used in the inner loops of some aspects of a game engine. I've written compilers that will take elements of the problem space and generate assembly code to get to where we needed to be performance-wise. The more sophisticated the features of a language get (OO or otherwise), the more room there is for the compiler to produce crappy code. It's a well-understood problem in certain areas of software development - games and other real-time sims. certainly among them. That is definitely not true: the complexity of the source language doesn't affect the complexity of the target language; for OO languages with single inheritance of implementation one single 'this' pointer per object is enough; it points to the class the object belongs to; the class stores a vft (Virtual Function Table) for all the virtual functions. A simple indirect subroutine call is enough to call one of those functions.
Data member access is completely equal to structure member access; the compiler figured out the offsets and all so the target code is as simple as can be. You haven't been in the correct compiler writers team if you think that target code for complex (OO?) source languages is more complex than others ... Granted the compilers themselves may be more complex than a compiler for a toy language but that's about it.
kind regards,
Jos
| | Moderator | | Join Date: Mar 2007 Location: North Bend Washington USA
Posts: 5,366
| | | re: When not to use Object Oriented Programming?
What you say is true.
However, JohnBoy is hung up on games and real-time sims. There's no time here for properly created and intialized objects. Everything is hand-made, highly optimized and will never be reused again. These folks don't need OO or OOP by any stretch. Neither do operating system kernal writers.
OO and OOP are for complex systems consisting of hundreds, or thousands of interacting objects where re-use is the prime driver, where the current version that works is the result of an earlier version that also worked. No hand-tailoring here. If there's a resource problem, get a faster computer, or more cores. When changes are made, the ripple of change must be minimal. Therefore, no spaghetti code but instead strict encapsulation. Polymorphism helps to shield the details of the object from the application allowing new obejcts to be added without having to change the application.
Has anyone on this thread read any Grady Booch?
| | Newbie | | Join Date: Nov 2008
Posts: 8
| | | re: When not to use Object Oriented Programming?
Well, I think I can agree with the spirit of what you're saying, but there are a couple points I'd like to clarify:
- I'm not hung up on any particular kind of software - the OP noticed a posting that was from a game company, which is why I am using it as an example.
- Properly initialized data is just as important in high-performance apps. as it is elsewhere, and is definitely not exclusive to OO. There are cases where it won't matter, however, and you can get a marginal boost in performance by not initializing things.
- Re-use is also not exclusive to OO. Many of the highly-optimized processes that have been made for high-performance apps. have been bundled into ibraries that are used again & again. Sometimes those libraries have to be doctored, because some of it is hardware-dependent. I remember having to alter my compiled bitmaps engine to take advantage of 64-bit processors and the new barrel shifters of the time.
- Modern sims and scientific apps. often deal with billions of objects per second, and this is the context that is often difficult for "business developers" to understand. Small increases in performance really matter here. It can mean the difference between being able to model a certain pathogen's mitosis stages fast enough to find a cure or not.
It isn't so much OO as a principle that leads to overkill software, but the silly applications of OO techniques that can lead to large-scale inefficiencies and bad software design. Case in point: JavaBeans. The "specification" for a JavaBean is that it has to have a no-args constructor (no big deal), it must implement the Serializable interface (no big deal), and that its attributes must all be private, accessible only through public getter and setter methods, which imo is a joke.
And it is this kind of thinking that leads to inefficiencies.
| | Expert | | Join Date: Mar 2007
Posts: 10,611
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by JohnBoy2 It isn't so much OO as a principle that leads to overkill software, but the silly applications of OO techniques that can lead to large-scale inefficiencies and bad software design. Case in point: JavaBeans. The "specification" for a JavaBean is that it has to have a no-args constructor (no big deal), it must implement the Serializable interface (no big deal), and that its attributes must all be private, accessible only through public getter and setter methods, which imo is a joke.
And it is this kind of thinking that leads to inefficiencies. The example you mention is just a language deficiency: you can't have a publicly read-only property, i.e. if the property is publicly readable it is publicly writeable and vice versa. Setters that simply set a value of an object are silly but I don't see the inefficiency here; C# just camouflages the setters and getters but they are still present behind the scenes. The advantages of those getters and setters are instrumented code, sandboxed code, generated code etc.
Care to elaborate on the 'kind of thinking that leads to inefficiencies'?
kind regards,
Jos
| | Member | | Join Date: Nov 2008
Posts: 80
| | | re: When not to use Object Oriented Programming?
I'm not that expert in programming to discuss benefits of OOP but here is a short article by Paul Graham about the matter: Why Arc Isn't Especially Object-Oriented | | Newbie | | Join Date: Nov 2008
Posts: 8
| | | re: When not to use Object Oriented Programming?
Quote:
The example you mention is just a language deficiency: you can't have a publicly read-only property...
I don't know enough about other lang's to say that, but I trust that you do. I think the larger issue for Java is specifications. More than 95% of the JavaBeans I have ever written (or seen others write) all have getters and setters which simply get and set the private variable directly without any processing. This is annoying to code with, and it bloats the software by substantially increasing the size of the codebase, the compiled byte-code to be deployed, the number of methods that need to be unit-tested (even trivially to satisfy coverage metrics from the likes of Clover, et. al.) and even the amount of network traffic in the cases where you are passing these objects over the wire. Moreover, method calls are not free, so every time you want to merely access an attribute on your bean, you're pushing another method call onto the stack.
Small wonder Java has a reputation for being a performance dog and a resource hog. It's not Java itself - it's how it's used by most Java developers.
It's not that getters and setters should never be used, it's that they should only be used when it makes sense. There are occasions when you really don't want anyone to be able to directly change an attribute on a bean. In those cases, by all means make the attribute(s) in question private, and provide accessors to manipulate them.
My argument is that for most routine development, these occasions are the exception not the rule, and we should not be making private attributes with getter/setter methods into a specification that every certificated trendoid instantly takes as gospel and clutters the codebase with.
John
| | Expert | | Join Date: Mar 2007
Posts: 10,611
| | | re: When not to use Object Oriented Programming?
Quote:
Originally Posted by JohnBoy2 My argument is that for most routine development, these occasions are the exception not the rule, and we should not be making private attributes with getter/setter methods into a specification that every certificated trendoid instantly takes as gospel and clutters the codebase with. We agree on that: setters without range checking or other processing is just plain silly but don't forget that Java was meant to be a language for toasters and other small appliances. The language itself should've been a bit bigger (e.g. read only public members etc.) C++ doesn't do any better here, C++ too doesn't distinguish between reading or writing a member variable, i.e. its access rules are the same for both (nor does any other language as far as I know, C# just hides that fact which doesn't solve the real problem).
kind regards,
Jos
| | Lives Here | | Join Date: Sep 2006
Posts: 12,070
| | | re: When not to use Object Oriented Programming?
Many web development frameworks these days require them though.
But then again that's not the only reason why they are a mess.
|  |
Similar Software Development bytes | | |  /bytes/about
We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights.
Get the best answers to your questions from over 226,295 network members.
|
