Так и есть. Просто в этом случае у нас возникает очень сложно отслеживаемая ошибка, особенно когда в validate есть побочные эффекты.
А вообще получается довольно гибкая вещь. Валидаторы можно склеивать тоже лениво, например так:
Validate1().Union(Validate2())
А затем, если мы вдруг решим аггрегировать не все ошибки, а только первую, или первые n то код валидаторов останется тот же. Достаточно будет добавить к результату .Take(1)
А ничего что IEnumerable обрабатывается лениво?
Если код вызывающий Validate не будет делать force (явно проходить по коллекции ошибок) то метод не будет выполняться даже если по логике он проходит всю валидацию?
Не совсем понял фразу по поводу того, что Store не хранит свое состояние.
Т.е. вы используете Store как абстракцию, чтобы делать запросы к серверу? Честно говоря интересный подход :)
Но во всех презентациях и примерах от Facebook Store хранит состояние (да и само название как бы намекает)
When a user interacts with a React view, the view propagates an action through a central dispatcher, to the various stores that hold the application's data and business logic, which updates all of the views that are affected.
Но ваша интерпретация Flux очень интересная. А поясните пожалуйста, пример про 5 запросов от разных компонентов.
Я так понимаю, что у вас используется что то вроде Promise?
Store – это далеко не модель. Модель, насколько мне известно, хранит образ сущности, например объект «Пользователь» с полем Name, Age и т.д.
То, что вы описываете называется пассивной моделью. В классическом MVC канонической принято считать моделью то как вы организовали Store.
На самом деле в какой-то статье читал, что в самом Facebook есть сторонники обоих подходов
Да после 100 страницы только начинается самое интересное. Помню как читал взахлеб по ночам.
Только после этого можно в полной мере оценить всю гениальность первой части.
Единственное, часть про написание интерпретатора пропустил, но сейчас пишу его по другой статье на хаскеле.
После прочтения книги больше всего был поражен, что с момента ее написания (80-ые) больших зачимых достижений в программировании не было. На самом деле только сейчас многие идеи из книги начинают популяризироваться
В том то и дело что создать папочку тут не достаточно )
Взять тот же пример из статьи. У нас есть класс A, к-ый используется классами B, C, D. Причем каждый этот класс использует только 1 метод из класса А, допустим b, c и d соответственно.
Не парясь о тестируемости мы бы просто реализовали интерфейс IA состоящий из методов b,c,d (а скорее всего даже его и не реализовывали).
Но чтобы сделать его тестируемым нам нужно выделить еще 3 интерфейса: IAforB, IAforC, IAforD с соответствующими методами.
Тут уже можно увидеть закономерность, что кол-во сущностей у нас уже удвоилось.
А вот вам еще один случай, у нас появляется новый класс E, которому нужно 2 метода: b и с, или новый метод e. Что мы теперь будем делать?
А что тут думать. Интерфейсы нужны как точки расширения системы, например вон через USB можно подключать как мышь, так и клавиатуру и много чего еще изначально чего не планировалось в системе иметь.
Проблема тут в другом, что тестируя все модули и выделяя для каждого из них свой интерфейс может получиться настолько абстрактный монстр, что вместе с DI никто уже толком не сможет разобраться что в системе происходит и для чего она вообще создавалась.
Вообще добавление тестирования к системе это большой такой + к затратам и что более важно сложности системы.
High Cohesion, или высокая связность говорит о том, что внутри модуля весь функционал согласован и сфокусирован на решении какой-то узкой проблемы. Это значит, что при правильном проектировании модули получаются компактными и понятными, не содержат «лишнего» кода и побочных эффектов.
Какой-то не очевидный вывод. Каким образом высокая связность вообще связана с побочными эффектами?
Если строго подходить к вопросу, то если ваш модуль имеет высокую связность, то все его функции(методы, классы) интенсивно используют друг друга. При этом компактность и понятность также не гарантируются.
ViewModel и умный компонент не одно и тоже.
ViewModel вообще не знает про View. View использует ViewModel. (можно иметь очень много View для одного и того же ViewModel)
В React связь обратная — умные компоненты управляют глупыми. Тут более очевидно сравнение с Controller. (вы уже не можете иметь много представлений, для каждого из них вам придется писать свой умный компонент)
Видимо мы о разном говорим )
Я так понимаю реактивные системы, к-ые вы упоминаете здесь — это «быстрореагирующие» системы.
Я же имел в виду вот это Реактивное программирование
Так мой первоначальный вопрос как раз и был о том как реактивное программирование реализовано в акторах :)
Я если честно, вообще не знаком с понятием «реактивная модель».
Как мне кажется, я как раз и описал общую концепцию реактивного программирования своими словами.
На практике же существует несколько подходов в ее реализации: FRP например.
Если не сложно опишите что такое «реактивная модель» и с какими вы знакомы
Для меня реактивное программирование это программирование построенное на инвариантах (если конечно правомерно так выразиться).
Переменные образуют граф из этих инвариантов (зависимостей). Любое изменение значения переменной из этого графа вызывает его пересчет. Таким образом значение переменных всегда находиться в консистентном (не противоречивом по отношению к инвариантам) состоянии.
Книгу я не читал, поэтому и задал вопрос.
Событийная архитектура еще не означает реактивность, в том числе как реактивность не обязательно должна быть реализована при помощи событий.
Что только не придумают лишь бы не использовать ангуляр.
Можно подумать, что ангуляр пуп земли.
Обычно такое высказывание свидетельствует об ограниченном кругозоре и скорее знакомство автора с reactJs свелось к беглому просмотру примеров на главной странице
Поделюсь своим видением Flux. Для меня это один из вариантов реализации классического MVC паттерна (к-ый используется в ASP.NET MVC а не двусторонние байндинги и т.п.) где
Store = Model
Action = Controller
View = React Components
С точки зрения MVC Controller должен синхронизировать Model с внешними источниками данных. Model про них вообще ничего не должна знать. Поэтому я бы общение с внешним API поместил в Controller (Action)
А вообще получается довольно гибкая вещь. Валидаторы можно склеивать тоже лениво, например так:
Validate1().Union(Validate2())А затем, если мы вдруг решим аггрегировать не все ошибки, а только первую, или первые n то код валидаторов останется тот же. Достаточно будет добавить к результату
.Take(1)Если код вызывающий Validate не будет делать force (явно проходить по коллекции ошибок) то метод не будет выполняться даже если по логике он проходит всю валидацию?
Т.е. вы используете Store как абстракцию, чтобы делать запросы к серверу? Честно говоря интересный подход :)
Но во всех презентациях и примерах от Facebook Store хранит состояние (да и само название как бы намекает)
Но ваша интерпретация Flux очень интересная. А поясните пожалуйста, пример про 5 запросов от разных компонентов.
Я так понимаю, что у вас используется что то вроде Promise?
То, что вы описываете называется пассивной моделью. В классическом MVC канонической принято считать моделью то как вы организовали Store.
На самом деле в какой-то статье читал, что в самом Facebook есть сторонники обоих подходов
Только после этого можно в полной мере оценить всю гениальность первой части.
Единственное, часть про написание интерпретатора пропустил, но сейчас пишу его по другой статье на хаскеле.
После прочтения книги больше всего был поражен, что с момента ее написания (80-ые) больших зачимых достижений в программировании не было. На самом деле только сейчас многие идеи из книги начинают популяризироваться
Взять тот же пример из статьи. У нас есть класс A, к-ый используется классами B, C, D. Причем каждый этот класс использует только 1 метод из класса А, допустим b, c и d соответственно.
Не парясь о тестируемости мы бы просто реализовали интерфейс IA состоящий из методов b,c,d (а скорее всего даже его и не реализовывали).
Но чтобы сделать его тестируемым нам нужно выделить еще 3 интерфейса: IAforB, IAforC, IAforD с соответствующими методами.
Тут уже можно увидеть закономерность, что кол-во сущностей у нас уже удвоилось.
А вот вам еще один случай, у нас появляется новый класс E, которому нужно 2 метода: b и с, или новый метод e. Что мы теперь будем делать?
Проблема тут в другом, что тестируя все модули и выделяя для каждого из них свой интерфейс может получиться настолько абстрактный монстр, что вместе с DI никто уже толком не сможет разобраться что в системе происходит и для чего она вообще создавалась.
Вообще добавление тестирования к системе это большой такой + к затратам и что более важно сложности системы.
Какой-то не очевидный вывод. Каким образом высокая связность вообще связана с побочными эффектами?
Если строго подходить к вопросу, то если ваш модуль имеет высокую связность, то все его функции(методы, классы) интенсивно используют друг друга. При этом компактность и понятность также не гарантируются.
ViewModel вообще не знает про View. View использует ViewModel. (можно иметь очень много View для одного и того же ViewModel)
В React связь обратная — умные компоненты управляют глупыми. Тут более очевидно сравнение с Controller. (вы уже не можете иметь много представлений, для каждого из них вам придется писать свой умный компонент)
Я так понимаю реактивные системы, к-ые вы упоминаете здесь — это «быстрореагирующие» системы.
Я же имел в виду вот это Реактивное программирование
Я если честно, вообще не знаком с понятием «реактивная модель».
Как мне кажется, я как раз и описал общую концепцию реактивного программирования своими словами.
На практике же существует несколько подходов в ее реализации: FRP например.
Если не сложно опишите что такое «реактивная модель» и с какими вы знакомы
Переменные образуют граф из этих инвариантов (зависимостей). Любое изменение значения переменной из этого графа вызывает его пересчет. Таким образом значение переменных всегда находиться в консистентном (не противоречивом по отношению к инвариантам) состоянии.
Событийная архитектура еще не означает реактивность, в том числе как реактивность не обязательно должна быть реализована при помощи событий.
Можно подумать, что ангуляр пуп земли.
Обычно такое высказывание свидетельствует об ограниченном кругозоре и скорее знакомство автора с reactJs свелось к беглому просмотру примеров на главной странице
Store = Model
Action = Controller
View = React Components
С точки зрения MVC Controller должен синхронизировать Model с внешними источниками данных. Model про них вообще ничего не должна знать. Поэтому я бы общение с внешним API поместил в Controller (Action)