You raise a good discussion point. However, I agree with the other commenters. Bob Martin, in his Dependency Inversion Principle, says:

A. High level modules should not depend upon low level modules. Both should depend upon abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.

The scenario described by Shoes is a violation of B. (Much discussion of the OCP deals specifically with abstract interfaces and implementations, but I think it is appropriate to whole systems as well). It is desirable to write your business logic with as little knowledge of the underlying details as possible. I’m not saying that anybody can perfectly do this, only that it is the aim we should all have.

Often, the constraints of a system are clearly expressed. For example, you know that a hash map has unique keys, because the documentation says so. But often, the unknowns are not expressed. When you insert a new item, will hashCode be called on all existing keys? Will it be called on only some keys? How may times will it be called per key? Do you care? These details are unspecified.

Certainly, we depend on the fact that HashMap uses unique keys. We probably wanted that behavior. We depend on the fact that Hibernate performs database access on our behalf. Again, we probably wanted that behavior. Should we depend on the fact that Hibernate’s concept of identity depends on the current Hibernate Session? This is not behavior that I asked for, so it’s better to pretend that was not guaranteed. If we assume nothing about the returned identity, then our code will be better able to adapt to future change (which is Shoes’ point).

I’m not trying to pick on you. Again, I think you raise a good point. It is a trap to over analyze and perfect the abstract architecture of a system. But the opposite, to put off as much architecture as we possibly can, just makes tomorrow’s work more difficult.

Shoes,
great article. I like to read your posts ’cause you supply a lot of references to my own learning and thinking.

Best regards,

The less facts we hold as axiomatic, the better we are on anticipating
changes, and building useful models.

I don’t think the analogy you’ve made is really relevant to this point. After all a Hash Map is a well defined entity. Not allowing duplicate keys is an essential, defining property of this object, as elemental as knowing that there’s no such a thing as the smallest real number > 0.

In other side, Shoes was refering to a behaviour that could be hardly defined as essential, it’s an implementation defined behaviour. Having a dependency on this fact is going to make your code fragile as the author has clearly pointed out.

Is this really an issue?

People rely on the guarantees made by underlying infrastructure all the time. A hash map guarantees the objects with different codes will not collide and overwrite. We use that, we’re happy, we move on.

At some point you need to be pragmatic about which assumptions you accept and which you account for. If you start accounting for everything, you end up in a world of pain and complexity that’s worse than if you just lived with the assumption…

I appreciate the point you’re trying to make, but don’t necessarily accept the scenario you’re using to make it… if that makes sense?