I have definitely seen people make the sort of mistakes you're talking about, and it always makes me worry when I see methods taking or returning complex data structures that are not objects, but I've also seen internal data structures that were objects for no real reason. Being able to ignore the internal data structure of other classes is one of the great boons of OO coding, even if the internal structure is something unusual like a hash of hashes.

99% of the time, the fact that multi-tier collections of collections being exposed to a single module, points to poor modulization of code, or lack of OO design.

If the code happens to have a OO face, then it indicates lack of genuine understanding of OO.

As a matter of fact, 99% of the time, OO classes should only see one level of collection. The elements of the collection, whatever how complex they are, their internal structure should not be exposed to the class that holds the collection.

There is absolutely no reason for a person to believe that his/her data is complex enough and cannot be clearly contained in layers.

Naked complex data structure can easily create maintainance nightmares.

Abigail

... and situation, and available time. Ever since I got the hang of using deeper/heavier data structures in perl, I've become more and more reliant on being able to handle more problems with less code in shorter amounts of time. Usually, the design is "simple" in the sense of optimizing the access to data for a particular activity: fewer looping blocks are needed overall, and the ones that are needed can be more compact, when the data are well organized for the task at hand.

I do worry sometimes about taking things too far, stuffing too many different things into one structure, and pushing the code to the point of being too obscure. But it often turns out to be a self-correcting condition -- if the data structure gets too complicated, so does the code that handles it, to the point that a self-respecting perl programmer will balk at that and start looking for a simpler alternative.

I agree that there should be a "shallower" threshold for drawing the line on depth/obscurity of data structures when building an OO design -- or at least when putting together an object's API.

...their internal structure should not be exposed to the class that holds the collection.

i.e. selectActiveUsers and selectInactiveUsers would return an object of the same dto class, containing all user objects.

It enforces the idea in my mind, that data structures are useful for internals to classes and to algorithms, but not as a non-volatile method of communicating to the outside/out-of-class world of your program.

Complex data structures are in no way analagous to objects. They're more like C's structs. Perl lacks a way to produce the stricter layout of a struct (ignoring CPAN modules), largely because it has fewer types to deal with than C.

Even OO projects need to store and retrieve data somehow. You might wrap it up with an object, but there must be an underlieing datastructure in there. It could be simple or complex, depending on the requirements of the object, but it is there.

The elements of the collection, whatever how complex they are, their internal structure should not be exposed to the class that holds the collection.

I suspect that pg meant to say "should not be exposed BY the class that holds the collection." Then it makes perfect sense.

This was a very nice reminder for me, anyway, of the usefulness of OOP in certain cases. Although I enjoy the freedom, speed, and flexibility of Perl, it doesn't mean that we should not use a little more structure when it's beneficial to do so.

I must admit that OOP is a weakness of mine, but I am diligently working to improve in that area.

pg's meditation was timely for me. Your question helped expose the crux of pg's point. That's why I'm voting for both of your nodes.

Many data structures have very specific rules. Say you wanted to create your own queue. You'd create an array, and do shift's and pushes. But imagine if some dork decide to access or worse, take out the middle item.

Yeah, it's stupid of the developer to do that, but you don't enforce rules on the data.

Let's say you were working on an array, and you have a function returnAverage. One optimizatio you could do, is recalculate the average as you are adding stuff to this array, keeping track of how many elements there are. You wouldn't have to add up all the #'s and divide. You could keep track of the current average, multiply by the current number of items to find the total to create your new average. This is especially true if your array is 100,000,000 elements big.

But imagine if someone directly adds data w/o updating the statistics. Then you have to add all those numbers since they didn't update the statistics. Imagine it like rebuildinga db index. By encapsulation, you can guarantee that your data is accessed in certain ways and things are done in a certain manner.


Play that funky music white boy..

Of course there is always more than one way to do things. If I were to implement an array of which I always mantained a statistical average of the values of its elements, I might consider tieing the array to a module that overloads the STORE function (and all other applicable to the situation) so that any time a new value is added by any means, the statistical average attribute is updated.

The attributes could then be obtained via access to the object's methods. ...perhaps a "getstat()" method which would return a reference to a hash of stats.

Such an approach would guarantee that the stats are always accurate, as there would be essentially no way to modify the array without the stats being recalculated. Performance would suffer a bit, but accuracy would be guaranteed. By using a tied array, the user could do whatever the hell he wants, directly to the array, and an accurate stat. would still be maintained.

:) Just a thought. And of course, it came to me because I've been playing with tied variables the past few days. Seems like a cool solution though.




Dave

Being new to Perl, I did not have the luxury of taking the time to learn it thoroughly (i.e the OO part) before I began working on my project.

However, what made me choose Perl over any other language, is that the complex data structures allowed me to link together a lot of data in very complex ways (and yes, the ways in which they are linked are truly complex due to the nature of the data itself).

It should be noted that this program in 'stand-alone'. It's input is a flat file with horrible amounts of intertwined data, it's output is some csv files, and an xml file. If it breaks, it will need to be fixed, but no other user/programmer will ever have to interact with it.

From this complex data, I constructed an xml file for my fellow workers to use, when they need to use the same information for other purposes.

When they need to cross-reference the data (is x in b under condition y?), their c-code is much more difficult to maintain than the similar perl structures.

With this knowledge, I have been singing the praises of Perl, for it allows me, simply, to manipulate data in ways that would otherwise most likely require a database.

To aid in maintainability, all of the relevant properties of each data structure was accessed via constants, given meaningful names (this is an arbitrary example, it's not really from my code)

 use constant ADDRESS => 1 
use constant POSTAL_CODE => 2
$persons{$name}[ADDRESS] = $addr;
if (exists $areas{POSTAL_CODE}[ADDRESS]{$addr}) 
  { ... do something...}
[download]

Could this have been done using OO?

Maybe.

Would it have been faster to code, and easier to maintain?

Probably not.

Remember, that not all solutions apply to all problems, and not all 'good rules' apply to all situations.