Здравствуйте, Елена! Не могли бы вы записать ролик про необходимые знания для того или иного уровня должности (от стажера до сеньора)? Прошу вас упомянуть не только необходимый список знаний, но и меру углубленности в эти знания. Спасибо!
2:51 Не совсем понял этот момент. Если у нас есть посредник в виде фасада, то клиент стучится в него. А фасад стучится в логику. Получается, мы имеем посредника в виде фасада? Или это предполагает косвенные импорты? Когда мы импортируем на потребителе бизнес-логику не напрямую, а фасад, который выдаёт публичное апи движка. Туда же можно параметрами давать адаптеры , которые сделают соответствие типов. И часть методов, которые можно вызывать внутри (условно декораторы для конкретных методов) Про то, как расширять, как делать систему более гибкой с помощью фасада
2:04 Получается, фасад - это просто публичное апи? Например, есть какой-нибудь движок рендера формы. Конфиги, компоненты UI, локальное хранилище - всё внутри. Потребителю выдаётся только вьюшка (ответ на вопрос, что рендерить) и набор данных + методов для реактивщины, нужных для взаимодействия с вьюшкой. То есть, вместо десятков конструкций, мы даём только вьюшку и сервис к этой вьюшке. Не нашёл про джаву, но на тайпскрипте это делается как `export { Engine } from './engine';`
view генерируется на фронте Фасад, как по мне напоминает контроллер для работы с нашими API, в которых мы передаем необходимую информацию для отображение на стороне Front
@@kxeklom не, это всё на фронте делается в моём примере. Ну конфиг приходит с бэка. Но там примитивно всё? Достать коллекцию по паре sql запросам - несложно. Фасад там не нужен)
Кроме фасада важны декоратор, мост, фабрика с адаптером, наблюдатель. Но чем отличается фасад от моста, если оба - про разделение абстракции выше-ниже? Оба урезают интерфейс взаимодействия, вводят ограничения в виде публичной апишки...
Использовать ключевое слово "this", в конструкторе класса, где он не принимает никаких параметров, не имеет никакого практического смысла, "this" нужен для того, чтобы указать, какое конкретно мы используем поле, если метод/конструктор имеет одноименные параметры. 7:37
А что тут не так с SRP? Каждый из трех сервисов внутри имеет ответственность над своим функционалом. Фасад объединяет функционал этих сервисов по доменному принципу. Он не забирает ответственность за реализацию с других сервисов, не изменяет их функционал. Его область ответственности это предоставление интерфейсов, связанных с банкингом, наружу
спасибо за фасад ! ждем фундамент !
Здравствуйте, Елена! Не могли бы вы записать ролик про необходимые знания для того или иного уровня должности (от стажера до сеньора)? Прошу вас упомянуть не только необходимый список знаний, но и меру углубленности в эти знания. Спасибо!
Спасибо, что как для самых маленьких объяснили =)
Елена, большое спасибо за видео!
Материал очень легко подается :)
Лена, ты молодец! Приятно слушать ТОП преподавателя!
Елена, хочу сказать спасибо за шуточки, которые вы вставляете в свои видео) С ними изучение Java уже не кажется таким сложным!
2:51 Не совсем понял этот момент. Если у нас есть посредник в виде фасада, то клиент стучится в него. А фасад стучится в логику. Получается, мы имеем посредника в виде фасада? Или это предполагает косвенные импорты? Когда мы импортируем на потребителе бизнес-логику не напрямую, а фасад, который выдаёт публичное апи движка.
Туда же можно параметрами давать адаптеры , которые сделают соответствие типов. И часть методов, которые можно вызывать внутри (условно декораторы для конкретных методов)
Про то, как расширять, как делать систему более гибкой с помощью фасада
2:04 Получается, фасад - это просто публичное апи? Например, есть какой-нибудь движок рендера формы. Конфиги, компоненты UI, локальное хранилище - всё внутри.
Потребителю выдаётся только вьюшка (ответ на вопрос, что рендерить) и набор данных + методов для реактивщины, нужных для взаимодействия с вьюшкой.
То есть, вместо десятков конструкций, мы даём только вьюшку и сервис к этой вьюшке.
Не нашёл про джаву, но на тайпскрипте это делается как `export { Engine } from './engine';`
view генерируется на фронте
Фасад, как по мне напоминает контроллер для работы с нашими API, в которых мы передаем необходимую информацию для отображение на стороне Front
@@kxeklom не, это всё на фронте делается в моём примере. Ну конфиг приходит с бэка. Но там примитивно всё? Достать коллекцию по паре sql запросам - несложно. Фасад там не нужен)
Можно ли сказать, что эндпоинт - частный случай фасада?
Кроме фасада важны декоратор, мост, фабрика с адаптером, наблюдатель. Но чем отличается фасад от моста, если оба - про разделение абстракции выше-ниже? Оба урезают интерфейс взаимодействия, вводят ограничения в виде публичной апишки...
Паттерны - фабрика, абстрактная фабрика, Proxy
Чем отличается "Интерфейс" от "Фасада"?
Звучит так, что этот паттерн = декларативная функция. Плюс инкапсуляция. Плюс разделение на публичное и приватное апи (доступное для класса/пакета)
Использовать ключевое слово "this", в конструкторе класса, где он не принимает никаких параметров, не имеет никакого практического смысла, "this" нужен для того, чтобы указать, какое конкретно мы используем поле, если метод/конструктор имеет одноименные параметры.
7:37
Single Responsibility - не, не слышала...
А что тут не так с SRP? Каждый из трех сервисов внутри имеет ответственность над своим функционалом. Фасад объединяет функционал этих сервисов по доменному принципу. Он не забирает ответственность за реализацию с других сервисов, не изменяет их функционал. Его область ответственности это предоставление интерфейсов, связанных с банкингом, наружу