i'm back to needing a work icon

[meganursula]

Question for object oriented gurus:

I am currently reviewing some code implementing a current standard of an algorithm i frequently use. (I want to examine some modifications to the algorithm, but, i need a good baseline to compare to.) In it we see something like:

struct velocity
{
int size;
double v[D_max]
};

There are a lot of these structs - position, quantum, etc.

Thing is, in my code, i generally declare
num_dim = n; // this is what they are using size for up above
double position[num_dim];
double velocity[num_dim];

(quantum, for the record, appears to be taking the place of what i usually declare as a constant Eps, and is used to get around numerical issues when looking for zero.)

etc. I do not have additional structs. Thing is, i find all this structifying to be sort of pointless and irritating. Pointless because i do not know what the structs are adding to the code. Irritating because i think they add a level of obfuscation, rendering the code not only longer, but also much less readable.

My question - what, if anything, am i missing in this situation? I get, generally, what object oriented-ness does for you. But i haven't used it very much in the past 6 or so years. (Matlab's excuse for object oriented isn't worth bothering with.) Right now i find myself faced with a few examples of modern code that are object oriented up the ass, and it just seems like it all has been taken too far. If i give myself three months will i become a believer? Will i stop feeling like there should be some sort of natural progression through code and adapt to having objects interacting at will?

Comments

[angelbob.livejournal.com]

It is entirely possible that you will not become a believer, nor find any reason to use OO stuff here, especially in C/C++, which is what I assume I am seeing above.

Stroustrup, the guy who invented C++, foresaw objects being used primarily for very large chunks of code and data, not so much for little things like points.

You might make a position/velocity array, as a whole, be an object. That depends if there's much anything you would normally do to the whole thing together. Big vectors are often object-ized in other languages to give you easy syntax for things like dot products, cross products, et cetera. I wound up doing a lot with object-ized vectors while writing a lot of numerical integration and differentiation code, for instance. You save passing in two arrays and a size for every function call, instead passing in only an object pointer -- yay for less typing.

Then again, if you don't do much of that then you probably don't care. So yeah, depends on the algorithm, depends if you'll be doing more with the same sort of objects (position/velocity arrays), and so on. But your basic intuition (that a single velocity or position shouldn't be an object) is dead on for the sort of situations it sounds like you're discussing.

[bhudson.livejournal.com]

A lot of OOness is a bad solution to a very real problem, and occasionally it solves so few problems it's not worth the effort (or sometimes it causes more than it solves).

Things I like to use structures for:
- encapsulation: keep related data together, which makes it easier to pass it around or change the implementation. Sometimes you end up replicating data, like in your example. That rarely matters.

- type-checking. You're declaring a velocity, and that has a bunch of functions related to it that deal with velocities. If your function demands a int and a double*, you might screw up and pass in the wrong int or the wrong double*; if it demands a velocity*, you're not going to make that mistake.

- in C++, you can (and should) declare operator[] on array-like classes, so that you could then use velocity v; v[2] = whatever; and it would check the bounds of your array. You also get access to template libraries like STL and Boost, which have all sorts of extremely useful data structures like arrays that resize automatically, linked lists, balanced binary trees, hash tables, fixed-size arrays that check array bounds, etc.

[bhudson.livejournal.com]

Oh, and Eps implies you're comparing doubles wrong. Read this article, and love it:

http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm

Then, yank out the AlmostEqual2sComplement function, rename it, and use that in all your comparisons.

[(Anonymous)]

I have nothing to contribute on the technical side, but I think Cthulhu makes a fine work icon.

[georgejas.livejournal.com]

Took me 6-12 months of being deep in our OO codebase to start believing it was behaving itself while I wasn't looking. I still don't fully trust it, but my plan is to continue on this career path until I do trust it or completely lose faith.