3 ms·

I appreciate what you're saying, and I agree that it's a valid approach, but I would be more interested in making any of the methods which are interested in the

I appreciate what you're saying, and I agree that it's a valid approach, but I would be more interested in making any of the methods which are interested in the object, capable of handling any of the values expressible by the object's type. That is, you need useful zero values (which means no null pointers), and any method that takes the object should be able to do sensible (if not useful) things even if things are their zero-values. As for validation, you don't always know what different consumers of your type consider to be valid or not. For a rectangle any non-negative size should be valid, for instance, but when you try to pass a zero-sized x side to a class that (for some reason) needs non-zero x length, that class should be doing the validation, not the Rectangle class itself. I think I'm coming at this after doing nothing but golang for a few years, and then having to switch to Java recently, and I really hate the language so far, mostly because of the style of programming it encourages.

spdionis 9y ago
I mostly agree with you except: > that class should be doing the validation, not the Rectangle class itself. I partially disagree. You should have a layer after which all (request) parameters are surely and clearly validated. This avoids repeated validations. This layer should be separated from any logic layer. Additionally a class like Rectangle should have a sanity check in the constructor, and throw a fatal exception if the passed in values are invalid. > you don't always know what different consumers of your type consider to be valid or not I try to make things in such a way that an object of a type is either valid or not. If two consumer have different notions of validity about the ~~same~~ similar (!) type of data, I'd rather create a new type. EDIT: For the exact reason that this allows to use static analysis and avoid silly checks for 0-sized x sides. What does a 0-sized side mean? This type of data can only come from bad user-input, and it should stop at the first line of the controller, and not a step further.

spdionis 9y ago

I mostly agree with you except: > that class should be doing the validation, not the Rectangle class itself. I partially disagree. You should have a layer after which all (request) parameters are surely and clearly validated. This avoids repeated validations. This layer should be separated from any logic layer. Additionally a class like Rectangle should have a sanity check in the constructor, and throw a fatal exception if the passed in values are invalid. > you don't always know what different consumers of your type consider to be valid or not I try to make things in such a way that an object of a type is either valid or not. If two consumer have different notions of validity about the ~~same~~ similar (!) type of data, I'd rather create a new type. EDIT: For the exact reason that this allows to use static analysis and avoid silly checks for 0-sized x sides. What does a 0-sized side mean? This type of data can only come from bad user-input, and it should stop at the first line of the controller, and not a step further.