I have some context
then I can do:
with context.getError(Object): ErrorHolder
holder.addError(error)
OR
context.setError(Object, error)
setError will probably have this implementation:
context.getError(Object).addError(error)
what approach should I choose and why?
4
I would definitely go with the second method. Why?
Well it seems to be the simplest answer. In the first instance it will require two calls everytime you need to add or get an error from your context.
There is another alternative, provided that you are providing your Object classes and they are not generated by some 3rd party lib.
You can add an ErrorCollection property to the base class of your data objects that keeps errors. That way when your object moves around the errors are linked with it.
That way you will have
object.addError()
object.getError(index)
This is cleaner because you are not maintaining objects and a relation of objects to their errors.
3
Isn’t this a case where you would be ‘violating’ the Law of Demeter ?
The second one, provided you use a name like context.addError(object, error) if you can actually have several errors on an object, hides ErrorHandler to the clients of context. Is ErrorHandler an implementation detail, or could clients of ‘context’ use it too ?
1
I’m a fan of keeping things simple. This enhances readability and the usability of an API. I don’t think there’s a definitive answer, But I would go for the second approach, although I would call the method context.addError(object, error), for this implies, that their could be more than one error, which is the case, when I look at your possible implementation.
The getError(object)-approach lacks good naming too, I think. If you choose the first approach consider naming the Method getErrorHolder(object).getError().
EDIT: If I still get you wrong, that’s a sign for ambigious naming. Use add for adding to a Collection and set for single instances.
2