Earlier quoted context omitted.
If the code snippet returns a local ID object, then calling a method on the ID object doesn't violate the law of Demeter. It can be, in fact, the preferred method in the case that you don't have control over the db object. If your snippet doesn't return a local id object, then the violating portion should be idstring = db.findUserBySsNumber(ssNumber).toString(); println("id=" + idstring) A (perhaps) more clear illust…
I'm sorry for not being more clear. `db` is a service and the code snippet is client code. I'm not sure what you mean by a "local object" (unless you are referring to C++'s stack-allocated objects). `Id` is a class defined by the service. The service doesn't know anything about the client code.
But anyway, the guideline takeaway is: work locally. This isn't so important perhaps in the stuff we showed here, but if you had many operations on it, then you risk being fragile to changes in db's api. That's what you are trying to avoid (because they do change, and in ways that can break things).
It's probably so obvious now that you're scratching your head trying to figure out what the hell I'm talking about he couldn't be saying something _that_ stupid!. But back when OO was just going mainstream I would imagine that guidelines like these were useful as all the new programmers likely had the same questions and the guidelines answered them.