'the data' is a vague concept. Usually, a hash map doesn't expose, for example, the bu met array, or the length of the bucket array. Sure, you can ask the hash map to give you the contents associated with a hash key, but you can't access the entire data structure that the hash map represents.

By contrast, in an 'extreme procedural' style, you would have a struct that is an array of buckets and an integer, and functions that can take such a struct and return information from some particular place inside it. In normal use you would just use the function, but if you're passing your hash map to someone else, there is no longer a guarantee that the length field still matches the actual buckets, or that objects are still arranged into buckets based on their hashes.

A hashmap wouldn't hide the data. But say, a Customer object might. A purist OO might insist that you shouldn't have a GetName() method because any code which needs the Customer's name should be method on Customer.

This particular example is probably a bad illustration, with all the recent rage about PII and privacy. In some cases (such as this) you want to make sure data doesn't leak all over the place and anything accessing it follows a strict path.

Anybody modifying Customer object would hopefully be in the right mindset regarding personal information, but once it gets out as a string from GetName or GetEmail, all bets are off, it gets into all kind of logs.

Anything security related is the same.

I'm having a hard time seeing how OOP style data hiding could be effective at controlling PII. Is this a method you've put into practice?

The data is accessed through an interface, a set of functions associated with the data structure. You don't dig through internal memory structures to get the data - you call these functions. That is what "hidden" means in this context.

A better example might be a linked list. With information hiding, you manipulate the list through functions like push and pop. Without information hiding, you manipulate the pointers directly. For instance, I've worked on C codebases where linked list manipulation isn't even hidden behind macros.

Almost all hashmaps hide the internal references/pointers to the backing arrays. That's implementation state just like any other internal data. It's just so mundane, well executed and common that you forget it exists.