Tag Info

New answers tagged

0

Smart data structures and dumb code works a lot better than the other way around. -- Eric S. Raymond, The Cathedral and the Bazaar You can use XML or JSON with schemas. Validation rules should be machine-readable first, and human-readable if possible. Consider not inventing your own format and using XML Schema or JSON Schema instead. Switching to ...


1

I've been developing extensible software for a long time now. I've also been on the other side. One thing I've learned is that you want libraries you use to "Fail fast". What that means is, it should break my software as soon as possible if something is wrong. If you can (which in this case I presume you can't) break at compile time. If not, throw an ...


2

Validation of input parameters/data should be performed whenever the data can come from an untrusted source. To be on the safe side, if anyone outside the development team can supply data to an interface, then that interface should validate its inputs. The more interesting part of the question is what to do when the validation finds a problem. First of ...


1

I think interfaces in the form of the wrapper pattern are the way to go. If you have an IPlatform interface and IAndroid, IOS (pun intended), etc. that extend it, you can write operations as wrapper objects following the wrapepr pattern. Disclaimer: this is pseudo code, it's been too long since I did C#, you get the idea Here's an operation that ...


2

If you worry about ORM persistence, then here's a possible solution: Each operation declares its supported platform, similar to interface approach but use flags property instead (please note I change your enum to flags and add an option for unknown type) [Flags] public enum PlatformType : short { Unknown = 0, /// <summary> /// Device is ...


1

How about adding interfaces for platform specific Operations? ie. public interface IAndroidOperation : IOperation {} public interface IIoSOperation : IOperation {} Then have the operations implement the interfaces they are good for public class LockOperation : IAndroidOperation, IIoSOperation {} Then have the device only allow adding of the correct ...


0

You definitely don't have to. For instance, if you already know that a return can never be null - Why would you want to add a null check? Adding a null check is not going to break anything but it's just redundant. And better not code redundant logic as long as you can avoid it.


7

A definite no. A caller should not ever check if the function it is calling respects its contract. The reason is simple: there are potentially very many callers and it is impractical and arguably even wrong from a conceptual point of view for each and every single caller to duplicate the logic for checking the results of other functions. If any checks are ...


5

If null is a valid return value of the getUser method, then your code should handle that with an If, not an Exception - it is not an exceptional case. If null is not a valid return value of the getUser method, then there is a bug in getUser - the getUser method should throw an exception or otherwise be fixed. If the getUser method is part of an external ...


4

I would argue that the premise of your question is off: why use a null reference to begin with? The null object pattern is a way to return objects that essentially do nothing: rather than return null for your user, return an object that represents "no user." This user would be inactive, have a blank name, and other non-null values indicating "nothing ...


22

Ixrec's answer is good, but I will take a different approach because I believe that it is worth considering. For the purpose of this discussion I will be talking about assertions, since that's the name by which your Preconditions.checkNotNull() has traditionally been known. What I would like to suggest is that programmers often overestimate the degree by ...


1

Generally, I'd say that depends mainly on the following three aspects: robustness: can the calling method cope with the null value? If a null value might result in a RuntimeException I'd recommend a check - unless complexity is low and called/calling methods are created by the same author, and null is not expected (e.g. both private in the same package). ...


40

That depends on how likely getUser and myMethod are to change, and more importantly, how likely they are to change independently of each other. If you somehow know for certain that getUser will never, ever, ever change in the future, then yes it's a waste of time validating it, as much as it is to waste time validating that i has a value of 3 immediately ...



Top 50 recent answers are included