Providing discrete return and parameter values
When I develop software, I enjoy writing methods that perform a very specific, very small task, then use those methods to make bigger, more complex actions. Small methods are good methods, and the larger they get, the more chance that a design problem is present. These are personal philosophies that, thankfully, seem to be echoed in the larger community of developers.
Here's something though. One of the tenets of good method design is defining a contract for your method. That is, defining that, in all cases, your method should return something specific given certain input. Now, naturally, the shorter the method, the simpler the contract. The simpler the contract, the better the code will work. Also, a simple method that isn't overreaching has a better chance of being reused.
Now, in the spirit of short but descriptive methods, I have in mind a language mechanism that constrains the input and return values of a method. I'm not sure if this concept exists in languages other than the ones I know, and I wouldn't be surprised if it did. The idea would be that your method is defined in such a way that it can only take a certain range or set of values as input per parameter, and only return a certain range or set of values.
Why would this be useful? Several reasons. The methods themselves could be checked at run time and compile time for violations of the constraints, allowing for faster development and speedier debugging. If the cause of the error is that one of your inputs or outputs is out of a logical range, then it would help to know the cause of the error rather than the effect. Another reason would be self documentation. The code would be more descriptive than before since it would now declare the constraints on the data input and output with actual language, not comments. One of the most appealing features of this is the integration with testing frameworks. If you know the range of all legal inputs, then you can easily test border conditions because you've declared exactly what those borders are. Another fine advantage would be the sudden absence of error-checking code in your methods, since the constraints are enforced by the language.
Now, I would argue that there are some mechanisms already in place to constrain input and output in methods. Particularly, in a strongly typed, object oriented language, you can already classify data for this purpose. For instance, in Java, you could have a bean that represents the input for a method, defining all the properties that method needs to access. You could define a similar bean that models the output of a method. In that bean, you could set up exceptions to fire off if certain ranges and values are exceeded or violated. Why would you not want this? It's too constraining on the data model. Writing a bean should be a one time thing for a certain piece of data, and it may be that the process should define the data constraints, not the model of the data. Instead, the proper way to approach it would be to define exceptions for your methods that use specific ranges of values and check those values before your method makes use of them, throwing the appropriate exceptions if necessary.
The other issue at hand is the use of complex data types vs. primitive data types. In my opinion, the time of primitive data types for high-level languages is coming to an end. This isn't to say that they don't have their uses, but the gap covering the distance between their necessity in modern software and the ability of objects to mimic their behavior is closing fast. Java's autoboxing features exemplify this sort of behavior. However, the point is that primitive data types are usually not nullable values, whereas complex data types are. The behavior associated with null values as return data from methods is often loosely defined. In my opinion, the return of a null value is usually the result of something unexpected, and should trigger a descriptive exception. However, I also believe that they have their uses, and should be used if necessary. I believe that it should be possible to declare that the return of a method is not null, and likewise allow the input to be checked automatically. Again, this is done to make the declaration more descriptive and, by extension, more functional and reusable.
Any thoughts are appreciated.
Here's something though. One of the tenets of good method design is defining a contract for your method. That is, defining that, in all cases, your method should return something specific given certain input. Now, naturally, the shorter the method, the simpler the contract. The simpler the contract, the better the code will work. Also, a simple method that isn't overreaching has a better chance of being reused.
Now, in the spirit of short but descriptive methods, I have in mind a language mechanism that constrains the input and return values of a method. I'm not sure if this concept exists in languages other than the ones I know, and I wouldn't be surprised if it did. The idea would be that your method is defined in such a way that it can only take a certain range or set of values as input per parameter, and only return a certain range or set of values.
Why would this be useful? Several reasons. The methods themselves could be checked at run time and compile time for violations of the constraints, allowing for faster development and speedier debugging. If the cause of the error is that one of your inputs or outputs is out of a logical range, then it would help to know the cause of the error rather than the effect. Another reason would be self documentation. The code would be more descriptive than before since it would now declare the constraints on the data input and output with actual language, not comments. One of the most appealing features of this is the integration with testing frameworks. If you know the range of all legal inputs, then you can easily test border conditions because you've declared exactly what those borders are. Another fine advantage would be the sudden absence of error-checking code in your methods, since the constraints are enforced by the language.
Now, I would argue that there are some mechanisms already in place to constrain input and output in methods. Particularly, in a strongly typed, object oriented language, you can already classify data for this purpose. For instance, in Java, you could have a bean that represents the input for a method, defining all the properties that method needs to access. You could define a similar bean that models the output of a method. In that bean, you could set up exceptions to fire off if certain ranges and values are exceeded or violated. Why would you not want this? It's too constraining on the data model. Writing a bean should be a one time thing for a certain piece of data, and it may be that the process should define the data constraints, not the model of the data. Instead, the proper way to approach it would be to define exceptions for your methods that use specific ranges of values and check those values before your method makes use of them, throwing the appropriate exceptions if necessary.
The other issue at hand is the use of complex data types vs. primitive data types. In my opinion, the time of primitive data types for high-level languages is coming to an end. This isn't to say that they don't have their uses, but the gap covering the distance between their necessity in modern software and the ability of objects to mimic their behavior is closing fast. Java's autoboxing features exemplify this sort of behavior. However, the point is that primitive data types are usually not nullable values, whereas complex data types are. The behavior associated with null values as return data from methods is often loosely defined. In my opinion, the return of a null value is usually the result of something unexpected, and should trigger a descriptive exception. However, I also believe that they have their uses, and should be used if necessary. I believe that it should be possible to declare that the return of a method is not null, and likewise allow the input to be checked automatically. Again, this is done to make the declaration more descriptive and, by extension, more functional and reusable.
Any thoughts are appreciated.
