Answer the question
In order to leave comments, you need to log in
How to reduce class coupling?
There is the following class structure.
There is a GraphParser class that can both parse a graph into json and parse json into a graph, the question is this: to create a graph, you need to pass Point and Edge objects to it, and to create a Point, you need to pass config and container in which it will be displayed and it turns out a big dependency injection into an object that doesn't need them, one could move config and container to the global scope, but that would only mask the problem.
Are there any design patterns for this case, I know about factories, but there must be something better.
var parser = new JsonParser({config:Config,container:Container});
var graph = new Graph({config:Config,container:Container,points:points,edges:edges,parser:parser});
Answer the question
In order to leave comments, you need to log in
It will help to stop thinking flat and use the class diagram. All this has nothing to do with design.
Read about systems decomposition, drop decomposition, systems theory, SOLID.
As I understand it, you need to make a parser module.
Point, Edge, Graph are not programmatic entities, but just a data structure without functionality. They definitely don't need a Container.
Parser is a universal module that can serialize and desserialize any abstract data. It can already be broken down into modules for writing and reading files, or into parsers for specific objects.
Lower-level decomposition modules cannot link directly to higher-level modules. All links must go from top to bottom. But already on such a structure, you can apply dependency inversion.
The point should not know what settings the application has and in which container it was shoved.
This container should be able to give a list of what was stuffed into it, and the renderer should know the settings.
You've stuffed too much logic into classes that only need to store coordinates and pairs (or lists) of points. Now you are suffering with them.
1. What is a Container and what is it for? Perhaps it will be possible to get rid of this case or replace it with an interface?
2. The Graph constructor should not take Parser as parameters. Conversely, the Parser function of parse() must return a Graph.
3. Config should be divided into several parts: one is specific to Graph, the second to Parser. How to combine them depends on who needs what settings.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question