Posts

Showing posts with the label method

Java doesn't have "Diamond" problem : Really ..?

Java doesn’t have “Diamond” problem : Really ..? We have been confidently telling that Java doesn’t have diamond problem even if it support multiple inheritance. In object-oriented programming languages with multiple inheritance and knowledge organization, the diamond problem is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. But do you that the diamond problem is now there in newly introduced Java 8. It is because of the introduction of default methods in Interface. In Java8 Interfaces not only have method declaration but their default implementation. Any class implementing can either use default implementation from interface or provide its own implementation. Since Java class can implement multiple interfaces it is possible that two interfaces has same default methods, that brings diamond problem. How do we overcome diamond problem ? Consider following code snippet public interface InterfaceA { ...

Overloaded function in Javascript

Coming from Java background, it is happened to be searched java language constructs while coding javascript. One of such construct is overloaded methods/function. Take a look following code snippet   //Normal sum var intergerSum = sum ( 10 , 20 ); //Expecting item price sum var objectSum = sum ( {item_id: '01' ,name: 'abc' , price: 100 }, {item_id: '02' ,name: 'xyz' , price: 200 } ); As per above code snippet, implementation of ‘sum’ has been abstracted from the user. In the world of type safe language like Java, it is very straight forward, but in case of javascript we need to have our custom implementation. Lets see how can we achieve above in javascript. Lets start with defining a constructor function which introduce a common function to all our custom object so that we can extract integer value for summation. //constructor function to introduce new function to custom object function item (options) { var instance = Object...

Characteristics of Object.equals()

I am come across the characteristics specified for implementation of equals() method in Java Classes. There is nothing like which we don’t know, but here it is well explained. I thought of sharing the same just for recalling old Java learning days Here are the characteristics that every implementation of Object.equals() should follow Reflexive. For any non-null reference value x, x.equals(x) should return true Symmetric. For any non-null reference values x and y. x.equals(y) should return true if and only if y.equals(x)   returns true. Transitive. For any non-null references value x,y and z , it x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true . Consistent. For any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified. For any non-null reference value x, x.equals(null) ...

Improved Exception handling in Java 7

Java 7 has improved the exception handling by ease of development, reduced code duplication  and intelligent throws clause. 1. More than one  exception types in single catch block: Java 7 onwards single catch block can handle multiple exception types. Now Catch block can specify ‘|’ separated exception types instead of only one exception. It prevent code duplication in case when same operation has to perform for all of set of types of exceptions and improve code readability. Old style : try { //your code here } catch (IOException ex) { log(ex); throw ex; catch (SQLException ex) { log(ex); throw ex; } New style : try { //your code here } catch (IOException|SQLException ex) { logger.log(ex); throw ex; } 2. Intelligent throws clause : Method declaration has to include the list of exception its is going to throws using throws clause. These exception types has to be matched with catch block throw statement. Java 7 onwards compiler ...

Java Puzzle : Function parameters

Here is another Java puzzle, but this time you don’t need to find output of this program. Instead just complete the code snippet to get desired output. Here is the program : public class OPuzzle { public static void main(String[] args) { Object o = null; printMe(o); } private static void printMe(<Provide the declaration here> o){ if (o!=null){ System.out.println( "I am not null" ); } } } Desire output : I am not null Replace the <Provide the declaration here> with appropriate declaration to get above desired output. Leave your comments. Reference : http://google-opensource.blogspot.com/2011/04/geek-time-with-josh-bloch.html   No no no … don’t see reference before solving :).

Covariant Return Type

One of the pillars of Object Oriented Java language is Polymorphism. Polymorphism allows two or more methods within the same class that share the same name, as long as their parameter declarations are different .  It also allows two or more methods in class hierarchy where child class can have same method name as of parent class, but their signature should be same. Here is a limitation on overridden methods, they can not have different return types. J2SE 5.0 has come up with a solution for this limitation. Onwards J2SE 5.0 new feature called “Covariant Return Types”. “As per Covariant Return Types, a method in a subclass may return an object whose type is a subclass of the type returned by the method with the same signature in the superclass.” Consider following example 1: class ParentClass 2: { 3: public SuperValue getValue(){ 4: System.out.println(" ParentClass.getValue() "); 5: return new SuperValue(); 6: } 7: 8: } 9: 10: 11: public c...

Understanding Observer Designing Pattern by Example

Image
  “The Observer pattern define a one to many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.” With the observer pattern, the source is the object that contain the state and control it. The Observer on the other hand use the state, even if they don’t own it. The observer pattern provides an object design where the subject and observer are loosely coupled. Here is the Class Diagram explaining Benefit of loosely coupling The only thing the subject knows about an Observer is that it implements a certain interface We can add new Observer at any time We never need to modify subject to add more observer. We can use subject or observer independently of each other. Change in either observer or Source will not affect the other. Here is an example : This example explains Observer pattern, here source generates random characters and observer, Java Swing component listen this eve...