Design principles are the guidelines for better software development. In this post I'm going to write about 4 fundamental design principles which I thought are very essential.
FAIL FAST PRINCIPLE
Fail fast is very effective principle that every software systems must adopt. This principle says that do not ever hide the error; report as soon as it occurs and corrective action(s). This is very essential because the error is constrained. Let’s take an example of a web page of a web application where user needs to key in the lots of data. The page has got many text fields and user starts filling the fields and at the last text box the user enters an invalid data and there is message thrown by the web application saying “Error Occurred, please start over” then the user is forced enter again all the fields from the beginning. This is the real pain for the user. Does anyone use this website? Of course the answer is NO. This web application is said not to follow the Fail – Fast Principle. We need to remember "
Success is 99% failure" and Fail Fast is all about this.
Let’s look at different types of errors/failures in software and how can we apply Fail – Fast for each of them.
What are the types of failures?
1.
User Input Error: Tell the user about the error right away! Do not give user errors at step10 and ask him/her to start all over again. Ask the users to correct them immediately. One way to solve this type of error is not allowing user to navigate to the next field until the correct data is entered in the previous field. As a best practice, user input errors can be reduced. Can we see how Google Search does a spell check when user starts typing the search keywords? Google autocorrects the words types if spell mistake is obvious. Drop downs can be supplied if we know what the values that a text field can have are. Provide calendar widget than having users type in the date etc
2.
Programming Error: These are all coding errors. These can be avoided by following certain best coding practices. The key to avoid programming errors are to use asserts. An assert is the tiny piece of code that checks a condition and throws error if the condition is not met. Whenever writing a comment, better write the assert. For example: //Variable “a” should not be negative -> assert (a > 0) etc. Typical places to use assert are at the beginning of a function, at the end of complicated procedure to check that the result is plausible, to check the post conditions etc. Note that the too many asserts can lead to fragile software which seems to fail now and then and hence need to be used carefully.
3.
Error Conditions: A condition in the software that can happen. It is not an illegal condition.
4.
Violation of Assumptions: violation of assumption is the condition in software which should never arise. A typical example for violation of assumption is that assuming that the program will always run on Windows platform. Remember that the software requirements change over the time and your program can be asked to run on Linux or MacOS.
5.
Compilation Errors: IDE’s (Integrated Development Environments) help to fail fast the compilation errors. Compilation errors can be reduced by having less or no dependencies, increasing the IDE’s error levels etc.
Advantages of Fail Fast Principle
1. Easy debugging because if an error is reported late, it is too difficult to figure out the root cause of the issue. You all know debugging is unpredictable.
2. Fail Fast ensures that the distance between point of failure and point of reporting the failure is low
3/ Fail Fast is the key to the robust software since it reduces the debugging cost, pain and the schedule risk.
TELL, DON’T ASK PRINCIPLE
The principle says that use TELL interface. This means that just tell the interface what you want and let the interface do the rest. In a typical ASK interface, we query lot of data before getting our job done. Better example is that if you want to go from one floor to another using elevator, you just press the up or down key of the elevator irrespective of which floor the elevator is in. This is good TELL interface. If the elevator is implementing ASK principle and let us you want to move from 2nd floor to the ground floor. You need to know first where the elevator is and if it is in the ground floor you need to press up button and if the elevator happens to be in the 5th floor you need to press down button.
“
Interfaces based on TELL are better than the interfaces based on ASK”
To put it in object oriented paradigm, tell what objects need to do and don’t ask questions about the object state to make a decision and then tell them to do what you want.
The logic you are implementing is probably the object’s responsibility and not yours. For you to make decisions outside the object violates the encapsulation.
Asking the objects for their values is a bad idea instead just tell the objects what you want from them.
Let’s take a java code example.
-----------------------------------------------------------------
| public String findGrade(int testScore){
| TestGrade grade = new TestGrade();
| String strScore;
| if(testscore >= 90) {
| strScore = grade.getAGrade();
| } else if (testscore >= 80) {
| strScore = grade.getBGrade();
| } else if (testscore >= 70) {
| strScore = grade.getCGrade();
| } else if (testscore >= 60) {
| strScore = grade.getDGrade();
| } else {
| strScore = grade.getFGrade();
| }
| return strScore;
| }
---------------------------------------------------------------------------------
The above code asks the object for grade. This is following ASK principle. Above code can be re-factored to follow TELL
--------------------------------------------------
| public String findGrade(int testScore){
| TestGrade grade = new TestGrade();
| return grade.findAndGetGrade(testScore);
| }
----------------------------------------------------------------------------------
Well, the difference between above two code snippet is obvious. The code written based on TELL is easy to read and robust.TELL principle says that you need to minimize having getters and setters.
Advantages of TELL, DON'T ASK Principle
1. Enables programmers to think decleratively and not procedurally
2. We give commands than queries and code is more readable
3. Freezing responsibility of a class will ease in modularity, abstraction and encapsulation
4. Minimizes the use of getter and setter methods.
