commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <ggreg...@seagullsw.com>
Subject RE: [codec] Binary BIT_n and BITS question.
Date Thu, 18 Mar 2004 19:16:16 GMT
> > > > (2) The public Binary.BIT_n fields are only used from Binary.
Should
> > > > they really be public fields?
> > >
> > > Hmmm I think this might be best kept private but I do use them
else
> > where
> > > in applications that depend on Binary however perhaps incorrectly.
> > Let me
> > > explain below.
> >
> > I see them used from the unit tests so perhaps they can be moved to
the
> > unit test code base.
> 
> Ok with me.  Let's just make them private in Binary and redefine them
as
> needed for use in the unit test cases.

Let me take a step back, sorry. I thought that the BIT_n fields were
only used in the tests where in fact they /are/ used in both the code
and the tests. My bad. In that case, the question is, I think, what
visibility should these fields have? I see several views, from strict to
lax:

(1) Make the fields private, there are implementation details. Let the
unit tests duplicate similar declarations. While duplication is not OO
it ensures that the tests /really/ can make the difference b/w expected
and actual values. After all, if there was a bug in some bit
declaration, the unit test might not find it. 

(2) Make the fields package private so that both test and code can share
the value.

(3) Leave as is, BIT_n fields are considered generally useful. You'd
have to agree that these field decls are germane to the Binary Codec
problem domain as public values and are very useful to call sites.

I think I like (1).

Gary



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message