tough refactoring

| | bookmark | email
Long time no see. It was a hard month. I hope that the days to come to be more normal. Oke, back to business. I got on my head an applet client with about 150 classes. Told that it worked. Although at the beginning I didn't agree, now I'm very sure, and also, I'm not very happy about it. Eveything seems to me to be very messy (code duplication, a lot of unusefull delegation and lots of classes unused). I started by attacking the communication layer, which I thought was very important to my application. I've tried a refactoring and little by little the code is 70% rewritten (this is not very good, but now the communication is pretty neat). Other interesting part is some panels that are generated code and displayed according to user interactions. The generated code contained also lots of code duplication and unused methods and fields. I've fixed this too, so the code in a generated panel has been reduced by about 40%. I have only added 4 generic classes that add the default behavior. I am left with aproximatively 60% of this client, which is represented by specific GUI controls developed by extending the Swing. Huston, we've got problems. Number of methods/class: 11. Not so bad. But looking deeply, the most used controls have between 15 and 47 methods, and this is definitely not good. But the thing that bothers me the most is the duplicated code. I hate this code. You find yourself on the last days and find out a little bug. You fix it, but you must replicate that code in other x classe. Then you find out you just introduced another one, and your work must be redone. This way you can loose the delivery time. Keeping this in mind, I want to start eliminating the duplicated code. First idea: create a few generic controls with the attached default behavior and then let the others extend. But this solution is no good now, as all the developed controls extend a Swing control. I must find out something else. Secondly, I want to reduce interfaces offered by these controls. 47 public methods represents to much. For the moment I guess not only 15 of these are really used. Then why to publish such an interface... just for the future sake??? I am really trapped with this problem. As always, I don't have enough time to try to create some working skeleton and then only append the needed features. I must deal with the whole existing stuff. What I propose to myself is: - try to extract the common code and then find a solution for this code to be called from each already developed control; - step through all the controls and change the published interface and so finding out what is the really needed interface. After this, reduce the quantity of code. Maybe this step will be the first one, so the extraction step to be easier to be done. This is what I'm thinking this evening (in fact late night) after studying the code for 2 days. Tomorrow is a new day, and I think more ideas will be in my head. Till next time, ta-daaa.