Java +策略+工厂+相同的程序包=如何隐藏专门的类？

Question

I want to hide the specialization classes from the external classes of the same package.

Example:

package com.app.letter;
public interface LetterChange {
   void change();
}

public class A implements LetterChange{
   public void change(){..}
}

public class B implements LetterChange{
   public void change(){..}
}

To instantiate these classes I use a factory....

package com.app.letter;
public class LetterFactory{
   public static LetterChange getInstance(Object doesNotMatter){
   return doesNotMatter.isA() ? new A() : new B();
}

Note, all of them are in the same package and I DO NOT WANT to put the factory and the specialized classes in a sub package and change the specialization classes' constructors to default (package).

Following this example, I have a third class in the same package

package com.app.letter;

public class DoesNotMatterClass{
   public void situations(){       
      LetterFactory.getInstance(null); // Legal
      new A(); Illegal
      new B(); Illegal    
   }
}

I want to provide the A or B only by the factory LetterFactory.getInstance(doesNotMatter) which is in the same package.

Answer 1

Make A and B private static classes of the factory:

public class LetterFactory{
   public static LetterChange getInstance(Object doesNotMatter){
       return doesNotMatter.isA() ? new A() : new B();
   }

   private static class A implements LetterChange{
      public void change(){..}
   }

   private static class B implements LetterChange{
      public void change(){..}
   }
}

Only the factory knows the existence of these classes and can instanciate them.

Answer 2

First of all, I see no reason to not allow to instantiate your classes directly. Usually, you do not care who instantiated the class, as long as you are sure it was instantiated correctly .

Therefore, I believe you have not one problem, but two:

1. Provide a way for anyone to correctly create both class A and class B manually, if required.
2. Provide a way to instantiate either A or B given some set of abstract parameters (your Factory solution).

As for the first part, the are 3 ways to instantiate classes of different complexity correctly:

1. A constructor, which has a list of all required parameters and dependencies. This can be used for simple cases pretty well.
2. A factory method. This can be used for more complex scenarios.
3. A factory class/a builder class. These are usually used for complex scenarios.

Now, whichever one you choose, by all logic it should be allowed to be public. The constructor/factory method/factory class will enforce your rules to create a proper valid instance of either A or B . And, as I mentioned before, there is no possible scenario when you should disallow creating a perfectly good and valid instance of a class.

Let's say you went with a builder class as the most complex solution. Here's how your code might look:

package com.app.letter.A;
public class A {
    A() { //Package visibility, we don't want anyone to create an invalid A class
        ...
    }
    ...
}

public class ABuilder {
    public void validateAndSetSomeCriticalParam(Param param) {
        ...
    }
    public A build() {
        A a = new A();
        a.setSomeCriticalParam(param);
        ...
        return a;
    }
}

The builder should be designed in a thought in mind, that it could not in any way produce an invalid instance of A . This way, you can allow the builder to be the only way of instantiating A and not worrying about it, because all instances it creates are always valid. You can utilize proper API on the builder or Exceptions to reach this. Also, the builder approach is the most complex one, for some simpler scenarios you might use a bunch of public static factory methods. However the idea should remain the same - the public factory methods should ensure that they produce only valid instances of A .

Same stuff for B class, in other package:

package com.app.letter.B;
public class B {
    ...
}
public class BBuilder {
    ...
}

Now for the factory. Basically same thing you had, but with builders:

package com.app.letter;
public class LetterFactory{
    public static LetterChange getInstance(Object doesNotMatter){
        if (doesNotMatter.isA()) {
            ABuilder builder = new ABuilder();
            builder.setSomeCriticalParam(...);
            builder...
            return builder.build();
        } else {
            BBuilder builder = new BBuilder();
            builder.setSomeBSpecificParam(...);
            builder...
            return builder.build();
        }
    }
}

And about the usages:

public class DoesNotMatterClass{
    public void situations(){       
        LetterFactory.getInstance(..whatever..); // Legal
        new A(); //Illegal, as it is package protected
        new B(); //Illegal, as it is package protected
        new ABuilder(); //Legal, as ABuilder can ensure that only valid As are created
        new BBuilder(); //Legal, as BBuilder can ensure that only valid Bs are created
    }
}

I will add, repeating myself once again, you should only hide the parts of your system that can be abused in some ways. There is no point of hiding a class or a method if there is no way for it to be abused. Therefore, if you provide a way to correctly initialize a valid instance of A or B it should not matter to you that some other part of the system can see it or use it.

Answer 3

You can hide A and B from other packages by making them package-protected.

But that won't hide them from classes in the same package.

Since they have to be visible by the factory, but not by any other class of the same package, the only way to do that is to make them private static nested classes of the factory class.