On Jan 23, 12:03 am, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
wrote:

Thanks for all of you. You let me to find the limitation of my design.
So I change it.

I changed my design:

1 Add a protect method GetInstance() in Class B;
2 Add a class E which is extends from B in package XX.ZZ.GG. Create a
protected method GetInstance() which has the same function of
A.GetInstance() in class E.   Remove the Method  A.GetInstance().
3 Add a static member 'B e ' withe the default access right in Class
B, construct 'e'in the static block of B as 'E':
          static{ e = new E; }

In this design B,C and D can invoke B.e.GetInstance() which is
E.GetInstance(), any other classes that is not in package XX.ZZ (and
also not in package XX.ZZ.GG) can't invoke the E.GetInstance().

Is my design OK ?

Please note that ignoring good advice, especially from one such as Roedy who
really goes out of his way to be helpful, is risky.  You send a message that
you aren't really interested in good advice, thus lowering the expected value
of advice that you will receive.  Quoting that advice, then disregarding,
gives the no doubt accidental impression that you are evincing deliberate
disrespect.  I'm sure that you did not mean that, of course.

There's good reason for the coding conventions, particular where upper- and
lower-case names are concerned.  These conventions facilitate discourse about
Java programs.  Discourse about Java programs is the whole point of the
clj.programmer newsgroup.  There is a tolerance for variation from some parts
of the convention, formalized in 1999, but only to a point.  Indentation, for
example, has two major variants with permissible indentation sizes that can
vary in a narrow range.  However, the case conventions are pretty solid and
should not be ignored.

Java from the beginning has been a "literate programming" language -
information about the program is embedded in the source code for the program.
 Javadocs are one aspect of that.  Annotations are another.  The naming
conventions stress the use of names out of the domain of discourse - the
logical model for the program, not out of the implementation.  Thus
"WidgetExtractor" tells us by the initial upper-case letter that this is a
class name for something that models a widget extractor.  No need to embed the
redundant "Class" in a name like "WidgetExtractorClass".  The identifier
"widgetExtractor" in this context now tells us that we see an instance of that
class.  "widgetExtractor()" jars the senses, because it's a noun phrase for a
method name; "widgetExtract()" would be more comfortable.  With little if any
cognitive strain one can infer many things about the logic and the domain
model from a source code artifact without interrupting the flow of reviewing
it, if these conventions are rigorously followed.

So please, for both engineering and social reasons, use lower-case identifiers
for your package names.