Невозможно найти идиоматику дизайна/программирования за интуитивно-хорошей практикой: дайте объекту построить детерминированный период

Question

Вот моя проблема. Я хочу документировать часть программы и хочу что-то выразить, я считаю довольно распространенным среди сообщества программистов, но не могу взломать идею в одно слово. Взгляните на этот класс:

public class RemoteClient { 
    private InetSocketAddress remoteAddress; 
    /*+ some other fields not in the scope of this topic*/ 

    public RemoteClient(String hostName, int port 
    /*+ some other arguments not in the scope of this topic*/){ 
     this.remoteAddress=new InetSocketAddress(hostName, port); 
    } 

    public InetSocketAddress getRemoteAddress() { 
     return this.remoteAddress; 
    } 

} 

Очевидной проблемой в многопоточной среде является то, что вызывающий конструктор не имеет никаких гарантий, что hostName будет решена, и, следовательно, время сборки не является детерминированным. Было бы, как мне кажется, гораздо лучше, если строительство InetSocketAddress поленился, такие как следующие:

public class RemoteClient { 
    private volatile InetSocketAddress remoteAddress; 
    private final String hostName; 
    private final int port; 
    /*+ some other fields not in the scope of this topic*/ 

    public RemoteClient(String hostName, int port 
    /*+ some other arguments not in the scope of this topic*/){ 
     this.hostName=hostName; 
     this.port=port; 
    } 

    /** lazy instanciation **/ 
    public InetSocketAddress getRemoteAddress() { 
     if(remoteAddress==null){ 
      synchronized(hostName){ 
       if(remoteAddress==null){ 
        this.remoteAddress=new InetSocketAddress(hostName, port); 
       } 
      } 
     } 
     return this.remoteAddress; 
    } 

} 

Таким образом, в этом случае Thread вызова оператора конструктора, который мог бы на какое-то время строить из списка имена хостов, больше не связано с сетью. Теперь он делегирован Thread, который отвечает за связь с удаленным клиентом.

Мои вопросы:

• вы можете указать причины, почему второе утверждение/не лучше разработаны?
• не могли бы вы сказать слово на идиоме за этой практикой?

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

Answer 1

Простой, «сделать это в конструкторе метода времени», что вы не любите есть несколько больших преимуществ:

1. remoteAddress может быть final и более потокобезопасной, e.g. leaky constructors. И для простоты он избегает всего двойного замка. (Кстати, если вы не вызываете getRemoteAddress() Gazillion раз, просто синхронизировать ваш ленивый вызов.)
2. Если абонент дает неверный порт, он не сможет быстро (бросить IllegalArgumentException) в конструкторе который, вероятно, лучше место для обработки ошибки. Ленивая версия getRemoteAddress() не удастся значительно позже с IllegalArgumentException в методе, который не имеет аргументов, что очень сбивает с толку. Плюс к тому времени, вероятно, слишком поздно предпринять какие-либо корректирующие действия (например, вернуться к уровню пользовательского интерфейса, чтобы снова спросить в диалоговом окне).

Для записи я согласен с EJP в том, что конструктор без детерминированных скоростей вряд ли будет проблемой в любом случае.

Answer 2

В этом случае вам не нужно использовать synchronized с volatile. Неустойчивость делает всю работу за вас. C.f. the Java Language Spec:

Запись в летучую переменную V (§8.3.1.4) синхронизирует-со всеми последующим чтением V любым потоком (где «последующим» определяются в соответствии с порядком синхронизацией).

И это StackOverflow ответ на Safe Publication.

public class RemoteClient { 
    private volatile InetSocketAddress remoteAddress; 
    private final String hostName; 
    private final int port; 
    /*+ some other fields not in the scope of this topic*/ 

    public RemoteClient(String hostName, int port 
    /*+ some other arguments not in the scope of this topic*/){ 
     this.hostName=hostName; 
     this.port=port; 
    } 

    /** lazy instanciation **/ 
    public InetSocketAddress getRemoteAddress() { 
     if(remoteAddress==null){ 
      this.remoteAddress=new InetSocketAddress(hostName, port); 
     } 
     return this.remoteAddress; 
    } 

} 

Answer 3

Очевидной проблемой в многопоточной среде является то, что вызывающий конструктор не имеет никаких гарантий, что будет решена Hostname, и, следовательно, время сборки не детерминированный.

Я этого не вижу. Я не понимаю, почему это «очевидная проблема в многопоточной среде», и я не понимаю, почему «недетерминированное время построения» является проблемой в какой-либо конкретной среде вообще. Если время строительства является проблемой, это проблема в любой среде. Если то, что вы ищете, это более короткий тайм-аут DNS, есть способы обеспечить его соблюдение: см. Страницу «Свойства сети» в Javadoc.

Это было бы, я считаю, намного лучше, если бы конструкция InetSocketAddress была ленивой.

В этом случае все, что вам нужно, это InetSocketAddress.createUnresolved().