I must apologies for the long deley between posts, unfortunately, I have just battled to come up with anything interesting to write. Hopefully this post will change this.
I have recently started investigating Enterprise Java Beans. It has been both interesting and frustrating. Entity beans I find to be hugely complex, all the local/remote/home/bean concepts are to my mind, having used JDO extensively, rather complex and difficult to grasp. Let's hope EJB 3.0 is all I'm hoping it will be...
Anyway, back to the matter in hand.
I was reminded of the relationship between what an object does and what an object knows. These two concepts are inextricably linked and should be carefully considered. To take an example from the real world - there are often times when knowledge is specific to the role of that person/entity. The classic - need to know basis. As an employee of a company I am given enough information to perform my set tasks, and no more. There is certain pieces of information which I should not be provided with, because they involve knowledge that is outside of the ambit of my responsibility.
The other scenario where knowledge is important is when I need to find out something. I should immediately be able to deduce the person or entity which possesses that knowledge. The knowledge required should be congruent with the person or entity who possesses that knowledge. It would be inappropriate for the cleaning staff to know the bank account details of the company for instance.
Now let's bring out thoughts into the object space. Like I was saying, I've recently started looking at J2ee and Enterprise Java beans. I'm using the Eclipse Web tools project to do the development. When you request an enterprise bean you have to do a JNDI lookup in order to locate that bean - you provide it with a name, and it returns a bean. When eclipse sets up a bean for you it creates a Util class which knows how to lookup the bean (one util class per bean). Thus this util class not only has the behaviour to lookup the bean but also the knowledge.
Personally, I do not believe a class that uses a bean should be required to know the location of the bean. The reason for this is that a class that uses a bean has a functional job. Imagine you create a class to lookup employee details. This class calls an EJB to achieve this end. The directory information require to locate the bean has little to do with the job which the class is assigned. Thus that knowledge of where the bean is should not be stored in the bean. The class kinda thinks, all I want is a hook onto this bean, I don't want to know where it is, why do I care?
The thing to remember is that a class is defined by its behaviour as well as its knowledge. In other words, looking at the data which a class contains, be it static or dynamic, is a valid and important mechanism for determining what the class does. If a class contains the database connection url, then it clearly must be responsible for connecting to the database. Thus it could easily have two responsibilities (bad idea), some other responsibility which requires a database connection.
One of the advantages of providing classes with data on a strictly need to know basis is that duplication is reduced. If I have a class whose sole responsibility is to acquire a handle onto an EJB, if I wish to change the lookup information for that bean I only have to change it in one place. This is because only one class "knows" that information. The other classes are not privy to that information, why should they be?
In light of this there should probably be more objects in our code, with potentially more static methods as well. On the one project I worked on I implement a help system. I created a class with a number of static methods which contained the code for hooking and displaying the help. I effectively created a help "service". The class was full of static methods - changing the help system was as easy as changing this class.
