Adaptive Software Solutions

Static imports have been around since Java 1.5, but they are a feature that I have rarely used, or even seen much in code. I guess that's because static imports is not a must have thing, but something that is nice to have . Using static imports takes some pain away from typing code. For example, instead of writing System.out.println("some message"); we could statically import System.out and write it as follows: static import  System.out; public class  HelloWorld  {    public static  void  main ( String args []) {      out.println ( "Hello World" ) ;    } } Well using static imports definetely takes the pain away from typing System.out every time. However sometimes using static imports can also reduce the readability of code, because we would have to look at the imports to know if a variable in code was declared within that class itself or imported statically. Hav...

Can you spot the mistake in this code? // BROKEN - throws NoSuchElementException! for (Iterator i = suits.iterator(); i.hasNext(); ) for (Iterator j = ranks.iterator(); j.hasNext(); ) sortedDeck.add(new Card(i.next(), j.next())); If not, check this article on the Java for...each loop. Note: This text was originally posted on my earlier blog at http://www.adaptivelearningonline.net

In the past few posts we have discussed how it can be dangerous to extend a class that we do not control, if it has not been designed for subclassing. We understood this concept with a specific example from Josh Bloch's book: Effective Java. In the example we subclassed the HashSet class in the JDK. Without repeating the material, I will simply reiterate what I said in my previous post: The real problem was the class AbstractCollection which was not designed properly for inheritance. It is a non-final class with a public method addAll(Collection c) which invokes another non-final public method add(Object o) . Here is a possible implementation of the HashSet class that does not break the DRY principle and is also safe for extending...

In the previous post we saw how subclassing from a class not designed for inheritance, can be dangerous. Using composition instead of inheritance would have solved the problem. But what was the crux of the problem? Could such a trap have been avoided? Could AbstractCollection have been implemented so that such a situation would not have arisen in the first place? The real problem was the class AbstractCollection which was not designed properly for inheritance. It is a non-final class with a public method addAll(Collection c) which invokes another non-final public method add(Object o) . How should AbstractCollection have implemented add(Object o) and addAll(Collection c) to prevent such a problem? I do not know if this problem has been fixed in OpenJDK. They may have not been able to do so to maintain backwards compatibility. You can check out the sources from their website . In the next post we will discuss an idiom for preventing such a situation.  Discuss this post in the...

I ended my previous post with a paragraph from Josh Bloch's book, Effective Java . In his book, Josh explains why inheriting classes from a different package (especially inheriting from a class that may not be designed and documented for inheritance) can be dangerous. Below you will find Josh's example (from Effective Java ) that explains the concept. Many many thanks to Josh Bloch for graciously giving me permission to reproduce the example here :-) The class InstrumentedHashSet is a subclass of HashSet, that maintains a count of the number of objects added. It overrides the add(Object o) and addAll(Collection c) methods from HashSet to maintain a count of objects added to it. These methods increment the count and then delegate responsibility for adding the element to HashSet. The number of objects added can be obtained from the method getAddCount() . This seems like a reasonable way to count objects added to the Set. Unfortunately it's not. But first let's have a l...

Inheritance is used for Code resuse To support polymorphism Disadvantages of inheritance Difficult to change the interaface of the subclass Superclass is always instantiated Can get complex and unmanageable Composition is used for code reuse Disadvantages of composition We cannot use polymorphism We cannot extend the system by adding subclasses May have a slight performance overhead Usage Inheritance: IS- A Composition: HAS - A Example 1 : public class Car {    private Engine engine;    public void start () {}    public void stop () {} } public class SUV extends Car {    public void start () {} //overrides the start method from Car    public void fourByFourMode () {} } Example 2 : public void someMethod () {    Car c = new SUV () ;    c.start () ; } Example 3 : public class Car {    private Engine engine;    public void start () {    ...

[Time: 4 mins] Stuff that goes together, stays together Easy to discover relevant code Levels of cohesion packages classes methods So in very simple words, cohesion is keeping related stuff together so we can find what we want without too much difficulty. Example 1 : public class Student { //cohesive methods public void registerForCourse () {} public void deregisterFromCourse () {} viewTranscripts () {} //methods below are not in synch with the responsibilities of the Student class //hence cohesion is broken submit grades () {} submitCourseSchedule () {} } Java2html Resources: High cohesion on Wikipedia Note: This text was originally posted on my earlier blog at http://www.adaptivelearningonline.net