When not to use Object Oriented Programming?

[NeoPa]

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.

[JosAH]

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

[Atli]

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?

[JohnBoy2]

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.

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.

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

[JosAH]

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

[weaknessforcats]

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?

[JohnBoy2]

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 "specificat ion" 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.

[JosAH]

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 "specificat ion" 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

[serdar]

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

[JohnBoy2]

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

[JosAH]

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

[r035198x]

Many web development frameworks these days require them though.
But then again that's not the only reason why they are a mess.