EK
все классы реализуют общий интерфейс?
ну, не совсем, они каждый отвечает за свою часть логики, которая не пересекается никак
Size: a a a
2020 July 24
Вキ
ну, не совсем, они каждый отвечает за свою часть логики, которая не пересекается никак
а интерфейс общий?
EK
а интерфейс общий?
нет, один класс это пагинация, другой - сортировки, следовательно набор методов разный совершенно
EK
третий вообще с данными работает и отвечает за преобразования
Вキ
сделать общий интерфейс сможешь?
EK
сделать общий интерфейс сможешь?
не думаю... не могу представить как это все в общий засунуть, чтобы сохранить single responsibility... Ну, как вариант, FooController, который над ними, это один из вариантов общего интерфейса для них, типа фасада) но это не то...
Вキ
не думаю... не могу представить как это все в общий засунуть, чтобы сохранить single responsibility... Ну, как вариант, FooController, который над ними, это один из вариантов общего интерфейса для них, типа фасада) но это не то...
так наоборот, single responsibility будет лучше, если будет общий интерфйс для всех
EK
так наоборот, single responsibility будет лучше, если будет общий интерфйс для всех
тогда, я возможно не очень понимаю о чем ты говоришь)
EK
может на примере Foo Bar каком-нибудь?)
Вキ
можно
IB
Ребят, всем привет. Есть вопрос, на который не могу придумать решение, которое меня устроило бы..
Есть компонент. Он довольно сложный, у него много логики, которая изначально была вынесена в отдельные классы через фасад.
При создании компонента и передачи ему в Input параметра config создавался главный класс FooController на схеме и он в свою очередь инициализировал остальные Special Controllers передавая им их части конфига.
В случае, когда в input компонента приходил новый config, то можно было просто заново инициализировать класс FooController и все начиналось с чистого листа. Т.е. все состояния классов автоматически сбрасывались, т.к. создавались новые инстансы.
У этого подхода была проблема в том, что классы были не Injectable и не могли в себя включать какие-то зависимости, например Router, MatDialog и иже с ними. Получалось так, что FooController был таким вот передастом, который принимал все что нужно аж от компонента и распихивал по дочерним классам, следовательно приобретая совершенно не нужн
Есть компонент. Он довольно сложный, у него много логики, которая изначально была вынесена в отдельные классы через фасад.
При создании компонента и передачи ему в Input параметра config создавался главный класс FooController на схеме и он в свою очередь инициализировал остальные Special Controllers передавая им их части конфига.
В случае, когда в input компонента приходил новый config, то можно было просто заново инициализировать класс FooController и все начиналось с чистого листа. Т.е. все состояния классов автоматически сбрасывались, т.к. создавались новые инстансы.
У этого подхода была проблема в том, что классы были не Injectable и не могли в себя включать какие-то зависимости, например Router, MatDialog и иже с ними. Получалось так, что FooController был таким вот передастом, который принимал все что нужно аж от компонента и распихивал по дочерним классам, следовательно приобретая совершенно не нужн
Похоже что тут фраза по середине оборвалась)
EK
EK
У этого подхода была проблема в том, что классы были не Injectable и не могли в себя включать какие-то зависимости, например Router, MatDialog и иже с ними. Получалось так, что FooController был таким вот передастом, который принимал все что нужно аж от компонента и распихивал по дочерним классам, следовательно приобретая совершенно не нужные ему зависимости.
Было решено сделать ВСЕ классы Injectable, тем самым они все создавались вместе с компонентом, а в момент установки конфига у них был метод setConfig, его как и прежде вызывал FooController для каждого класса со своей частью конфига. При этом FooController перестал быть передастом и избавился от лишних пробросов зависимостей.
Новая проблема: В случае обновления Input config в компоненте - нужно как-то сбросить состояния классов.
Потенциальное решение номер 1: у каждого класса есть метод типа reset(), который сбрасывает все переменные состояния до дефолтных.
Потенциальное решение номер 2: вынести состояния из всех классов в подобие стора по группам, следовательно в момент, когда нужно сбросить состояние - просто инициализируем дефолтное состояние для группы в сторе
Потенциальное решение номер 3: не использовать для дочерних Injectable и оставить передастом FooController...
Было решено сделать ВСЕ классы Injectable, тем самым они все создавались вместе с компонентом, а в момент установки конфига у них был метод setConfig, его как и прежде вызывал FooController для каждого класса со своей частью конфига. При этом FooController перестал быть передастом и избавился от лишних пробросов зависимостей.
Новая проблема: В случае обновления Input config в компоненте - нужно как-то сбросить состояния классов.
Потенциальное решение номер 1: у каждого класса есть метод типа reset(), который сбрасывает все переменные состояния до дефолтных.
Потенциальное решение номер 2: вынести состояния из всех классов в подобие стора по группам, следовательно в момент, когда нужно сбросить состояние - просто инициализируем дефолтное состояние для группы в сторе
Потенциальное решение номер 3: не использовать для дочерних Injectable и оставить передастом FooController...
EK
хорошо, что я параноик и копирую ))))))))
EK
я сейчас попробую образно набросать в классах это
Вキ
может на примере Foo Bar каком-нибудь?)
Знаком с Interceptor pattern?
EK
Знаком с Interceptor pattern?
в теории да, но не могу наложить его на задачу что-то
Вキ
в теории да, но не могу наложить его на задачу что-то
почему?
EK
почему?
ну как раз в его случае мне нужен будет единый интерфейс, так?