S0ER

Вопросы с подвохом, которые могут задать на систем-дизайн интервью.

На интервью по системному дизайну есть пара вопросов с подвохом, которые неплохо знать. Первый — это знать, в чем разница между "связностью" и "связанностью". Тут легко решить проблему, используя слова "когезия" и "зацепление". Другой вопрос — разница между модулем и компонентом.

Есть общее представление, что компонент отражает функциональную суть задачи, а модуль — структурную. То есть компонент показывает "что будет делать система?", а модуль — "как она это будет делать?".

Проблемы начинаются, когда задается вопрос о подчинении этих двух понятий по отношению друг к другу. Кажется, что раз компонент отвечает за функцию, а модуль за структуру, то компонент должен декомпозироваться через модули (грубо говоря, "компонент включает модули"). Логично, но ломается на примере UI-компонентов: ведь условная функциональная единица интерфейса "кнопка" — очевидно, является компонентом, но мы знаем кучу примеров, когда подобные компоненты включаются в один модуль. Получается, что нарушается принцип подчинения "от общего к частному".

На самом деле эта неточность легко разрешается, если мы введем два уровня архитектуры:
1. "Уровень приложения", где компонент ведет себя согласно закону "от общего к частному".
2. "Уровень кода", где компонент, наоборот, ведет себя "от частного к общему".

Зачем это надо на практике? Это помогает уменьшить количество противоречий и "сюрпризов" на этапе документирования (а потом и реализации) системы и, соответственно, правильно определить границы модулей и компонентов для более точного разделения обязанностей.

👍3187❤4👎1🔥1👀1😎1

www.tgoop.com/softwareengineervlog/2328

8.18K viewsJul 23 at 03:47

Вопросы с подвохом, которые могут задать на систем-дизайн интервью.

На интервью по системному дизайну есть пара вопросов с подвохом, которые неплохо знать. Первый — это знать, в чем разница между "связностью" и "связанностью". Тут легко решить проблему, используя слова "когезия" и "зацепление". Другой вопрос — разница между модулем и компонентом.

Есть общее представление, что компонент отражает функциональную суть задачи, а модуль — структурную. То есть компонент показывает "что будет делать система?", а модуль — "как она это будет делать?".

Проблемы начинаются, когда задается вопрос о подчинении этих двух понятий по отношению друг к другу. Кажется, что раз компонент отвечает за функцию, а модуль за структуру, то компонент должен декомпозироваться через модули (грубо говоря, "компонент включает модули"). Логично, но ломается на примере UI-компонентов: ведь условная функциональная единица интерфейса "кнопка" — очевидно, является компонентом, но мы знаем кучу примеров, когда подобные компоненты включаются в один модуль. Получается, что нарушается принцип подчинения "от общего к частному".

На самом деле эта неточность легко разрешается, если мы введем два уровня архитектуры:
1. "Уровень приложения", где компонент ведет себя согласно закону "от общего к частному".
2. "Уровень кода", где компонент, наоборот, ведет себя "от частного к общему".

Зачем это надо на практике? Это помогает уменьшить количество противоречий и "сюрпризов" на этапе документирования (а потом и реализации) системы и, соответственно, правильно определить границы модулей и компонентов для более точного разделения обязанностей.

BY S0ER