Как организовать структуру модульных проектов?

Question

[Виталий]

Столько шумных статей о неграмотном использовании модульной системы... Вот к примеру, есть функции в классе, классы в локальных модулях, которые в свою очередь объединяются в модули публикуемые. Где границы этих масштабов? Т.е. как понять, где модуль оставлять локальным, где выносить глобально, а где сделать класс как часть другого модуля? Кроме этого, хотелось бы как-то упорядочить эти модули. Они конечно позволяют организовать пространство имён для внутренних функций и переменных, но сами захламождают пространство пакетов.

Answer 1

[Marat Amerov]

Для начала изучите SOLID принципы
https://scotch.io/bar-talk/s-o-l-i-d-the-first-fiv...

Comments

[Сергей Протько]

SOLID это хорошо, но у автора спутаны понятия "класс" и "модуль". Ну мол SOLID легко и просто объяснять на примере языков где есть явные интерфейсы. С модулями такая штука работает так же, но это надо постараться что бы спроэцировать такие вещи как "сегрегация интерфейсов" на модули.

К примеру... у нас есть модуль "bas64" и нам в одном месте надо только encode а в другом только decode. Согласно принципу сегрегации интерфейсов нам надо два интерфейса для этих двух операций (что бы связанность уменьшить), но с модулями так делать не очень удобно. С другой стороны модуль, который будет использовать наш, может импортировать только то, что ему нужно:

import {decode} from 'base64';

// magic

То же про инверсию зависимостей. Вместо "интерфейса" между двумя модулями у нас будет модуль-адаптер. А LSP вообще не поможет автору понять в чем соль, это больше о типах данных, о том что инварианты типов надо усиливать в наследниках... Ну то есть... ни слова про модули.

Тут больше в сторону структурного программирования стоит ковырять.

[Виталий]

Вопрос направлен конкретно на модульную систему node.js

[Виталий]

Сергей Протько: Кстати, похоже что вы используете TypeScript. Может желаете заглянуть на огонёк в не менее острый вопрос?
TypeScript для Node.js — как настроить для совместной работы?

[Сергей Протько]

Виталий: я пока не использую typescript, и в целом мало на ноде пишу.

Answer 2

[Сергей Протько]

Найдите баланс между Coupling и Coheasion.

Забудьте о классах и будет проще. Тогда все - модули. Приложение - модуль. Оно состоит из других модулей. Те используют другие модули и так далее организуем иерархию модулей. Классы это просто способ создания новых типов данных, для организации кода оно используется только в языках, где нет модулей (не ООП, а просто структурная единица кода, как в C++ например).

Они конечно позволяют организовать пространство имён

Пространства имен нужны тогда, когда все лежит в глобальной области видимости. Когда все существует в контексте модулей оно не нужно. У вас и так есть изоляция необходимая.

Вся задача сводится к тому, чтобы максимально порезать систему таким образом, чтобы полностью контролировать кому что доступно и кто чем пользуется. Декомпозиция в чистом виде, ну и инкапсуляция.

Comments

[Виталий]

Цитата не на том акцентируется, важнее - что со временем пакеты захламождают пространство пакетов. Как быть с этим?

[Виталий]

И строго говоря, я могу по одному классу выносить в каждый модуль, просто потому что это тип данных, который может использоваться где-то ещё.

[Сергей Протько]

Виталий: у вас нет пакетов. О чем речь вообще? И что значит "захламляют"? В модулях должно быть только то что надо. Если вы о том как группировать модули по "папкам" (ибо вы вообще можете все линейно организовывать), это тут опять же смотреть насколько модули "coheasive" между собой, ну то есть насколько им положено лежать рядом, насколько у них схожи задачи и т.д.

[Сергей Протько]

Виталий: вы опять зациклились на классах. Классы нужны в JS nолько для того, что бы создать новый тип данных. Именно данных. Логика пусть лежит просто в функциях, меньше проблем будет.

p.s. Признавайтесь из какого языка программирования вы пришли в JS?