Java: когда использовать поля против аргументов? - PullRequest
2 голосов
/ 10 ноября 2011

Мое текущее приложение IVR использует класс-оболочку с несколькими методами для вызова веб-службы, а затем анализирует ее результаты.У каждого класса есть один метод «invoke», который вызывает веб-службу, а затем вызывает последующие подметоды, чтобы разбить синтаксический анализ на логические порции.

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

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

Вместо:

 invoke (oldField1, oldField2, newField1)  
 submethod1 (results, oldField1, oldField2, newField1)  
 submethod2 (results, oldField1, oldField2, newField1)  

Должно ли оно быть:

 invoke(oldField1, oldField2, newField1){
   OldField1=oldField1
   OldField2=oldField2
   NewField1=newField1
 }
 submethod1(results)
 submethod2(results)

Или даже:

 new (oldField1, oldField2, newField1){
   OldField1=oldField1
   OldField2=oldField2
   NewField1=newField1
 }
 invoke()
 submethod1(results)
 submethod2(results)

Спасибо!

Ответы [ 3 ]

4 голосов
/ 10 ноября 2011

Первое решение позволяет сделать объект без сохранения состояния и позволяет использовать уникальный экземпляр для всех вызовов, даже параллельно.

Третье позволяет сделать объект состоящим, но неизменным.Его можно использовать для нескольких вызовов с использованием одного и того же набора полей, даже параллельно (если они сделаны неизменяемыми).

Оба эти решения приемлемы.Чем меньше состояние объекта, тем проще его использовать, особенно в многопоточной среде.

Чем менее изменчив объект, тем проще его использовать.

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

1 голос
/ 10 ноября 2011

Мое общее правило - по возможности избегать отслеживания состояния в сервис-ориентированном классе.Хотя Java на самом деле не поддерживает функциональное программирование как таковое, самая простая и масштабируемая реализация - это ваш первый подход, в котором не используются переменные-члены.

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

public class Invoker {
    public static void invoke(ResultContainer result, List<String> parameters) {
        submethod1(result, parameters);
        submethod2(result, parameters);
    }
}

Я также рекомендую вам взглянуть на шаблон оформления Decorator для получения дополнительных идей.

0 голосов
/ 10 ноября 2011

Это зависит от того, является ли ваш аргумент данными или идентификатором режима / переключателя.

Я предлагаю один аргумент для типа структуры данных и другой аргумент, который содержит типы перечисления различных операций.

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

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

...