KT
метод handleCommand - удалось прочесть раза с пятого)
Size: a a a
2017 February 10
DC
Да запутанность это большой минус
KT
не стоит сокращать код ухудшая читаемость
KT
никому от этого профита нет
AP
Ребят, а у меня в голову такая мысль пришла.... А что если сделать кастомный роутер и там сделать методы наподобии:
navigateToMainScreen(MainScreenArgs args);
navigateToProjectsScreen(ProjectScreenArgs args);
и т. д., т.е. смысл в том чтобы сделать удобную сигнатуру вызова, чтобы передать туда параметры для конкретного экрана, а роутер же уже знает как открыть конкретный экран. Вместо того чтобы использовать navigateTo(ScreenName, params). Как Вам такой роутер? покритикуйте.
navigateToMainScreen(MainScreenArgs args);
navigateToProjectsScreen(ProjectScreenArgs args);
и т. д., т.е. смысл в том чтобы сделать удобную сигнатуру вызова, чтобы передать туда параметры для конкретного экрана, а роутер же уже знает как открыть конкретный экран. Вместо того чтобы использовать navigateTo(ScreenName, params). Как Вам такой роутер? покритикуйте.
VC
Ребят, а у меня в голову такая мысль пришла.... А что если сделать кастомный роутер и там сделать методы наподобии:
navigateToMainScreen(MainScreenArgs args);
navigateToProjectsScreen(ProjectScreenArgs args);
и т. д., т.е. смысл в том чтобы сделать удобную сигнатуру вызова, чтобы передать туда параметры для конкретного экрана, а роутер же уже знает как открыть конкретный экран. Вместо того чтобы использовать navigateTo(ScreenName, params). Как Вам такой роутер? покритикуйте.
navigateToMainScreen(MainScreenArgs args);
navigateToProjectsScreen(ProjectScreenArgs args);
и т. д., т.е. смысл в том чтобы сделать удобную сигнатуру вызова, чтобы передать туда параметры для конкретного экрана, а роутер же уже знает как открыть конкретный экран. Вместо того чтобы использовать navigateTo(ScreenName, params). Как Вам такой роутер? покритикуйте.
Можно, но зачем? )
Это ж столько методов писать, а профит не очень то и большой как по-мне.
Плюс "найди 10 отличий":
navigateToSomeScreen(someScreenArgs)
navigateTo(someScreenName, someScreenArgs)
То есть все эти доп методы будут только ради того, чтобы вынести название экрана из метода.
Это ж столько методов писать, а профит не очень то и большой как по-мне.
Плюс "найди 10 отличий":
navigateToSomeScreen(someScreenArgs)
navigateTo(someScreenName, someScreenArgs)
То есть все эти доп методы будут только ради того, чтобы вынести название экрана из метода.
AP
Можно, но зачем? )
Это ж столько методов писать, а профит не очень то и большой как по-мне.
Плюс "найди 10 отличий":
navigateToSomeScreen(someScreenArgs)
navigateTo(someScreenName, someScreenArgs)
То есть все эти доп методы будут только ради того, чтобы вынести название экрана из метода.
Это ж столько методов писать, а профит не очень то и большой как по-мне.
Плюс "найди 10 отличий":
navigateToSomeScreen(someScreenArgs)
navigateTo(someScreenName, someScreenArgs)
То есть все эти доп методы будут только ради того, чтобы вынести название экрана из метода.
профит будет только в том, что нельзя будет что угодно передать в качестве аргументов, как это сейчас можно сделать с navigateTo т.к. аргументы там Object. Хм...
VC
А что за проблема с тем, что туда можно передать что угодно. Проверяй на входе, что это то что тебе надо. И ругайся если это не то что-то.
VC
Это вылезет в процессе разработки и проблем не будет.
VC
Это ж ты кидаешь туда аргументы, а не кто-то там.
AP
так-то да, видимо профита будет немного
IK
Можно, но зачем? )
Это ж столько методов писать, а профит не очень то и большой как по-мне.
Плюс "найди 10 отличий":
navigateToSomeScreen(someScreenArgs)
navigateTo(someScreenName, someScreenArgs)
То есть все эти доп методы будут только ради того, чтобы вынести название экрана из метода.
Это ж столько методов писать, а профит не очень то и большой как по-мне.
Плюс "найди 10 отличий":
navigateToSomeScreen(someScreenArgs)
navigateTo(someScreenName, someScreenArgs)
То есть все эти доп методы будут только ради того, чтобы вынести название экрана из метода.
смотри проще, идет логическое разделение аргументов и рецепиента, что весьма правильно
VC
смотри проще, идет логическое разделение аргументов и рецепиента, что весьма правильно
Поясни.
IK
А что пояснять то, идет разделение между аргументами, которые передаются рецепиенту, и идентификатором рецепиента
IK
SRP жи
VC
SRP тут вообще ни при чем.
VC
В методе navigateTo(someScreenName, someScreenArgs) они не смешаны. Отдельно получатель и отдельно аргументы.
KT
на данный момент есть несколько задуманных моментов:
1) все ключи экранов описываются в одном месте - это дает представление о карте прилодения.
2) Роутер в большинстве случаев трогать не надо
в предложенном случае для каждого перехода надо будет добавлять метод в роутер (а на экран мы можем попадать разными способами) - будет класс на тысячи строк
1) все ключи экранов описываются в одном месте - это дает представление о карте прилодения.
2) Роутер в большинстве случаев трогать не надо
в предложенном случае для каждого перехода надо будет добавлять метод в роутер (а на экран мы можем попадать разными способами) - будет класс на тысячи строк
VC
А вот если в роутер напихать методы типа navigateToSomeScreen, то принцип единой ответственности как раз будет нарушен.
VC
Потому что у рутера другая задача.