Java Programming Tips

Most of you heard the word 'Encapsulation' while dealing with Java OOPs concepts. What it stands for? We will start with an example. Imagine you have made your class with public instance variables as shown below. public class Sample{ public int height; public int weight; } public class MainClass{ public static void main(String args[]){ Sample sample = new Sample(); sample.height = 170; } You have created this class and think that many of others used this class for setting height and weight variables directly. Now you are really in trouble. Just think a situation that you want to do something when someone set height variable?. Can you do that without breaking everyone's code? Here comes encapsulation. It helps to change your implemented code without breaking the code of others who use your code. You must follow encapsulation if you want maintainability , flex...

Most contend that it's usually a very bad idea to have an empty catch block. When the exception occurs, nothing happens, and the program fails for unknown reasons. Example import java.io.*; import java.util.*; /** How NOT to implement a catch. */ public final class BadCatch { public static void main( String... arguments ) { List quarks = Arrays.asList( "up" , "down" , "charm" , "strange" , "top" , "bottom" ); //serialize the List try { ObjectOutputStream output = new ObjectOutputStream( new FileOutputStream( "quarks.ser" ) ); try { output.writeObject(quarks); } finally { //flush and close all streams output.close(); } } catch (IOException exception){ } } } In general, when a exception occurs, it can be thrown up to the caller, or it can be caught in a catch block. When catching an exception, some ...

Raw types refer to using a generic type without specifying a type parameter. For example, List is a raw type , while List is a parameterized type . When generics were introduced in JDK 1.5, raw types were retained only to maintain backwards compatibility with older versions of Java. Although using raw types is still possible, they should be avoided : they usually require casts they aren't type safe, and some important kinds of errors will only appear at runtime they ar e less expressive, and don't self-document in the same way as parameterized types Example import java.util.*; public final class AvoidRawTypes { void withRawType(){ //Raw List doesn't self-document, //doesn't state explicitly what it can contain List stars = Arrays.asList( "Arcturus" , "Vega" , "Altair" ) ; Iterator iter = stars.iterator(); while (iter.hasNext()) { String star = (String) iter.next(); //cast needed log(star); } ...

Some argue that allowing null into the API of a class, in the form of possibly- null parameters or return values, should be avoided if possible : null references can only be used in a boolean test - any other use will throw a NullPointerException null references always represent special cases, and if these special cases can be removed, the code will be easier to understand null return values are error prone, since there is no way to ensure that the caller always does a check-for- null . methods which accept an explicit null reference as a valid argument are less intelligible at the point of call. The reader will usually need to consult documentation to determine what exactly the null argument means. If null is allowed for a method, then this should be clearly stated in its javadoc. Some follow the convention that all items are assumed to be non- null unless otherwise specified. Such a convention could be explicitly stated once in the javadoc overview.html . There is a v...

One of the most fundamental aspects of a programming language is how it initializes data. For Java, this is defined explicitly in the language . For fields and array components , when items are created, they are automatically set to the following default values by the system: numbers: 0 or 0.0 booleans: false object references: null This means that explicitly setting fields to 0, false, or null (as the case may be) is unnecessary and redundant. Since this language feature was included in order to, in part, reduce repetitive coding, it's a good idea to take full advantage of it. Insisting that fields should be explicitly initialized to 0, false, or null is an idiom which is likely inappropriate to the Java programming language. _______________________________________________