Greetings, fellow Monks,
I typically use direct methods to access data, but now that I have become more experienced with complex data structures and references I have found objects much easier to understand. I have very little experience with OOP, but I'm trying to understand it better because I know it has definite advantages in some cases (abstraction). Therefore, I am considering rewriting parts of my code to use objects, but I'm having trouble understanding how large numbers of objects are usually stored and balancing differences in efficiency vs the advantage of hiding the "guts" of the data structure behind method calls.
For example, take the hash shown below. Within each $id there is a series of $position hashes, and each $position hash contains additional data structures:
%hash $id $position key1 = (scalar) type_a = { subkey1 => (scalar) subkey2 => (scalar) subkey3 => (scalar) } list_1 = [ ]
Currently, if I need to get some data for a known $id and $position, I can access the data directly:
my $value = $hash{$id}{$position}{type_a}{subkey2};
This is fine, but I would like to make the accessing code more independent of the underlying hash structure so I can change it (the hash structure) as needed. Therefore, I thought about adding some accessor-like subroutines:
my $value = get_typea_sk2( $id, $position ); sub get_typea_sk2 { return $hash{$id}{$position}{type_a}{subkey2}; }
Now if I change the data structure, all I have to do is change the subroutine and the rest of the code still works. Of course, I immediately started thinking "objects". I could make each $id it's own object and store all of the $id objects in an array instead of a hash, but then I'd have to search through the array for the proper object each time I wanted to get data for a specific $id. This seemed like an incredible waste of time, so I thought about storing the objects in a hash, keyed by $id:
%hash $id => $objref
This would allow me to immediately find the object for a given $id. Since I'd still have to find the proper $position hash within the $id object before returning the data, however, I could take this one step further and use "position" objects instead:
%hash $id $position => $objref $position => $objref
This would allow me to do things like:
my $obj = get_object( $id, $position ); # use methods on $obj to get data sub get_object { return $hash{ $_[0] }{ $_[1] }; }
This approach would give me the ability to access objects quickly (without searching an array), and it still provides a degree of abstraction through method calls. For some reason I feel like this isn't quite acceptable OOP, though, and somehow I'm short-circuiting something (encapsulation?) that will come back to bite me later. For example, by storing the $id and/or $position outside of the object, I lose the ability to change those values via the object methods (not that I need to, but it's an argument against this approach). If I try to retain that ability by including them in the object as well as in the hash, then I would have to update the hash keys whenever the $id or $position data in the object changed.
So my question is this: how do you store large sets of objects and access them efficiently? Is it OK to combine direct-access with objects, as in the hash of objects above, or is that idea just pseudo-OOP (pOOP)?
Many thanks!
bobf
I apologize for the length of this post - I thought it would convey my reasoning and clarify my questions better than a shorter version would.
In reply to Storing and organizing objects by bobf
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |