My friend bruno started a thread about interfaces and abstract classes and I wanna continue here. I totally agree with his points and I’m adding other ones here. About interfaces:

1. define a communication “protocol” between classes.

It is, a class which has an interface as a colaborator knows which operations it can send messages for this interface;

2. isolate the clients from the implementation.

So, you are free to change the internal structure of your implementation and the clients don’t have to concern with this. So, we are applying the hiding mechanism here, known as encapsulation;

3. clients don’t have to concern with implementation details, because they only work with the interface. The real type doesn’t care for the client;
4. define the form for a class. More precisely, is what the classes look like while the implementation says how the classes work.

About abstract classes:

1. describe an incomplete abstraction definition, as interfaces do;
2. define a common interface for all the subtypes;
3. establish a basic form, so it’s easy to say what’s in common between the subtypes;
4. express only a interface, not a particular implementation

Interfaces and abstract classes are ways of managing the internal coupling of your code. You create them when you want to manipulate classes through this common interface. If you only want to factor behavior, interfaces are a good choice, but if you want to factor structure too, choose abstract classes.

Tags: java

Some months ago I was wondering what was the benefit of using thread groups, which is a container of threads in Java. Reading Bruce Eckel’s Thinking in Java, I discovered this quote from Joshua Block, the one who improved the Collections framework in JDK 1.2:

“Thread groups are best viewed as an unsuccessful experiment, and you may simply ignore their existence.”

I haven’t been told about any Sun’s official statement about this topic before reading the book. So, why do they let us spend our effort trying to figure out the value of thread groups? 🙂

Tags: java

What do java programmers version control? is a good question to ask ourselves in the corporate world of software development. I think we should version control all the stuff regarding to the project knowledge, such as documents, wireframes, prototypes, notes, requeriments and obvious, source code :-). If you have a wiki available, documents about the project can be put and edited there. I think the build process has to take care of creation and manipulation of other dependent libraries, they should not be versioned. At my company we use Ivy, a java based dependency manager for this purpose. I haven’t been told about this tool before but I found it quite interesting to work with dependencies. You can even specify which version of a specific jar you need, Ivy finds the correct version and applies it as a dependency to your project. It seems to be very useful to manage the dependencies of software projects. And in your company, what’s your team allowed to version control?

Tags: java

From Bruce Eckel’s Thinking in Java book, about threads:

1. If you need to synchronize one method in a class, synchronize all of them. It’s often difficult to tell for sure if a method will be negativelyaffected if you leave synchronization out.
2. Be extremely careful when removing synchronization from methods. The typical reason to do this is for performance, but in JDK 1.3 and 1.4 the overhead of synchronized has been greatly reduced. In addition, you should only do this after using a profiler to determine that synchronized is indeed the bottleneck.

Tags: java