Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
2  
Always choose the one that will cause you least amount of effort and grief in future. Its really hard to tell which one because we don't know what your code does. Can you elaborate on the use case of the context and the errors? –  Tjaart Oct 25 '12 at 7:23
    
@Tjaart The context is created when user entered values and pushed them into an application. I'm setting values user entered to those objects inside the context and If I see a wrong value, I add an error to the context, so when context will try to persist objects, he will instead notify user that bad value is entered. –  dhblah Oct 25 '12 at 7:27
1  
So you are storing a collection of validation errors, matched with which object failed to validate, in the context? –  Tjaart Oct 25 '12 at 7:41
    
Yes that's right. –  dhblah Oct 25 '12 at 7:51

3 Answers 3

up vote 1 down vote accepted

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.

share|improve this answer
    
Maybe I didn't understood you correctly, but I don't want to add errors to objects itself. Objects only contains some business - date, not their validation data. That's why I'm keeping all validation data inside the context. –  dhblah Oct 25 '12 at 9:07
    
@johnsmithoptional then you can go with the second method that you mentioned as I said. Why don't you want to keep the error data in a base class of the data objects though? –  Tjaart Oct 25 '12 at 9:09
1  
because it doesn't belong there. The validation info is a technical information and objects themselves contain only business-specific data. –  dhblah Oct 25 '12 at 9:55

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 ?

share|improve this answer
    
note: context.addError should have error as a parameter. ErrorHandler can be used by clients. –  dhblah Oct 25 '12 at 9:04
    
@johnsmithoptional corrected, thanks ! –  phtrivier Oct 26 '12 at 11:55

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.

share|improve this answer
    
there is a couple of objects in the context, so I should specify for which object to add an error. –  dhblah Oct 25 '12 at 7:21
    
Excuse me, I mixed things up a little bit. I'll correct it in my answer. The principle stays the same: focus on readability, expressiveness and usability of the API. –  Regular John Oct 25 '12 at 8:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.