Давайте обратимся к истокам. Щас вот наброшу прям =) А почему

Question

Давайте обратимся к истокам. Щас вот наброшу прям =) А почему

именно нельзя иметь контект в презентере или бизнес-логике? В чем обоснование?
Я слышал такие причины, что нельзя тогда простестить. Но есть Роболектрик, пожалуйста.
Роболектрик долгий. У меня он стартует за 6 секунд, это много?
На сколько я знаю, если Роболектрик стартовал для одного теста, то уже просто подрубается к следующим. То есть 6 секунд тратится один раз. Дальше все по накатке.
Действительно иногда требуется либо получение строки, либо даты, либо еще чего-то.
Не спорю, можно это обходить энамом, врапперами и т.д. Но стоит ли это того?
Я придерживаюсь позиции, что архитектура должна нам прежде всего помогать, а не усложнять. А если следовать бездумно некоторым канонам, смысл которых не так ясен, мне кажется не совсем верным.

#it #programming #russian #software

0

28.01.2017

3 ответов

23 просмотра

Ivan

имхо тестирование вообще мимо. Смысл в разделении приложения по слоям. И вот уже исходя их этого контекста не должно быть в презентере.

0

28.01.2017

Max Tuev

К теме, почему нельзя/можно использовать контекст в презентере. Я придерживаюсь такого мнения: контекст в презентере открывает огромное количество вариантов для чего его можно использовать. Когда видишь зависимость презентера от контекста, то мозг сразу настораживается, непонятно для чего конкретно он используется. Если презентер зависит только от самописных классов(причем построенных по принципу единственной ответственности) то просто глядя на конструктор презентера можно очертить границы, на что он может повлиять и от чего он зависит. Если конечно вы работаете в команде, каждый член которой имеет внутреннюю дисциплину и понимает какие границы использования контекста в презентере или у вас жесткое код ревью то проблем не должно быть, но если это не так, то на выходе можно получить проект, который вроде построен по MVP, но на самом деле имеет презентеры с размытой ответственностью и с различными side-эффектами. К тому же при таком раскладе может сыграть теория разбитых окон. Поэтому лучше задать изначальные ограничения на зависимости презентера и избавить проект от будущих проблем. Естественно за это придется заплатить чуть большим количеством кода, но, как известно, разрабы больше времени читают а не пишут код.

0

28.01.2017

Alexandr Zherebtsov · Accepted Answer

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

214 похожих чатов

Давайте обратимся к истокам. Щас вот наброшу прям =) А почему

3 ответов

Похожие вопросы