This is in continuation to the existing post, in my previous post I pointed out five very basic points that we should keep in mind as a java developer. Here are next few points as I promised.
Proper usage of static: in most of the server side applications we just follow procedural programming and we don't share any field between requests and even we many times pass all the required objects as the parameter to the next method call, many times we can simply define methods as static methods where we don't need any field dependency. for eg: in case of validations, converters, or to simply work some operation on any object. It is very good practice to define static and final methods wherever possible and required.
Though you will not be able to use polymorphism in this case because static methods can't be overridden but then first question in your mind must come is why do you need a static method or why you are not using any of the instance variable.
And keep in mind when you define any method static that simply means its going to be final so just say it as final in its definition.
Avoid setters in interfaces: almost all the times we do design by interfaces, which is the best design approach and I will talk about that in next points, but for now I will simply say that do not declare any setter method in any interface that you design. Reason is back into the principle of interface base designed, simply think for a moment what is the basic reason of design by interfaces. It simply says that design by interface so that we can change implementation detail any time, and if we define any setter in interface that means we know implementation dependency while writing the interface, which simply is opposite the principle. Go study some factory pattern and you will find the correct way of doing this.
Avoid parameters in getter: now tell me what is the meaning of getObject method name in any class or interface, its very simple, give me some object. If we pass any parameter generally that means we are expecting any operation to happen in getter which simply violates the whole meaning of its being a getter. Generally getter methods are to get something that this class has being a DTO or VO or a Bean (in POJO style, which actually it is, others are just fancy names) or something that it has prepared in some previous method call. So let it be that simple.
Do not wrap standard api: THIS IS LIKE COMMITTING A SIN, yes I have seen code where developer creates classes like MyArrayList, MyHashSet or MyHashMap. Don't know why they think that collection or any standard api will change and they will have to implement their own. I mean if these things ever change, we all anyway will have to just change everything. But simply saying that is not going to happen. This will only make you have more number of classes and more places of possible errors. Also writing such class will only increase your class count and confusion.
Use of Collections.EMPTY: I remember code where I used these empty constants and it was very clean code. At many places we simply do like below
now why we did if(c!=null) simply so that if c is null, it should not throw null pointer exception. Well simply if in catch block we assign c =Collections.EMPTY_LIST you need not to check this nullability. It makes code more readable and good looking.
Also I would say returning a null value from any method does not make sense specially when we expect a collection or map. In that case it should simply mean that there is something wrong and it must throw an exception to report that. while pointing out this point I remember my discussion with my friends regarding new foreach statement, we were debating over, if foreach should take care of nullability or not. I was on the side that it must not and it is doing correct simply because a collection being null means that collection (or bag) is not created, why, why there can't be an empty collection, and who can stop its existence.
Proper usage of static: in most of the server side applications we just follow procedural programming and we don't share any field between requests and even we many times pass all the required objects as the parameter to the next method call, many times we can simply define methods as static methods where we don't need any field dependency. for eg: in case of validations, converters, or to simply work some operation on any object. It is very good practice to define static and final methods wherever possible and required.
Though you will not be able to use polymorphism in this case because static methods can't be overridden but then first question in your mind must come is why do you need a static method or why you are not using any of the instance variable.
And keep in mind when you define any method static that simply means its going to be final so just say it as final in its definition.
Avoid setters in interfaces: almost all the times we do design by interfaces, which is the best design approach and I will talk about that in next points, but for now I will simply say that do not declare any setter method in any interface that you design. Reason is back into the principle of interface base designed, simply think for a moment what is the basic reason of design by interfaces. It simply says that design by interface so that we can change implementation detail any time, and if we define any setter in interface that means we know implementation dependency while writing the interface, which simply is opposite the principle. Go study some factory pattern and you will find the correct way of doing this.
Avoid parameters in getter: now tell me what is the meaning of getObject method name in any class or interface, its very simple, give me some object. If we pass any parameter generally that means we are expecting any operation to happen in getter which simply violates the whole meaning of its being a getter. Generally getter methods are to get something that this class has being a DTO or VO or a Bean (in POJO style, which actually it is, others are just fancy names) or something that it has prepared in some previous method call. So let it be that simple.
Do not wrap standard api: THIS IS LIKE COMMITTING A SIN, yes I have seen code where developer creates classes like MyArrayList, MyHashSet or MyHashMap. Don't know why they think that collection or any standard api will change and they will have to implement their own. I mean if these things ever change, we all anyway will have to just change everything. But simply saying that is not going to happen. This will only make you have more number of classes and more places of possible errors. Also writing such class will only increase your class count and confusion.
Use of Collections.EMPTY: I remember code where I used these empty constants and it was very clean code. At many places we simply do like below
Collection c=null;
try{
c=getCollection();
}catch(AnyException e){
}
if(c!=null){
Iterator i=c.iterator();
while(i.hasNext()){
.
.
.
}
}now why we did if(c!=null) simply so that if c is null, it should not throw null pointer exception. Well simply if in catch block we assign c =Collections.EMPTY_LIST you need not to check this nullability. It makes code more readable and good looking.
Also I would say returning a null value from any method does not make sense specially when we expect a collection or map. In that case it should simply mean that there is something wrong and it must throw an exception to report that. while pointing out this point I remember my discussion with my friends regarding new foreach statement, we were debating over, if foreach should take care of nullability or not. I was on the side that it must not and it is doing correct simply because a collection being null means that collection (or bag) is not created, why, why there can't be an empty collection, and who can stop its existence.
Comments
Post a Comment