Tuesday, December 20, 2005

What is an object supposed to know?

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.

Tuesday, November 22, 2005

Google and advertising...

When google made their first steps into advertising they took the view hitherto not taken too seriously. While the rest of the industry was using flash based animated adds, popups and even rather intrusive "pop-backs" (popups which appear when you close your browser windows), they eschewed those and went for POTA's (plain old text adds).

Their text based entry into advertising is discussed at How Google tamed ads on the wild, wild Web.

The article makes the point that while they were entering the market and sticking to text adds, some of the other advertisers were convinced that they would have to move to animated, flash based adverts eventually.

However, I would like to suggest that by going the text based route, restricting the text to a specific length, and make the adds context sensitive, google has succeeded in taking web advertising from a necessary evil, something you put up with, to a valuable and relevant part of an everyday web experience.

It is not suprise therefore that google is the only company which is making a lot of money from web based advertising. They saw the good in amongst the bad, they knew there was money to be made in web advertising, only if it's done right.

I find myself going to a web site now and getting severely irritated by "flash" (excuse the pun). A collection of horrible animated adverts that just plain make me mad. Those are the ones I want to turn off, they are the ones that distract me and make my browsing experience particularly unpleasant.

I much prefer going to a page which does not have animated or even picture based adverts.

Personally, I feel that google has been so successful at making text based ads fashionable that the consumer will start demanding that they are the only kind of ads that they see.

Monday, November 21, 2005

Geek and Beautiful do go together...

I stumbled on this site via slash dot I think, and I thought it was just too cool.

Check out The Geek Gorgeous Calendar featuring Women in Technology

"The calendar showcases young ladies who are not only beautiful and stylish, but can also fix your computer, normalize your databases, discuss the advantages of polymorphism, and beat you at Doom."

I think it's a great idea. Besides, who says you can't have both?

Friday, October 28, 2005

Those pesky Gui Designers...

My first introduction to a heavy weight java IDE was JBuilder. I have to admit, I do not remember those days with an fondness.

The application was in a nutshell, a data maintenance gui. I can remember rolling up my sleeves and fighting with the clumsy and just plain irritating gui designer.

Nowadays I have an intense disliking for the concept of automated gui design. I feel that coding it manually is a far more efficient and liberating approach to gui design. As an aside, I did experiment a little with gui design on the SWT API and saw an awful lot of potential there for a gui designer that I might be persuaded to use.

I think my eschewing of gui designers is both because of the lack of control and because I disliked the code that gui designers produced. Which is why a salute Charles Petzold and his article Does Visual Studio Rot the Mind?

He fully endorse everything he says on the subject and highly recommend that you read his words on automated gui design.

I'm also sure all the java programmers out there, will have a quite chuckle to themselves when they read about Microsoft plans with Avalon about how they're going to introduce layout managers (sic).

Friday, September 16, 2005

Object Oriented Design?

When Object oriented design first came on the scene there was a great deal of excitement. One of the early mantra's was that with the OO programming paradigm you can create complex data types which not only contains data but also the behaviour associated with that data.

The most obvious example of this is in the case of the Vector data structure. The standard vector consists of three scalars, x, y and z, and as my ever persistent matric science teacher was at pains to point out, "has magnitude and direction".

With OO you can create a data structure which contains the 3 scalars and a collection of methods in the same context as the scalars to allow the vector interact with other vectors. Addition, multiplication and dot product etc.

However, I'm not so sure if this is the key to the success of OO, nor that this paradigm should be ubiquitously applied.

It's probably fair to say that the majority of data types that are built in modern programming do not have such a tight coupling between their behaviour and their data and therefore this encapsulation should, in most circumstances, not take place.

In the case of the vector, it is in fact defined by its behaviour; the vector is an entity which has this set of data and behaves in this way. The same cannot be said about a Person object for instance.

Let's change tack for a second and look at what would happen if we do enapsulate the behaviour of an object with its data.

Consider a person object, it contains the name, surname, birthday etc of a Person. If we place behaviour for the person object into the person object it becomes prohibitively difficult to reuse that behaviour, for a different person object for instance. If we wish to use that behaviour we have go via the Person object itself. It also means that we cannot change the behaviour without affecting the data.

It is therefore better to create a data object which only contains the data associated with the Person and then another object which contains the behaviour associated with the person.

So then you might be asking, doesn't that make the data object little more than a struct, a concept which was part of the procedural programming paradigm? You would be right, but then that begs the question, why is the OO paradigm better?

The key to the OO paradigm is not that data can be associated with it's behaviour but that behaviour can be treated as a variable. The strength of a variable is that it is exactly that, it can change, it can be assigned and it can therefore be moved around. Now with the OO model we can pass behaviour around like a variable is passed around. With the introduction of objects, which have behaviour (methods), we can now treat behaviour like we would treat a string for example. We can pass it in as a parameter for a method, we can change the behaviour as easily as changing a variables value.

How is this achieved? It is achieved by something that was formally introduced in Java, the "interface". C++ fully supported interfaces in their "abstract classes with no implemented methods" guise, java however, created a new class type. Interfaces are exactly that, abstract classes with no implemented methods. In java, though it does not have multiple inheritance, there is no limit on the number of interfaces a class can implement.

If you write an object which contains functionality associated with a Person object then you would create an interface with which this behaviour would know how to talk. Your person object would then implement that interface, and by so doing, would be able to be acted upon by the functionality you have created.

Whether to separate behaviour from data is a decision that should always be looked at. Conjoining behaviour with data should only be done when the behaviour and data are tightly coupled. Making behaviour mobile is arguably the key advantage of the OO approach, and one that should be leveraged as much as possible.

Thursday, September 01, 2005

Only do it once...

When it comes to programming, one of my most recent mantras is to "only do it once".

Whenever I solve a problem, whatever that problem might be, I must only solve the problem once and then re-use that solution in future. By doing this you programs become many mini programs.

I can remember one of the first things I learnt, even when I still at school, about computer programs is that it's input, process, output. By employing this approach you are configuring alreaday written components, supplying them with input data and then firing them off.

A naive example would be, you have a square root to solve, you write a square route method, make it statically available (it is a stateless algorithm) and you never have to solve the square route problem again.

It has input - the input parameter you want to find the square root, it has processing, calculate the square root and it has result, the calculated square root.

Now on my current project, we receive data from a back end stored in a Map. We have to move that data into a data object. The populate mechanism for doing this would be to write something like...

Now, as you can see, for every different data object I receive from the back end, I have to do something similar to this.

However, that means I have to solve the same problem many times. If I apply the "only do it once, input process output" paradigm then I write a re-usable utility that will do the work for me. I supply it input parameters and configuration parameters, and it does the work of copying the data from the map to the data object.

In this case the input parameter is the map. The configuration parameter (this is a kind of input parameter) is the mapping between the key names in the map and the property names in the data object. The other input parameter would be the data object.

funkyMechanism(map, <ObjecToMapMapper> , dataObject)
So map to data object would contain...
START_DATE = startDate
AMOUNT = amount
In order to solve this problem in this way, reflection was used. There are ways to solve it using a similar input processing output paradigm, they're just not as elegant.

When programming try your best to only ever solve a problem once, and then re-use that solution. Think of instances where you can encapsulate a solution into input - processing - output. You'll find you code a lot less, your programs will be more robust and will have more of a Wow factor!

Friday, August 19, 2005

Swing and the client...

For the last week and a half I have been on a java gui project... I had to wipe away the cob webs entangled in my swing knowledge.

I read somewhere months ago about how Java's uptake ont he client was not as much as could be expected. I cannot remember the answer to this question. Having spent the last week and half building java guis, I'm pretty sure I know why.

Fundamental to building a gui is the laying out of gui components. Java eschews the absolute positioning and sizing of a gui in favour of the concept of a layout manager. This is a laudable goal, and I understand why they went this route. I agree with it to be honest. In a multi platform environment you do not know how an absolute size location on one platform will appear on another. What about when the user wishes to resize? What happens then when using the abolute system. What if you want to let the user resize? Proof of this is evident in that there is no XYLayout provided in java!

However, laying out components with the managers provided is a black art. To get the gui to look exactly the way you want it takes a lot of hair pulling. Just to get a component to move to the left by 5 points can sometimes take up to 2 hours. Just to get a gui to resize in the way you desire could take half a day.

I start building a simple gui, using one of the simpler layout managers. Eventually, the gui just won't work, and I have to use GridBagLayout. As far as I'm concerned, this is overkill, but I don't have any choice. I'd rather _not_ use it, but what can you do?

It does not have to be this way.

I have used the SWT Formlayout and find it GREAT! I wish that someone would be so kind as to port the SWT Formlayout to Swing. I have taken a short look at the java FormLayout (jGoodies). I will consider that manager and the Table Layout manager. Maybe they will work better.

Tuesday, July 05, 2005

Workers and Intellectuals

The commonly held belief is that in any company you need workers (people who do the work) and people who decide what to do. In other words, you need not so bright people who are happy to plug away at their keyboards, the "workers" and you need the intellectuals, people who guide the workers and leverage their value. That is the common view, probably wins the day mostly because you can't find enough "intellectuals", and you can't afford to pay a bunch of intellectuals their full value.

Look up http://www.thoughtworks.com. Started by someone who said no, and created a company of _only_ intellectuals.

But I digress. My Father has always talked about the difference between a manager and supervisor. He's said a _manager_ is an agent of change and a supervisor maintains status quo. Most of the managers in even our top companies are in fact super-visors. This is especially true in middle management. Pnp was a good example of this kind of manager. He has recently been mulling over the idea that leadership and management are not the same thing. This he says is what the cognscenti have recently been coming up with. And he has a point. A leader is someone who inspires, they have vision and drive. Just by sheer circumstantial evidence it is obvious that a manager is not necessarily a leader. I have found that a leader is more effective when they're perceived to be on the same level as the people they're leading. Kinda like the way you have NCO's in the army. They are some of the most important people in the army because they're on the ground. The infantry feel far more loyalty to the NCO's than the officers.

The other thing I wanted to say is that the difference between a manager/leader and worker is not intellectual or in ability. It is in _attitude_. Managers need to have the "can do" attitude. That attitude that says "cool, let's do it", instead of the "why do that?, that's a silly idea". It's question of how big is your world.

Monday, June 13, 2005

What would I do without Cygwin...

I have recently moved from a linux desktop onto a windows desktop. When I first started on the linux desktop I missed the familiar functionality in the "dir /s" command. There was no direct equivalent in linux.

I subsequently overcame this so called difficiency by utilising "find . | grep xxx". I also got used to using tail and less as well as vi.

Now that I am on the windows desktop a minor adjustment was required. Fortunately, and this is a big one, cygwin came to my rescue and provided me with all those familiar commands available in my now beloved bash.

It boggles my mind to think how any self respecting software developer committed to excellence can suffer a desktop without something as simple as tail. What is your windows alternative? Notepad! Heaven forbid. There is no out of the box viewer on a windows platform which can monitor a file for changes and render those changes when they happen. Do the microsoft developers deem the facility useful enough? In linux (and cygwin) you have two options; 'tail' for monitoring a file and 'less' for doing both viewing and monitoring (the best of both worlds).

Those guys at Cygwin make my life on a windows platform bearable.

I salute them.

Wednesday, June 08, 2005


The other day I went to the bank in order to have my garage card linked to my debit card instead of to my credit card. Considering I have had a credit card and a garage card for more then 3 years, to any plain man you would think it would simply be the case of, unlink from credit card, link with debit card.

In other words, they would simple cancel the garage card linked with the credit card and issue me with a garage card linked with the debit card...

Why then is it, that in order to acquire a garage card linked to my debit card I did in fact have to apply for a new garage card from scratch! Go figure...

Friends of mine had a similiar issue. They wanted to apply for something at the bank, I can't remember what, and the bank requested that they supply them with bank statements from the last year. To which the obvious reply is, you've got all the records, look it up and approve the application.

No, this is not the manner in which it would be done. Eventually they had to march home, get all the paper work in order and take it down to the bank.

Why is it that when you go to the bank it always seems as if you have to start from the beginning with everything.

The answer lies in usability. Take an average bank employee, the kind who deals with the public. Both the tellers and consultants. They are the "infantry" of the bank. They're the worker bees of the bank, and, just like the rest of the population, they can't even program a VCR. How could you then expect them to understand all the conditions and different ways of applying for a garage card. If the client has an account already then do this... For the sake of the "worker bees", everything is kept simple. If things were more complex, then the average bank employee would be swamped with paper work and would not understand any of the processes. Remember, most of the people in the world do not understand what they're doing, or critical evaluate _why_ they're doing it. They do it because they're told to do it. You average bank consultant is no different.

So the next time you get irritated with bureaucracy, spare a thought for the workers implementing the processes. They have to be simple enough for them to operate.

Tuesday, June 07, 2005

intro to the fork...

well, as I mentioned on my other blog (thoughts for life), quite a few weeks ago, that I was going to "fork" the blog. That day has finally arrived, thus we have analysis 102. Okay, okay, cool name you might say, well, obviously, because someone has already acquired the analysis 101 name. Hopefully, being a more advanced subject (102), the analysis may be more advanced.

This blog will be for well, thoughts on practical issues, business, computing etc. Hopefully the content will be interesting for anyone who thinks about the way things are and the way to make things better.