Исправлены опечатки в Practice_article.md

Author: osipxd

practice/Practice_article.md

@@ -125,7 +125,7 @@ https://martinfowler.com/bliki/CQRS.html<br>
 -------OperationsRubNetworkModel<br>
 -------OperationCurrNetworkModel<br>
 
-Разбивать только по слоям или фичам невсегда бывает удобно, поэтому гибридный вариант, когда внутри одного пакета слоя могут быть пакеты с фичами, вполне приемлим.<br>
+Разбивать только по слоям или фичам не всегда бывает удобно, поэтому гибридный вариант, когда внутри одного пакета слоя могут быть пакеты с фичами, вполне приемлим.<br>
 
 Иногда проект разбивают на модули, чаще всего делаю отдельный модуль для каждого слоя приложения. <br>
 
@@ -178,8 +178,8 @@ Dagger 2 имеет следующие преимущества перед "ру
     modeRepository.getMode()
         .flatMap(mode -> operationsRepository.getOperations(mode))
 
-Исходя из вышесказанного Репозиторий должен тестироваться.<br>
-Если вам нужно сделать приложение быстро, можно, конечно, не заморачиваться с маппингом, а передавать модель, полученную с запроса. Но если приложение чуть более серьезное и долгое, то лучше маппить. Так как по опыту, по Дате-уровне или по логике получения данных всегда что-то может поменяться. Бизнес-логика про это вообще не должна знать.<br>
+Исходя из вышесказанного, Репозиторий должен тестироваться.<br>
+Если вам нужно сделать приложение быстро, можно, конечно, не заморачиваться с маппингом, а передавать модель, полученную с запроса. Но если приложение чуть более серьезное и долгое, то лучше маппить. Так как по опыту, в Дата-уровне или в логике получения данных всегда что-то может поменяться. Бизнес-логика про это вообще не должна знать.<br>
 
 #repository #designpatterns<br>
 
@@ -233,7 +233,7 @@ geoApiProvider - это специальный класс, которому мы
 
 **Проблема**<br>
 
-Хранение данных в рантайме.  Если нужно хранить какие-то состояния, но ложить их в БД или SP нет необходимости. А где мне следует хранить данные, которые должны жить только в рантайме? Т.е. допустим, у меня приложение не кэширует что-то в бд. Получает данные и хранит пока приложение живо. У меня есть репозиторий, в нем по сути ретрофит, который берет данные из сети. Репозиторий сделал на случай если бд в дальнейшем понадобится, то будет удобно делать выборку из бд или сети в репозитории. А данные которые, хранятся в рантайме я тоже в репозитории хранить должен или какой-то манагер данных должен быть, в которого складываются данные из сети?<br>
+Хранение данных в рантайме.  Если нужно хранить какие-то состояния, но класть их в БД или SP нет необходимости. А где мне следует хранить данные, которые должны жить только в рантайме? Т.е. допустим, у меня приложение не кэширует что-то в бд. Получает данные и хранит пока приложение живо. У меня есть репозиторий, в нем по сути ретрофит, который берет данные из сети. Репозиторий сделал на случай если бд в дальнейшем понадобится, то будет удобно делать выборку из бд или сети в репозитории. А данные которые, хранятся в рантайме я тоже в репозитории хранить должен или какой-то манагер данных должен быть, в которого складываются данные из сети?<br>
 
 **Решение**<br>
 
@@ -251,7 +251,7 @@ Persistence данные должны быть всегда сокрыты по
 **Решение**<br>
 
 Можно реализовать интерактор по паттерну Фасад. Данный интерактор будет уже дергать соответствующие вспомогательные классы. И интерфейс бизнес-логики у нас будет единым, что очень удобно при дальнейшем сопровождении. <br>
-По опыту одного из админов. В своё была задачи встроить чат в одно банковское приложение. И там было очень много логики. Но так как это одна бизнес-фича, то был сделалан один Интерактор по Фасаду. В имплементации он по сути просто дергал вспомогательные классы. Написаны были ещё некоторые функциональные тесты. И вот спустя 9 месяцев руководство для реализации чата решило использовать не стороннюю либу, а свою. А это другой интерфейс и вообще другая логика отправки сообщений и прослушки входящих. Просто подменой data уровня не спастись было поэтому. Но ui тот же остаётся. <br>
+По опыту одного из админов. Была задача встроить чат в одно банковское приложение. И там было очень много логики. Но так как это одна бизнес-фича, то был сделалан один Интерактор по Фасаду. В имплементации он по сути просто дергал вспомогательные классы. Написаны были ещё некоторые функциональные тесты. И вот спустя 9 месяцев руководство для реализации чата решило использовать не стороннюю либу, а свою. А это другой интерфейс и вообще другая логика отправки сообщений и прослушки входящих. Поэтому просто подменой data уровня было не спастись. Но ui тот же остаётся. <br>
 И вот тогда действительно сыграло на руку такое решение с интерактором. Была просто произведена подмена Интерактора без затрагивания View и Presenters, где было тоже немало всего. И оно заработало с первого раза =)<br>
 
 #facade #interactor #designpatterns<br>