Java Basics Revisited..,

• Class: A template that describes state and behavior of a object
  
• Object: new instance of a class.
  
• State: The value assigned to an Objects instance variable
  
• Behavior: methods in a class
  
• Inheritance: allows code defined in one class to be reused in other classes
  
• Interface: 100-percent abstract superclass that defines the methods a subclass must support
  
• Every class should have a focused set of responsibilities.
  
• Identifiers cannot start with a number!; You can't use a Java keyword as an identifier; No limit to number of characters an identifier can contain
  
• Rules:
  
  • Classes: First letter capitalized, Should be a noun (Ex:- Account, Customer )
    
  • Interfaces: First letter capitalized, should be a adjective (Ex: -Runnable Serizlizable)
    
  • Methods
    The first letter should be lowercase, and then normal camelCase rules should be used. In addition, the names should typically be verb-noun pairs (getSize)
    
  • Variables
    Like methods, the camelCase format should be used, starting with a lowercase letter. Sun recommends short, meaningful names, which sounds good to us.
    
  • Constants
    Java constants are created by marking variables static and final. They should be named using uppercase letters with underscore characters as separators
    
  • Listeners: must start with either add/remove. Must end with Listener; Example: addActionListener, removeActionListener
    
  • There can be only one public class per source code file.
    
  • Files with no public classes can have a name that does not match any of the classes in the file
    
• Access Control/Modifiers (Public, Private, Protected, Default) – code in one class can modify/access other class
  
  • Class:
    
    • Has only public and Default. Default means package level, only classes in that package can access it, other packages cant see this class.
      
    • Can use strictfp, abstract and final modifiers for a class. You should make a final class only if you need an absolute guarantee that none of the methods in that class will ever be overridden.
      
  • Interfaces.
    
    • All interface methods are implicitly public and abstract
      
    • All variables defined in an interface must be public, static, and final—only constant, no instance variables
      
    • Interface methods must not be static. (int x=1 is implicitly public static final int x=1)
      
  • Method:
    
    • Has all four access levels.    
      
    • Default- package level access;
      
    • Protected – package + kids (who ever extends; If you try to access it using instance it will fail). The protected method becomes private to the classes in the package that the original class inherited.
      
    • Private: Class level; When a member is declared private, a subclass can't inherit it.
      
  • Variables
    
    • it's nearly always best to keep all variables private or protected.
      
    • Private/Protected/Default Access Control– same as method level.
      
    • Local variables: no access modifier except final.
      
• Non-Access Modifiers
  
  • Final
    
    • Class: prevents the class from being subclassed. This is particularly useful, for example, when creating an immutable class like the String class.
      
    • Method: Prevents a method to be overridden. You might wish to make a method final if it has an implementation that should not be changed and it is critical to the consistent state of the object. Methods called from constructors should generally be declared final. If a constructor calls a non-final method, a subclass may redefine that method with surprising or undesirable results.
      
    • Method arguments: Variables passed to a method can have final modifier. which means it can't be modified within the method. In this case, "modified" means reassigning a new value to the variable. In other words, a final argument must keep the same value that the parameter had when it was passed into the method.
      
  • Abstract
    
    • Class: Classes which inherit a abstract class should implement the abstract methods
      
    • Methods: One method declared in a class as abstract makes the whole class abstract.
      
    • Variables: Abstract CANNOT be applied to variables.
      
  • Synchronized
    
    • Class: Not applicable
      
    • Method: Applicable and indicates that a method can be accessed by only one thread at a time.
      
    • Variables: Not Applicable
      
  • Native
    
    • Class: NA
      
    • Method: method is implemented in platform-dependent code. Note that a native method's body must be a semicolon (;) (like abstract methods), indicating that the implementation is omitted
      
    • Variables: NA
      
  • Strictfp
    
    • Class: Forces floating point to adhere to IEEE 754 standard. With strictfp, you can predict how your floating points will behave regardless of the underlying platform the JVM is running on.
      
    • Methods: same as class.
      
    • Variables: NA
      
  • Static
    
    • Concept: Doesn't depend on the state/instance of the class. Runs the same way independent of instance.
      
    • Class: NA (Unless they are nested)
      
    • Methods:
      
      • Exist before you make a new instance of the class.
        
      • static methods can't be overridden; they can only be re-defined.
        
      • Imagine you've got a utility class with a method that always runs the same way; its sole function is to return, say, a random number. It wouldn't matter which instance of the class performed the method—it would always behave exactly the same way. In other words, the method's behavior has no dependency on the state (instance variable values) of an object. So why, then, do you need an object when the method will never be instance-specific? Why not just ask the class itself to run the method?- that's what static does.
        
    • Variables:
      
      • all instances of a given class share the same value for any given static variable
        
      • Suppose you want to keep a running count of all instances instantiated from a particular class. Where do you actually keep that variable? It won't work to keep it as an instance variable within the class whose instances you're tracking, because the count will just be initialized back to a default value with each new instance. The answer to both the utility-method-always-runsthe-same scenario and the keep-a-running-total-of-instances scenario is to use the static modifier.