Как избежать передачи большого количества аргументов в методе с использованием подхода MVP

У меня есть экран регистрации с большим количеством полей регистрации, и когда пользователь нажимает кнопку регистрации, я передаю значения поля ведущему. В презентаторе я проверяю эти значения и создаю объект. Проблема заключается в большом количестве аргументов в методе register(). Я думаю, что мне следует избегать этой ситуации, но я понятия не имею, как это сделать.Как избежать передачи большого количества аргументов в методе с использованием подхода MVP

источник

2017-01-22 Yurii Mirskii

Возможно, вам понравится Builder pattern. Это позволяет сохранить код в чистоте, когда вам нужно передать большое количество аргументов. Это также очень полезно, когда вы не знаете точное количество аргументов, которые будут переданы, потому что некоторые из них могут не быть обязательными.

На практике, вы бы что-то вроде

MyObject myObject 
void register() { 
    myObject = MyObject.Builder(<mandatory arguments>) 
       .argument1(<argument 1>) 
       .argument2(<argument 2>) 
       ... 
       .create(); 
    if (myObject == null) fail(); 
    else dosomething(); 
}

источник

2017-01-22 15:03:15

Основная проблема не в создании объекта, а передаче аргументов ведущему. Я мог бы создать объект модели в представлении и передать его ведущему, но, согласно MVP, я должен переместить всю логику (например, проверку и создание объектов) до уровня ведущего –

Mmmm, возможно, я недостаточно эксперт MVP, но я думаю, что если вы имеют представление о том, что запрашивает некоторые данные для пользователя, он обязательно должен отправить эту информацию ведущему, но он не должен быть самим объектом. Возможно, я ошибаюсь, но если в представлении вы создаете объект с помощью шаблона builder, проверка и логика выполняются внутри create(), поэтому представление не должно знать никакой логики, просто нужно проверить, создан ли созданный объект имеет значение null или нет. Я действительно не знаю, является ли метод create() частью презентатора или модели. –

Если я создаю свою локальную сущность в представлении, было бы невозможно заменить этот объект объекта другим без редактирования. View не должен знать об объектах сущности, бизнес-логике и т. Д. И я думаю, что объектная модель объекта не должна иметь никакой логики внутри. –

Один способ я сделал это раньше, чтобы использовать TextWatcher на каждом поле, которое должно быть завершено:

myEditText.addTextChangedListener(new TextWatcher() { 
    @Override 
    public void beforeTextChanged(CharSequence s, int start, int count, int after) {} 

    @Override 
    public void onTextChanged(CharSequence s, int start, int before, int count) {} 

    @Override 
    public void afterTextChanged(Editable s) { 
     presenter.myEditTextChanged(s.toString()); 
    } 
});

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

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

Если вы используете ButterKnife, RxBinding или DataBinding, код более краткий.

источник

2017-01-22 19:42:52 Jahnold

Как избежать передачи большого количества аргументов в методе с использованием подхода MVP

ответ

Смежные вопросы