Как уменьшить связанность классов?

Question

[Anton Dyrkov]

Есть следующая структура классов.

Есть класс GraphParser который может как парсить граф в json , так и json парсить в граф, вопрос в следующем: чтобы создать граф в него нужно передать обьекты Point и Edge ,а чтобы создать Point нужно передать config и container в котором он будет отображаться и получается большая иньекция зависимостей в обьект, которому они не нужны, можно было бы вынести config и container в глобальную область видимости, но это лишь замаскирует проблему.

Есть какие нибудь шаблоны проектирования для данного случая , я знаю про фабрики, но должно быть что-то получше.

var parser = new JsonParser({config:Config,container:Container});
 var graph = new Graph({config:Config,container:Container,points:points,edges:edges,parser:parser});

Answer 1

[arTk_ev]

Поможет перестать мыслить плоско и использовать диаграмму классов. К проектированию все это не имеет отношение.
Прочитайте про декомпозицию систем, уроню декомпозиции, теория систем, SOLID.
Как я понял, вам нужно сделать модуль парсера.
Point, Edge, Graph - это не программные сущности, а просто структура данных без функционала. Им точно не нужен Container.
Parser - универсальный модуль, который может серилизовать и дессерилозвать, любые абстрактые данные. Его уже можно разбить на модули для записи и чтения файлов или на парсеры конкретных объектов.
Модули нижнего уровня декомпозиции не могут ссылать напрямую к модулях верхнего уровня. Все связи должны идти сверху-вниз. А вот уже на такой структуре можно применять инверсию зависимостей.

Comments

[arTk_ev]

https://habrahabr.ru/post/276593/
тут довольно просто все объясняется

Answer 2

[Adamos]

Точка не должна знать, какие у приложения настройки и в какой контейнер ее запихнули.
Это контейнер должен уметь выдать список того, что в него запихнули, а рендер - знать настройки.
Вы слишком много логики засунули внутрь классов, от которых требуется только хранение координат и пар (или списков) точек. Вот и мучаетесь теперь с ними.

Comments

[Anton Dyrkov]

в точку передается все настройки из них она берет свои настройки для отображения в Container, надо MVC фигарить

[Adamos]

Anton Dyrkov, если вы хотите уменьшить связность - избавляйтесь от классов, которые слишком о многом знают за пределами собственных данных. В первую очередь - от точек, которые сами себя отображают. Это откровеннейший антипаттерн.

Answer 3

[Mercury13]

1. Что такое Container и для чего он нужен? Возможно, от этого дела удастся избавиться или заменить интерфейсом?
2. Не должен конструктор Graph брать в параметры Parser. Наоборот, Parser функцией parse() должен возвращать Graph.
3. Config стоит разбить на несколько частей: одна специфична для Graph, вторая для Parser. Как их объединять — зависит от того, кому какие настройки нужны.

Comments

[Anton Dyrkov]

1 Container это обьект в котором отрисовывается точка, target - ссылка на этот рисунок точки
2 я специально через композицию вынес логику Parsera чтобы иметь больше гибкости и иметь возможность находу менять формат вывода - ввода Graph
3 Config согласен, лучше разделить его, но его все равно надо передавать в качестве зависимости классам, которые создают Point или Edge
скорее всего надо сделать фабричные методы в App и App сделать глобальным

[Mercury13]

Anton Dyrkov, В том, что Graph — единый неразрывный кусок, нет никаких проблем.

Штука у вас в том, что Parser ссылается на Graph, а Graph — на Parser. Не очень мне это нравится, и есть два варианта.
1. Вся функциональность по построению графа в Graph (а Parser выдаёт какой-то промежуточный код типа вызова callback’ов) — сделать интерфейс типа GraphSource.
2. Вся функциональность по построению графа в Parser — я уже говорил.