Исправления опечаток и запятых

Author: xcam

theory/Theory_article.md

@@ -80,14 +80,14 @@
 3. Есть несколько вариантов трактования понятия "Репозиторий". Подробно можно почитать, например, [здесь](http://hannesdorfmann.com/android/evolution-of-the-repository-pattern). В Андроид-мире "Репозиторий" - это абстракция для получения данных, то есть она скрывает, с какого именно источника получены те или иные данные. <br>
 Кроме того Репозиторий может внутри себя реализовывать логику кеширования данных и соответственно выдачи либо закешированных данных, либо данных с сети. 
 
-4. Дядюшка Боб говорит, что *Interactor*- это объект, реализующий *Use Case*. Более того, предлагается создавать их с помощью паттерна [Команда](https://refactoring.guru/ru/design-patterns/command). У нас же сложилась тенденция объединять различные пользовательские сценарии, связанные с одним функционалом, в отдельные классы - Use case feature facade. Вдобавок, многие использует в своих проектах RxJava, и мы получаем довольно лаконичный способ описания основного функционала. Были некоторые споры о том, должны ли такие классы называться в стиле "FeatureInteractor", или "FeatureInteractors" (во множественном числе), но больше прижился первый способ наименования.
+4. Дядюшка Боб говорит, что *Interactor*- это объект, реализующий *Use Case*. Более того, предлагается создавать их с помощью паттерна [Команда](https://refactoring.guru/ru/design-patterns/command). У нас же сложилась тенденция объединять различные пользовательские сценарии, связанные с одним функционалом, в отдельные классы - Use case feature facade. Вдобавок многие использует в своих проектах RxJava, и мы получаем довольно лаконичный способ описания основного функционала. Были некоторые споры о том, должны ли такие классы называться в стиле "FeatureInteractor", или "FeatureInteractors" (во множественном числе), но больше прижился первый способ наименования.
 
 5. Domain ничего не знает о других слоях. По классике к domain относятся Интеракторы и интерфейсы Репозиториев. Поэтому Интерактор не может являться маппером моделей. Мапперами моделей будут выступать Репозитории (из моделей data в модели domain и наоборот) и Презентеры (из моделей domain в модели View и наоборот).<br>
-Когда мы проектируем фичу и разрабатываем ее по слоям, то в отношении моделей нужно исходить все-таки из принципа минимализма. Если вы знаете, что для в рамках вашей фичи вам достаточно будет просто сходить в сеть и полученный результат отобразить на экране и ничего более, и такое поведение врят-ли когда-нибудь изменится, то на все слои вашей фичи лучше держать одну модель.<br>
+Когда мы проектируем фичу и разрабатываем ее по слоям, то в отношении моделей нужно исходить все-таки из принципа минимализма. Если вы знаете, что для вашей фичи вам достаточно будет просто сходить в сеть и полученный результат отобразить на экране и ничего более, и такое поведение вряд ли когда-нибудь изменится, то на все слои вашей фичи лучше держать одну модель.<br>
 Чаще бывает, когда полученный результат с сервера нам нужно немного подкорректировать, и уже можно отображать на экране. Тогда на фичу будет две модели (data и domain). <br>
 Ну и бывает, что по сути на каждый слой необходима своя модель (presentation, domain, data).
 
-6. Activity, Service, BroadcastReceivers - это точки входа в приложение, это служебные классы. Поэтому относить их к какому-либо конкретному слою в Архитектуре не верно. В тот же Service вы при необходимости можете и Интерактор инжектить, и Репозиторий.
+6. Activity, Service, BroadcastReceivers - это точки входа в приложение, это служебные классы. Поэтому относить их к какому-либо конкретному слою в Архитектуре неверно. В тот же Service вы при необходимости можете и Интерактор инжектить, и Репозиторий.
 
 7. В [видео 2016 года](https://www.youtube.com/watch?v=AlxMGxs2QnM&t=2509s&list=PLb1A91j1236pH1yoUvq5YDZUWAJz1T4DF&index=4) для Интерфейса Вьюшки много методов (setName, setAccountNumber, setCardNumber, setNearestDepartments). На самом деле все эти методы можно заменить на один типа setData, и в аргументы передавать какую-то специальную модельку.