encapsulation and accessing large maps?

Suppose that I have an object that has a very large map. Consider now, another object that wishes to iterate through every item in the map owned by the first object. Lets name these two objects, ObjMap and ObjNoMap. It is tempting to write a ObjMap::getMap function that returns a pointer to the internal map object. However, this breaks encapsulation. Another option is to return the whole map by value, but then there is a very large hit in efficiency. Still another option would be to return a const_iterator. Consider this last option. If I return a const_iterator to the map from ObjMap am I still breaking encapsulation? On the one hand ObjNoMap will gain read access to an internal member of ObjMap, but at least ObjNoMap cannot mutate the internal member of ObjMap. Is there a viable solution that will allow me to keep with the object oriented methodology of encapsulation without taking a majore hit in efficiency?

Thank you for your time.

dustfinger.

If only a number of private classes wish to access the map, you could implement them as friends of the map. But if you want to provide access (that is, only access) to the map to the public, I think a const_iterator is the way to go.

Note that encapsulation isn't about locking up everything in a neutronium-alloy-whatsit safe and making sure no one gets into it. It's about allowing folks to get only what they need from an object, and nothing else.

I think returning the iterator is perfectly acceptable. You could typedef it to a different name (or maybe just ObjMap::iterator) so that if you ever do need to change the implementation of ObjMap to not use the same kind of map, you can just change the typedef. As long as the new implementation can provide something with the same interface as the original map const_iterator, the calling code in ObjNoMap will not need to be updated.

One problem with returning a const_iterator is that I will not know when I am at the end of the map. I could write a function that takes a reference to a const_iterator, which will be set to the end of the map, and returns a const_iterator, which will be set to the start of the map.

Code:

---

ObjMap::const_iterator endItr;
ObjMap::const_iterator itr = getMap(endItr);

---

However, what if I want to iterate through the map more than once for some reason. Then I could do something like.

Code:

---

ObjMap::const_iterator startItr;
ObjMap::const_iterator endItr;
ObjMap::const_iterator itr;
getMap(startItr, endItr);
for(itr=startItr; itr!=endItr; ++itr)... you get the point

---

But that seems messy. Is there a cleaner way to deal with this problem. I feel compelled to only want to return a const_iterator, but then I want to be able to iterate to the very end of the map, and so I need to know when I am at the end.

dustfinger.

> One problem with returning a const_iterator is that I will not know when I am at the end of the map.

Not sure if I follow you on this one...

objMap.end() will let you know if you have hit the end of the map.

Oops. I did not mean to write getMap is a member of ObjMap. This is what I really meant:

The code in question is being called from ObjNoMap. I want read only access to a very large map that ObjMap contains. So I write:

Code:

---

AMap::const_iterator ObjMap::getMap();

---

and call getMap from ObjNoMap. The problem is that I recieve a const_iterator to the begining of the map, but do not know where the end is. So there are two solutions that I can think of. Return a const pointer to the map itself, or have getMap take two reference parameters of type AMap::const_iterator and set them appropriately. What is the best solution here?

Note: the code in my previous post should have looked more like:

Code:

---

AMap::const_iterator startItr;
AMap::const_iterator endItr;
AMap::const_iterator itr;
getMap(startItr, endItr);
for(itr=startItr; itr!=endItr; ++itr)... you get the point

---

dustfinger.

>What is the best solution here?
Why not just add begin and end member functions to AMap? It sounds like you're writing a wrapper container with a map as the internal container, so there shouldn't be any problem with matching a subset of the map interface.

Why not indeed. I cannot believe that I never thought of that. I will sheepishly go back to what I had been doing before I interupted this forum. Augh!!!!

dustfinger.