Saturday, May 08, 2004

Decoupling Your Java Code Decoupling Your Java Code   This was in interesting presentation by Dave Thomas in TSS Symposium that was completely different from the J2EE, Persistence, and Open Source framework talks and dealt with basics of Java programming.  He provided an interesting perspective to Java programming that general programmers overlook during application development projects.   He described the dependencies between Java classes as coupling and discussed problem that may evolve due dependencies of Java classes. The overly coupled code is very common and he describes symptoms of the overly coupled code as follows:   Minor changes require recompilation of whole system Unit testing requires every JAR on the box Things stop to work when context is changed Hard to partition the application as units   The types of couplings those are evident are:   Static coupling - when one class requires other to exist during compilation Using interfaces can reduce this. Also suggests using inheritance only when required.   Dynamic coupling – when using multiple method calls Train Wrecks e.g. order.getCustomer().getAddress().getState()  He suggests to avoid this type of coupling unless dependencies on external libraries.   Large Scale Coupling – a lot of dependencies e.g. having circular dependencies which is hard to maintain. He suggests avoiding this using mediator class or observer pattern.   Domain coupling – this is very prevalent in business applications as business rule e.g. tax calculations. He suggests to store these types of rules in the external system e.g. database tables and use those when required.   Temporal coupling – coupling in time or sequence of events.  He suggests to avoid using state machines , augmented mediator pattern or adhoc solutions such as thread based, JMS, etc.   I liked the presentation style of the speaker and his funny slides. This was real basic for most Java developers but most developers forget to implement these with crunch of time.     3:13:18 PM    comment []

© Copyright 2004 Debu Panda.

PS: These are my own thoughts and not of my employer ..