wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes To break or not to break? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "To break or not to break?" Watch "To break or not to break?" New topic
Author

To break or not to break?

Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
Do you recommend breaking up the functionality into small classes with limited capabilities? Sounds like just the thing to make testing easier.


Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Anton Golovin:
Do you recommend breaking up the functionality into small classes with limited capabilities? Sounds like just the thing to make testing easier.


I like small classes better than huge classes. There has been quite a bit of discussion on the Sun forums about ideal class size. Too many very small classes can cause object bloat, if you end up with a lot of instances as well. Very large classes tend to be difficult to test and to understand.

For example in my project I've defined a LockManager interface and concrete implementations that simply lock resources that are non negative long integers. It doesn't need to know anything about the file structure or things like record existence. It can be tested easily in isolation and can be proven for correctness. This also means that I can use a much simpler LockManager when running in standalone mode. Doing this does mean that the Data class must check for record validity and someone has to install the LockManager.

A standard old software engineering maxim is that a function, method or class or program should "do one thing well".
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
That's exactly what I had in mind. In my project, I need to read the datafile header, to read records, and to change a record's format. It can all happily co-exist in one same class, but I can't imagine de-bugging it.

So, I am implementing three classes: DBHeaderParser, DBRecordParser, and DBRecordManager. One reads the header, the other knows how to read and write a record, and the third changes the format of the records.

I should have little problem de-bugging classes 200 lines rather than 1000.
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
My data tier is split in to:

DataFile - multiton, raw file handling only - no find method.
DataCache - caches DataFile - no find method.
Data - implements supplied interface, adds find method and locking.

I'm also considering Peters approach of a LockManager interface for obtaining different Locking strategies (or absence of them :-) but I think this may be overkill, and I'm very scared of the 44/80 on locking.

My main design descision left is exactly the best way to link those DataXxx classes. I'm considering Decorator, sublclassing (not seriously), interfaces and subinterfaces...


SCJP 1.4, SCJD
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by mike acre:
My data tier is split in to:

DataFile - multiton, raw file handling only - no find method.
DataCache - caches DataFile - no find method.
Data - implements supplied interface, adds find method and locking.

I'm also considering Peters approach of a LockManager interface for obtaining different Locking strategies (or absence of them :-) but I think this may be overkill, and I'm very scared of the 44/80 on locking.

My main design descision left is exactly the best way to link those DataXxx classes. I'm considering Decorator, sublclassing (not seriously), interfaces and subinterfaces...


On structure:
Your structure is quite similar to mine, I use a singleton for the DatabaseFile class, since we are only dealing with a single table. If this needed to support multiple tables I would use a Factory to provide instances based on the table name with only one instance per table, I assume that's what you mean by multiton.

I'm still uncertain about caching, given the capabilities of modern file systems this may be wasted effort. The operting system may already be doing more than you need. Caching also brings up all those problems with write through buffers. I am considering providing a means to index a field, so that the searches can be very fast for frequently referenced fields. I'd probably build the index for deleted records, name and location at startup since these are the only fields currently involved in searches. The other choice is to build the index the first time a full table scan is required.

On the LockManager:
I always require a LockManager, even for the single threaded standalone case. My SingleLockManager still requires the locking protocol to be followed and will throw a SecurityException if used by any thread other than the one that instanciated it. The default LockManager is the MultipleLockManager which supports multiple threads.

On the Data class:
I use simple composition. The Data class has an instance of the DatabaseFile that it gets when its constructed. The DatabaseFile is already constructed before the Data class in most circumstances, but is capable of being constructed in a lazy manner, using whatever file it gets from the properties. This is where the Singleton comes in handy. If you need to know the file name to create a DatabaseFile object, there is no way to have a default no argument constructor for your Data class. Now, I don't know how much automated testing of this code they will do, but I want to provide a default constructor for that class.

If you call my Data default constructor, you get whatever file is in the suncertify.properties in the current directory, or the default.properties in my jar file and you get the MultipleLockManager that supports multiple threads. I don't actually provide any non-default constructors for Data at present. I provide a setLockManager method so the standalone version can request the simpler LockManager.
 
GeeCON Prague 2014
 
subject: To break or not to break?