DuraSoft TechLet 08, 2002
|
Welcome
to the August 2002 TechLet. If you have received this through some one you know and
would like to subscribe directly for our future issues, please send an email to
techlet@durasoftcorp.com with a subject subscribe. This subscription currently
is absolutely free.
In this issue, we have a detailed article on Interface based programming. |
| Interface based programming! When I ask people why they want to use the object paradigm, invariably one of the top answers is Reusability. Yet, how much of the code we write is reusable? Are we writing code that lends itself to reusability? In this article, we will talk about how interface based programming truly helps us to develop reusable and extensible code. The complete article can be found at http://www.durasoftcorp.com/download |
What is the result of executing the following code (try to answer without running it of course)?
The answer will be in the next issue.
class Employee
{
public Employee() { work(); }
public void work(){ System.out.println("Employee working"); }
}
class Room
{
public void openWindow() {}
}
class ExecutiveRoom extends Room {}
class Manager extends Employee
{
private Room theRoom;
public Manager(int level)
{
if (level == 1)
theRoom = new Room();
else
theRoom = new ExecutiveRoom();
}
public void work()
{
theRoom.openWindow();
super.work();
}
}
public class Test
{
public static void main(String[] args)
{
Employee emp = new Employee();
emp.work();
Manager mgr = new Manager(2);
mgr.work();
}
}
Quiz from the past issue A class keeps track of the number of objects created. Partial code is shown below: public class A
{
private static int objCount = 0;
public A()
{
synchronized(getClass()) { objCount = objCount + 1; }
}
...
}
The constructor is performing a thread safe increment. Is this increment well protected? What could go wrong? Answer! The intent of the synchronized block above is to protect the variable objCount from being concurrently accessed from mutiple threads. If two threads are creating objects of A at the same instance, then each thread would call the synchronized(getClass()). But, only one of the threads would gain access to the monitor (lock) on the meta objec, which is returned by getClass(), and the other will get blocked. This, of course, is what we would like to happen. However, if you derive a class, say B from A, and if one thread is creating an object of A while another thread is creating an object of B, then, unfortunately the first thread will obtain the monitor on the meta object for A (getClass() called on object of A will return the Class object of A), while the second thread will obtain the monitor on the meta object for B (getClass() called within the constructor of A for an object of B will return the Class object of B and not A!). The thread safety breaks here at this instance. What is the Fix for this? We can modify the synchronized(getClass()) to synchronized(A.class).
|
|
If you like any question to be addressed or topic to be discussed, please send
us an email to techlet@durasoftcorp.com. At the end of the year, one person
will be randomly selected from the list of respondents for a special prize. We
would like to hear from you.
Please send suggestions, corrections and comments to techlet@durasoftcorp.com. When you have learned what an explanation really is, you can then go on to more subtle questions - Richard Feynman. |