MT
Давайте обратимся к истокам. Щас вот наброшу прям =)
А почему именно нельзя иметь контект в презентере или бизнес-логике? В чем обоснование?
Я слышал такие причины, что нельзя тогда простестить. Но есть Роболектрик, пожалуйста.
Роболектрик долгий. У меня он стартует за 6 секунд, это много?
На сколько я знаю, если Роболектрик стартовал для одного теста, то уже просто подрубается к следующим. То есть 6 секунд тратится один раз. Дальше все по накатке.
Действительно иногда требуется либо получение строки, либо даты, либо еще чего-то.
Не спорю, можно это обходить энамом, врапперами и т.д. Но стоит ли это того?
Я придерживаюсь позиции, что архитектура должна нам прежде всего помогать, а не усложнять. А если следовать бездумно некоторым канонам, смысл которых не так ясен, мне кажется не совсем верным.
А почему именно нельзя иметь контект в презентере или бизнес-логике? В чем обоснование?
Я слышал такие причины, что нельзя тогда простестить. Но есть Роболектрик, пожалуйста.
Роболектрик долгий. У меня он стартует за 6 секунд, это много?
На сколько я знаю, если Роболектрик стартовал для одного теста, то уже просто подрубается к следующим. То есть 6 секунд тратится один раз. Дальше все по накатке.
Действительно иногда требуется либо получение строки, либо даты, либо еще чего-то.
Не спорю, можно это обходить энамом, врапперами и т.д. Но стоит ли это того?
Я придерживаюсь позиции, что архитектура должна нам прежде всего помогать, а не усложнять. А если следовать бездумно некоторым канонам, смысл которых не так ясен, мне кажется не совсем верным.
К теме, почему нельзя/можно использовать контекст в презентере. Я придерживаюсь такого мнения: контекст в презентере открывает огромное количество вариантов для чего его можно использовать. Когда видишь зависимость презентера от контекста, то мозг сразу настораживается, непонятно для чего конкретно он используется.
Если презентер зависит только от самописных классов(причем построенных по принципу единственной ответственности) то просто глядя на конструктор презентера можно очертить границы, на что он может повлиять и от чего он зависит. Если конечно вы работаете в команде, каждый член которой имеет внутреннюю дисциплину и понимает какие границы использования контекста в презентере или у вас жесткое код ревью то проблем не должно быть, но если это не так, то на выходе можно получить проект, который вроде построен по MVP, но на самом деле имеет презентеры с размытой ответственностью и с различными side-эффектами. К тому же при таком раскладе может сыграть теория разбитых окон. Поэтому лучше задать изначальные ограничения на зависимости презентера и избавить проект от будущих проблем. Естественно за это придется заплатить чуть большим количеством кода, но, как известно, разрабы больше времени читают а не пишут код.
Если презентер зависит только от самописных классов(причем построенных по принципу единственной ответственности) то просто глядя на конструктор презентера можно очертить границы, на что он может повлиять и от чего он зависит. Если конечно вы работаете в команде, каждый член которой имеет внутреннюю дисциплину и понимает какие границы использования контекста в презентере или у вас жесткое код ревью то проблем не должно быть, но если это не так, то на выходе можно получить проект, который вроде построен по MVP, но на самом деле имеет презентеры с размытой ответственностью и с различными side-эффектами. К тому же при таком раскладе может сыграть теория разбитых окон. Поэтому лучше задать изначальные ограничения на зависимости презентера и избавить проект от будущих проблем. Естественно за это придется заплатить чуть большим количеством кода, но, как известно, разрабы больше времени читают а не пишут код.
