Comments 9
Так ли нужна концепция разнесения классов по пакетам в соответствии с тем, чем является тот или иной класс? Т.е. вот в вашем примере, не проще ли положить CarView, CarPresenter, CarActivity в один пакет car. Ведь чаще всего их редактировать нужно вместе. Я понимаю, что есть рекомендации гугла по именованию пакетов, да и вообще «всегда так было». Но если бы их не было, то как ответите на мой вопрос?
Есть мысль, что стоит заводить отдельный пакет под Car, и в нём держать CarView, CarPresenter и CarViewModel. CarActivity стоит оставить в пакете activity. Этому есть несколько причин:
Мы (в arello :D )планируем в ближайшем времени попробовать такую структуру пакетов – может быть будет удобно. А может и нет – время покажет ;)
- Обычно для одного Presenter есть один конкретный View. И для этого удобно передавать во View не сырой объект Model, а уже обработанный ViewModel, который содержит в себе информацию, собранную из нескольких моделей. Таким образом мы соберем в одном месте всё, что нужно для Precenetr и View. Так же сюда можно будет, например, сложить уникальные StateStrategy для связки View Presenter
- Activity(равно как и Fragment) может содержать в себе несколько View. Поэтому чтобы не возникало путаницы, стоит всегда складывать их в пакет activity, fragment, etc
Мы (в arello :D )планируем в ближайшем времени попробовать такую структуру пакетов – может быть будет удобно. А может и нет – время покажет ;)
HotIceCream, складывать все в один пакет удобно до тех пор, пока приложение не разрастается. Представим, что к пакету car относятся 4 Fragment и Activity которое ими управляет. Это означает что в одном пакете будет лежать как минимум 15 классов.
Также непонятно куда складывать базовые классы для Presenter, Activty. По такой логике нам нужно создавать пакет base?
senneco, я уже пробовал раскладывать по логическим пакетам, в результате было не очень удобно. Если в пакет складывать только один экран, то получается слишком мелкое деление, а если несколько, то огород.
для data объектов мы используем отдельный пакет ui_data, в нем также сохраняется разбиение на пакеты
Также непонятно куда складывать базовые классы для Presenter, Activty. По такой логике нам нужно создавать пакет base?
senneco, я уже пробовал раскладывать по логическим пакетам, в результате было не очень удобно. Если в пакет складывать только один экран, то получается слишком мелкое деление, а если несколько, то огород.
для data объектов мы используем отдельный пакет ui_data, в нем также сохраняется разбиение на пакеты
Да, пакет base.
Можно раскладывать так, что в одном пакете может быть только 1 view (+ его fragment, presenter). Если в каком-то фрагменте могут содержаться другие фрагменты, то каждый из дочерних фрагментов (+ его view, presenter) лежит в пакете одного уровня с первым фрагментом. Т.е. группировать не по «темам», а по конкретным вьюхам.
Можно раскладывать так, что в одном пакете может быть только 1 view (+ его fragment, presenter). Если в каком-то фрагменте могут содержаться другие фрагменты, то каждый из дочерних фрагментов (+ его view, presenter) лежит в пакете одного уровня с первым фрагментом. Т.е. группировать не по «темам», а по конкретным вьюхам.
В результате на каждое Activity и Fragment будет свой пакет? В большом проекте в корневом пакете будет слишком много вложенных пакетов. Это осложнит навигацию.
Мы используем описанную иерархию. Она зарекомендовала себя как довольно практичная
В любом случае, разделение по пакетам советую делать так, как удобно Вам, т.к. единого мнения не существует
Мы используем описанную иерархию. Она зарекомендовала себя как довольно практичная
В любом случае, разделение по пакетам советую делать так, как удобно Вам, т.к. единого мнения не существует
Ну сейчас тренд как раз таки feature based packaging. Я пробовал и так и так — мне больше понравилось feature based подход. Навигация как раз таки упрощается, потому что почти всегда правка кода необходима только в 1ом пакете.
А у Вас все слои архитектуры в одном пакете? А общие классы куда-нибудь выносите? К примеру, если объект продукт нам понадобится и в каталоге и в корзине, то в какой пакет нам его поместить?
Нет, не все. Вот тут можно посмотреть как я сейчас делаю.
Сделал MVPActivity и MVPFragment шаблоны для MVP архитектуры, которую используют в ribot. Может кому пригодится.
Sign up to leave a comment.
MVP на стероидах: заставляем робота писать код за вас