• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Faults with the original suncertify.db package

 
Gregory Golberg
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is it just me or is it a mess (of course, written by an
intern ? For example, FieldInfo and
DataInfo classes are used arbitrarily. That is, Data.add()
method takes a String array, instead of a DataInfo object,
thus effectively violating DataInfo abstraction -- we "know"
that it's just a bunch of strings, yeah, sure.
Another point: Data deals in 8-bit characters, yet FieldInfo
and DataInfo may lead one to believe that Java (Unicode) characters may be used, which can lead to some problems.
Yet another point: Nowhere in writing a new record is the
length of data checked, yet it may be greater than
the length declared in Field information, which may
screw up the database.
Granted, probably none of these issues will come up if
we are to implement the minimal requirements. However,
I think these are issues that need to be addressed
at least in the accompanying documentation.
I am also changing the code slightly to make FieldInfo and DataInfo check the arguments (for example, I've restricted
Field info to contain only alphanumeric ASCII chars,
and Data to contain only ASCII characters except single
quotes -- to ease the task of criteriaFind, and at the same
time make it Do The Right Thing most of the time).
I decided not to change Data.add() (and others) to
take DataInfo, for that would involve changing the
signature, which I am reluctant to do. The only change
in this approach is that methods affected throw
IllegalArgumentException when an invalid value for
field name or data is presented. Since it is a
RuntimeException, this breaks few things, some of
which already need breaking (and I believe we're asked
to assume that this happens as in the real world,
i.e., there is a possibility of someone using these
classes already).
To explain what 'needs breaking' means -- since Data already
deals in bytes, we can safely break existing code that
attempts to write, say, some data in Chinese, since it will
result in an even harder-to-trace error even if we do not
make these modifications to our code. As for making criteriaFind
more convenient, well, perhaps it is not a good reason;
I am still thinking about that...
What are people's opinions regarding this approach?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic