Victor Bazarov wrote:
Tom wrote:
The scenario is this
The original values to the map are created in the initial function of
the application. Further processing in various functions throughout
the application need to use the data in the map and sometimes actually
change the data held in the map.
Rather than have to extract the original objects in the map and
replace them when they are modified, it would be nice to simply
retrieve a modifiable version of the objects that reflect the changes
in the original without the need to have to delete the original and
add the new version or even replace the original with the newer
version.
Or, perhaps you should give the object that owns the map to make the
changes necessary... Was it yesterday that I read about Law of Demeter
here? Or was it in a different newsgroup?... I don't remember. Check
it out, though.
<snip>
Although I agree with you that the Law of Demeter is correct, I think
you are missing the point here. LoD does not preclude the use of
databases/repositories or transport mechanisms and/or does not
interpret the database/repository or transport mechanism as the
"friend" or as a stranger.
The class that holds the map in this scenario is simply a container for
application data. The only purpose of it is to transport application
data around the application. Think of it similar to a shopping cart,
though that is not the use here but a good analogy, in that the
container holds various types of application data types in the same way
that a shopping cart can hold different inventory.
In this way it is both a friend and neutral, in that it is presents a
known interface to the application in order for the application to
store data in a retrieve data from using setter/getter methods. Other
than that, the application knows nothing about it.
The data classes contained in the class map are known application data
types which the application manipulates. Given that there is a need to
manipulate the data in various different points in the application and
and unknown quantity of the data, it serves well to store/retrieve
references/pointers to the data classes such that they can be
manipulated without the overhead of copy ctors or assignment operators.
The alternative would be to hold global arrays/maps/vectors/lists of
the data types which is not very nice to deal with.
Simply put I have created a container specific to the needs of my
application and as such it should be compared to using a std::map or
std::vector or any other std::container for that matter. LoD does not
preclude the use of such containers.
Thanks,
Tom.