This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Number of classes/interfaces

 
Adrian Engler
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am working on a B&S assignment, and I am now quite close to the final phase.

There have been several threads in this forum about the number of classes and interfaces in the SCJD project. I have seen that some people used very few interfaces and classes and that I have even significantly more than those who thought they they have a lot.

I have the following packages:
- suncertify.application (starting the application, managing the communication between GUI and database)
- suncertify.db (database and locking related classes and interfaces)
- suncertify.gui (graphical user interface
- suncertify.gui.userguide (subsystem of the GUI for online help)
- suncertify.network (classes for networking with RMI)

These packages have the following numbers of classes and interfaces:
suncertify.application: 12 classes
suncertify.db: 26 classes and 12 interfaces
suncertify.gui: 27 classes
suncertify.gui.userguide: 8 classes and 1 interface
suncertify.network: 6 classes and 1 interface

This gives a total of 79 classes and 14 interfaces (a few more might be added until I have finished everything).
Most of the classes are very small - the introductory comment about what the class does and all the JavaDoc generally takes significantly more space than the actual code.

Some of the reasons why there are so many classes/interfaces:
- For the application/controller package, I have an abstract superclass for all kinds of applications, a subclass for the application started in server mode, an abstract subclass for the application started in client or standalone mode and two subclasses of this class, one for client mode and one for standalone mode. I think that the advantages of having such a hierarchy is that not so many conditional statements that make the code more complicated are necessary, and the advantage of the superclass for both client and standalone mode is that the GUI does not have to know about the concrete class of the controller because it should not care whether a local database is accessed or whether RMI is used.
- In the db package, nearly all the classes are referenced with an interface type; this helped creating mock objects for unit testing (I don't intend delivering the test classes of which there is quite a lot with the project)
- For writing and storing data, some of the functionality is in separate classes, for instance transforming the record contents, which are strings to the byte format in the database. I think this helps meeting future needs (e.g. when some fields would be stored in binary format or if different character encodings were used), and a design with a larger number of small classes also simplified unit testing.
- For the GUI elements for connection/server/database location settings, I have a type hierarchy with a superclass for what is common in all modes and subclasses for the different modes.
- For the elements that have to do with booking or cancelling bookings of subcontractors for customers, I created abstract superclasses that contain functionality that is of general use for updating records and concrete subclasses that deal with is specific for editing the booking status of selected records - I think this makes sense to meet the requirement that future functionality enhancements of the GUI should be expected.
- There are quite a lot of very small GUI classes that are probably not strictly required, but enhace the usability of the GUI, e.g. a class for a file filter that allows the user only to see files with a .db extension in the file chooser dialog that is used for selecting the database location in server and standalone mode.
- Generally, I have used separate classes implementing the ActionListener interface for each GUI element for which it is necessary to listen for events. The actionPerformed(...) method then performs things specific to the GUI and calls a method of the suitable class in the suncertify.application package. This way, the controller that communicates with the database is kept independent of specifics of the GUI. In most cases, the contents of actionPerformed(...) are only one or very few lines, and then the classes implementing ActionListener are not in a separate file, but in some cases, a bit more is done in there, and therefore, I decided to make them top level classes. In some cases, a class hierarchy for these ActionListener classes made sense (for starting/cancelling a connection/serer and for booking/cancelling booking).

So, I wonder what I should do. I would not like to get fewer points because I have an excessive number of classes and interface, but somehow I prefer a larger number of small classes (huge classes are a bigger problem in actual projects I have seen than overdesigned systems with an unnecessarily large amount of classes). Do you think it is necessary to reduce the number of classes? Or could the large number still be OK if I state reason why I chose such a design over one with fewer classes in choices.txt?
 
John Stone
Ranch Hand
Posts: 332
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Adrian,

how much time did you spend on it and how many code (in kb) is there?
 
Adrian Engler
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The sum of the sizes of the Java source files is 938 KB. This number is likely to go up a bit because I am still completing JavaDoc in some classes (in most cases it is already done). Most of the space in the source files is probably due to JavaDocs and comments. The sum of the sizes of all .class files is 222 KB.

I do not know exactly how much time I spent on the project. I worked on it almost full time (but probably a bit less than 8 hours a day) for about a week between Christmas and New Year, then I did very little until March because I was preparing for the SCWCD exam, and since April I have been working irregularly on the project on evenings and weekends, mostly just one to three hours a time. Now, I have again been working on the project more or less full time for one week because I had holidays. I guess, in total it might have been about 100 hours or slightly more up to now. Now, I don't have any holidays for the project any more, but there is still some work to do and I want to complete it some time in August.
 
John Stone
Ranch Hand
Posts: 332
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I found this on Sun homepage:

Perhaps a more consistent measure of the scale of the assignment might be derived from the average number of lines of code submitted in typical passing assignments. Again, this is subject to substantial variation, but as a guide, 3500 lines of code is a reasonable estimate of the mean size of passing assignments.


938kb sounds like a lot of work, I guess, that's about 20 000 lines of code. You probably did a lot more than required by assignment, but I believe there is justification for everything..

like: "Junior programmers have opportunity to learn something new.." :-)
 
Adrian Engler
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for your reply!

I have just seen that there was a problem with counting the kilobytes: I use subversion via TortoiseSVN, which integrates in windows explorer, therefore, I had not seen that the sizes for the directories included hidden subversion data...

In the meantime, I have already refactored the db package a bit for reducing overdesigning.

In one case, I used the strategy pattern for allowing the conversion between bytes that are used in the database and the strings that are used in the rest of the application (e.g. in the GUI) to be different for different fields, e.g. one field could store numbers in a binary format, another Cyrillic characters and a third Latin characters. But then, I realized that the database header does not have any place for specifying the data type for files (and, well, of course, the specification says explicitly that the concents are in US ASCII).

So, I replaced the two strategy objects for conversion between byte arrays and strings, their interfaces and the methods that store them in field information objects by two simple metod calls.

I still have the flexibility that new fields can be added or fields could be renamed in the legacy database without causing any problems for the application (new fields would just be displayed left-aligned and sorted alphabetically because no special information about their alignment and ordering is available) - this is not required, but I think it can be interpreted as being ready for future change, but different ways of converting between bytes and string are probably really totally unnecessary.

I also reduced the excessive amount of comments (because one automatic style checker suggested so, I provided full JavaDoc even for private methods and members, although it is required only for public ones in the project, and I had unnecessarily long file header comments) - this certainly helped reducing the size, as well.

So, the real total size of the source files is 464,5 KB (the big difference is really mainly due to the mistaken counting of hidden subversion files last time, the refactoring of the db package mattered a bit, but not so much).

LocMetrics (www.locmetrics.com) says that there are 11'233 lines of code in total, 4'560 physical lines of code, 3'170 logical lines of code, 1'146 blank lines and 5'527 comment lines in the project.

I think it will be relatively easy to reduce the size significantly, I can mainly shorten the comments. In the end, it will certainly still be more than 3'500 lines, but probably not much more than double that number.

As far as the functionality is concerned, I don't think I have done much more than is required - if the requirements could be understood in different ways (many things that were discussed here in the forum, I probably rather chose the option that requires a bit more work if it somehow seemed "better", but I haven't implemented anything that is clearly not required. What has probably most significance for the total size of the source files is a) overdesigning is some cases (like in the case mentioned above where I used the strategy pattern for rather unlikely future requirements instead of a simple method call) and b) header comments and JavaDoc texts that are very long.

How much is the effort for reducing the size of the source files worth?

I suppose removing unnecessary cases of overdesigning, patternitis and anticipating very unlikely future requirements really makes sense because it makes the code easier to understand. But there aren't so many of these cases in my project.

Does shortening the comments and JavaDoc texts make sense? That is certainly the area where reducing the size of the code is most easy. Probably, in some cases, it is advisable, e.g. removing duplicate passages and removing JavaDoc comments for private methods and member variables (although some style checkers think they should be there), but in general, I think JavaDoc texts that are not too short can also make the code more understandable.

What I would prefer not to do is cutting down functionality. In the GUI, there is quite a lot of things that are not strictly required (context-sensitive help, sortable table - which does not require that much code with Java 6 -, tool tips, a status bar whose contents depend on what is in the main part of the window, exact information about what has changed in the database when a user who has stale data tries to book a subcontractor), but I think they still somehow make the GUI better.
 
John Stone
Ranch Hand
Posts: 332
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now your project doesn't seem so large to me.

How much is the effort for reducing the size of the source files worth?

That's the hard question. I saw also thread "How simple is simple", with similiar questions, but there is no answer for this. And I think this is what guys in Sun are curious about. What you have designed, how and why this way?
 
John Stone
Ranch Hand
Posts: 332
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
At time I wrote my last post in this thread, over a month ago I had no idea how much I'll write. I thought, I'll make it simple and it will be small.

Now as I'm writing it, my project (without GUI layer) has 5172 (lines), 2274 (executable physical), 1686 (executable logical), 2322 (comments).

Which seems to be much compared to my estimates from last month :-). But I really don't have feeling I'm doing something extra. I just made search method really flexible, but that's couple of lines.

I'm curious about other rancher,.. what do you think, where are those lines coming from? :-)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic