Чистый код. Создание, анализ и рефакторинг

                e.printStackTrace();

            }

        }

    };

    Thread clientConnection = new Thread(clientHandler);

    clientConnection.start();

}

Допустим, в результате внесенных изменений тест проходит[78]; задача решена, верно?

Анализ серверного кода

На обновленном сервере тест успешно завершается всего за одну с небольшим секунду. К сожалению, приведенное решение наивно, и оно создает ряд новых проблем.

Сколько потоков может создать наш сервер? Код не устанавливает ограничений, поэтому сервер вполне может столкнуться с ограничениями, установленными виртуальной машиной Java ( JVM). Для многих простых систем этого достаточно. А если система обслуживает огромное количество пользователей в общедоступной сети? При одновременном подключении слишком многих пользователей система «заглохнет».

Но давайте ненадолго отложим проблемы с поведением. Чистота и структура представленного кода тоже оставляют желать лучшего. Какие ответственности возложены на серверный код?

• Управление подключением к сокетам.

• Обработка клиентских запросов.

• Политика многопоточности.

• Политика завершения работы сервера.

К сожалению, все эти ответственности реализуются кодом функции process. Кроме того, код распространяется на несколько разных уровней абстракции. Следовательно, какой бы компактной ни была функция process, ее все равно необходимо разбить на несколько меньших функций.

У серверного кода несколько причин для изменения; следовательно, он нарушает принцип единой ответственности. Чтобы код многопоточной системы оставался чистым, управление потоками должно быть сосредоточено в нескольких хорошо контролируемых местах. Более того, код управления потоками не должен делать ничего другого. Почему? Да хотя бы потому, что отслеживать проблемы многопоточности достаточно сложно и без параллельного отслеживания других проблем, не имеющих ничего общего с многопоточностью.

Если создать отдельный класс для каждой из ответственностей, перечисленных выше (включая управление потоками), то последствия любых последующих изменений стратегии управления потоками затронут меньший объем кода и не будут загрязнять реализацию других обязанностей. Кроме того, такое разбиение упростит тестирование других модулей, так как вам не придется отвлекаться на многопоточные аспекты. Обновленная версия кода:

public void run() {

  while (keepProcessing) {

   try {

    ClientConnection clientConnection = connectionManager.awaitClient();

    ClientRequestProcessor requestProcessor

      = new ClientRequestProcessor(clientConnection);

    clientScheduler.schedule(requestProcessor);

    } catch (Exception e) {

      e.printStackTrace();

    }

  }

  connectionManager.shutdown();

}

Все аспекты, относящиеся к многопоточности, теперь собраны в объекте clientScheduler. Если в приложении возникнут многопоточные проблемы, искать придется только в одном месте:

public interface ClientScheduler {

    void schedule(ClientRequestProcessor requestProcessor);

}

Текущая политика реализуется легко:

public class ThreadPerRequestScheduler implements ClientScheduler {

    public void schedule(final ClientRequestProcessor requestProcessor) {

        Runnable runnable = new Runnable() {

            public void run() {

                requestProcessor.process();

            }

        };

       Thread thread = new Thread(runnable);

       thread.start();

    }

}

Изоляция всего многопоточного кода существенно упрощает внесение любых изменений в политику управления потоками. Например, чтобы перейти на инфраструктуру Java 5 Executor, достаточно написать новый класс и подключить его к существующему коду (листинг А.1).

Листинг А.1. ExecutorClientScheduler.java

import java.util.concurrent.Executor;

import java.util.concurrent.Executors;

public class ExecutorClientScheduler implements ClientScheduler {

    Executor executor;

    public ExecutorClientScheduler(int availableThreads) {

        executor = Executors.newFixedThreadPool(availableThreads);

    }

    public void schedule(final ClientRequestProcessor requestProcessor) {