> I don't really understand why. How would you distinguish between which > (kinds of) core objects and which not? Will you not end up with a > displayString on Object again? > > > You will not know all the 'why's in advance. The concrete answer is in the > next developer's creativity. > > What you can do in advance is to ask 'why not?'
Well, then we can argue why not put 'foo' on Object. I think we should try to get to a good API with concrete meaning. And preferably on Object, there should be as few methods as possible that can be interpreted in as many ways as you want. > And a reason that comes to mind to answer that is: > > because > 1) what are the odds to NOT needing to perceive an object? And how would I perceive a complex object through a string? Would I then display multiple lines with all the data contained in the object? > 2) what's the most obvious way to make objects perceivable one if not > displayed as a string in some kind of > screen/device/hologram/network-proocol/whatever? I think this is the core of the issue. We can't have a single 'displayString' interface that cater for all of these requirements / contexts. That's where the visitor pattern comes in - where the "whatevers" can decide for themselves how best to represent the object depending on the context. This is especially true when the object / object graph becomes more complex. Perhaps I'm misunderstanding the word 'perceive' here, but in my world it can be widely interpreted, depending on the perspective of the viewer. And 'screen/device/hologram/network-protocol/whatevers are all quite different perspectives. This is why I think that displayString is even for my 'DomainObject' above a bit suspect. What if I want to display it differently (in the same application), but in different views?
