> > > > (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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
