Понимание пакетов Java и заводы

Question

Я читаю Брюс Eckel-х Thinking in Java и есть упражнение, я просто не получаю:

Pg. 161: Упражнение 8: (4) Следуя , форма примера Lunch.java, создает класс с именем ConnectionManager, который управляет фиксированным массивом объектов объектов Connection. Клиентский программист не может быть способен явно создавать объекты подключения, , но может получить их только через статический метод в ConnectionManager. Когда у ConnectionManager заканчиваются объекты, возвращает нулевую ссылку. Проверьте классы в main().

я придумал следующее решение:

// TestConnection.java 
import java.util.*; 

public class TestConnections { 
    public static void main(String[] args) { 
     Connection cn = Connection.makeConnection(); 

     for (int i = 0; i != 6; ++i) { 
      Connection tmp = ConnectionManager.newConnectiton(); 
      if (tmp == null) 
       System.out.println("Out of Connection objects"); 
      else { 
       System.out.println("Got object: " + tmp); 
      } 
     } 
    } 
} 

И второй файл в том же каталоге, что означает все заканчивается в одном пакете по умолчанию:

// ConnectionManager.java 
class Connection { 
    private Connection() {} 

    static Connection makeConnection() { 
     return new Connection(); 
    } 
} 

public class ConnectionManager { 
    static private Connection[] _connections = new Connection[5]; 

    private ConnectionManager() {} 

    static public Connection newConnectiton() { 
     for (int i = 0; i != _connections.length; ++i) { 
      if (_connections[i] == null) { 
       _connections[i] = Connection.makeConnection(); 
       return _connections[i]; 
      } 
     } 
     return null; 
    } 
} 

Дело в том, что клиентская программа может напрямую создавать объекты Connection через статический завод Connection.makeConnection, который, по-видимому, нарушает цели упражнений. Но если я сделаю ConnectionManager.java отдельным пакетом, тогда импортируйте его, жалуется, что он не может найти определение для Connection.

Я чувствую, что что-то у меня над головой, но я не уверен, что.

Вот код Lunch.java, который ссылается на вопрос:

//: access/Lunch.java 
// Demonstrates class access specifiers. Make a class 
// effectively private with private constructors: 

class Soup1 { 
    private Soup1() {} 
    // (1) Allow creation via static method: 
    public static Soup1 makeSoup() { 
    return new Soup1(); 
    } 
} 

class Soup2 { 
    private Soup2() {} 
    // (2) Create a static object and return a reference 
    // upon request.(The "Singleton" pattern): 
    private static Soup2 ps1 = new Soup2(); 
    public static Soup2 access() { 
    return ps1; 
    } 
    public void f() {} 
} 

// Only one public class allowed per file: 
public class Lunch { 
    void testPrivate() { 
    // Can't do this! Private constructor: 
    //! Soup1 soup = new Soup1(); 
    } 
    void testStatic() { 
    Soup1 soup = Soup1.makeSoup(); 
    } 
    void testSingleton() { 
    Soup2.access().f(); 
    } 
} ///:~ 

Answer 1

Это следующий более Lunch.java в том смысле, что его сделали, поставив некоторые классы под другим с соответствующими модификаторами доступа. Предполагая, что ученик/читатель книги еще не введен в interfaces.

// File cm.Connection.java 
package cm; 

public class Connection { 
    // The constructor has package access and so is available to 
    // ConnectionManager, but not to any class outside package cm 
    Connection() { } 
} 

// File cm.ConnectionManager.java 
package cm; 

public class ConnectionManager { 
    static private Connection[] _connections = new Connection[5]; 

    private ConnectionManager() {} 

    static public Connection newConnectiton() { 
     for (int i = 0; i != _connections.length; ++i) { 
      if (_connections[i] == null) { 
       _connections[i] = new Connection(); 
       return _connections[i]; 
      } 
     } 
     return null; 
    } 
} 

И, Connection и ConnectionManager в тот же пакет cm.

// File different.TestConnections.java 
package different; 

import cm.*; 

public class TestConnections { 

    public static void main(String[] args) { 
     Connection conn = ConnectionManager.newConnectiton(); 
    } 
} 

Обратите внимание, TestConnections в different пакет.

Answer 2

Каждый класс имеет область. В вашем коде класс Connection имеет пакет scope (то есть к нему могут быть доступны только классы внутри этого же пакета). Это означает, что перемещение класса ConnectionManager в другой пакет перемещает его за пределы области видимости класса Connection; это неудача, которую вы видите. Эти соединения должны быть расположены вместе со своей фабрикой.

На самом деле, что бы вы на самом деле сделать, это создать общедоступный интерфейс, который определяет, какие операции на Connection являются и собственной реализации этого интерфейса внутри ConnectionManager; то метод newConnection может просто объявить, что он возвращает экземпляр интерфейса, а механизм защиты пакетов останавливает любого, кто может заглянуть за этим интерфейсом (ну, не без использования более смелых частей отражения).

Answer 3

Вы сказали

Дело в том, что программа-клиент может непосредственно создать подключение объектов через статический Connection.makeConnection завод

Я думаю, если это через статический метод , это не напрямую.

Кроме того, оглядываясь назад на задачу

клиент программист не должен быть в состоянии явно создать подключение объектов

Вы решение скрывает тот факт, что новые соединения создаются. Вы можете подчеркнуть это, переименовав «newConnection» в «getConnection» или что-то еще.

Возможно, ожидаемое решение должно повторно использовать объекты соединения, но это не говорит об этом в упражнении. (И это не имеет большого смысла для соединений).

Answer 4

Цель получения соединения через ConnectionManager состоит в том, чтобы связать ресурсы с разделяемым классом. В этом случае вы можете издеваться над соединением при написании модульного теста.

Answer 5

У метода есть видимость по умолчанию, что означает, что он не может использоваться напрямую кодом в разных пакетах. (На самом деле то же самое относится и к самому классу Connection, которого я не думаю, что вы хотите).

Обратите внимание, что клиентские программисты могут обойти это, поместив свой код в один и тот же pacakge; но видимость кода обычно следует рассматривать как помощь, помогающую программистам-клиентам видеть API, а не детали реализации, а не как способ предотвратить умышленную глупость или злобу. Хотя, если вам действительно нужно запустить ненадежный код, вы можете вводить код в свои пакеты, подписывая JAR.

Answer 6

Трюк: соединение не должно быть конкретным классом, а интерфейсом. Второй класс (ConnectionImpl) обеспечивает реализацию этого интерфейса.

Только ConnectionManager может создавать экземпляры этого конкретного класса и возвращает интерфейс.

Пример (уменьшенный, чтобы показать модификаторы доступа):

public interface Connection() { 
} 

---

public class ConnectionManager { 
    private static class ConnectionImpl implement Connection { 
    private ConnectionImpl() { 
    } 
    } 
    public static Connection createConnection() { 
    return new ConnectionImpl(); 
    } 
} 

Answer 7

Другой способ, чтобы сделать Connection публичный вложенный класс внутри ConnectionManager. Но вам это может не понравиться. Предложения Андреаса и Дональда лучше и практичнее.

public class ConnectionManager { 
    private static Connection[] _connections = new Connection[5]; 

    private ConnectionManager() {} 

    public static Connection newConnectiton() { 
     for (int i = 0; i != _connections.length; ++i) { 
      if (_connections[i] == null) { 
       _connections[i] = new Connection(); 
       return _connections[i]; 
      } 
     } 
     return null; 
    } 

    public static class Connection { 
     private Connection() {} 
    } 

} 

отредактирован, чтобы показать, как TestConnections будет выглядеть,

public class TestConnections { 

    public static void main(String[] args) { 
     Connection conn = ConnectionManager.newConnectiton(); 
    } 
}