Javascript classes, but more a design question

Trying to figure out a design for this:

I have a class Grid.

I want to make points relative to a Grid instance (there will be only one instance of Grid). Relative means the point coordinates will change accordingly to changes made in grid.

To build a new point I need access to data in Grid instance so I can make the proper calculations.
Also each instance point must retain a unique data referent to the state of a Grid property at the moment the point was built.

I thought in some possible approaches.

  1. Make the points and store them inside Grid class. In a collection of some kind, or an object. Thatā€™s ok, but not very beautiful and ā€˜oopyā€™ I think. The Grid class will be doing to much things, and the work to keep track of each point will be convoluted. There will be a lot ways to create a point, they must be updated every cycle, and do some other stuff, so the class will be like ā€œpollutedā€.

  2. Make a sub class Gpoint, extending Grid. But then, iā€™ll have to provide the instance of Grid to every point, right? A constructor like constructor(Grid, x, y) If so, doesnā€™t it makes extending useless?

  3. Make a class like Gpoints (plural) that gets an instance of Grid (the instance), and deal with storing all the points. Then make GPoint that extends Gpoints class and use super(Grid) to get a ref to the Grid instance.

Well, all that still not seems very good an answer yetā€¦

Please advise : )

thanks.

ps:

here a skeleton iā€™m working with

	class Gpoints {

	    constructor(Grid) {
	        this.grid = Grid;
	        this.Gpoints = [];
	    }

	    make_gpoint(x, y, label){

	    	let gp = new Gpoint(x, y, label);
	    	this.Gpoints.push(gp);
	    }

	} //class


	class Gpoint extends Gpoints {
	    constructor(x, y, label) {
	    	super(grid);
	        this.x = x;
	        this.y = y;
	        this.gx;
	        this.gxy; 
	        this.label = label;
	        this.g_width;
	    }





	}//class

and then something like:

    gps = new Gpoints(grid);
    gp1 = gps.make_gpoint(100, 100, 'gp1');
1 Like

Not sure what youā€™re trying to accomplish, but the following code creates a grid of points (or can be adapted to draw about any shape you like).

let _numRows = 60;
let _numCols = 60;

function pointGrid(left, top, ptSize, colGap, rowGap) {
  for(let k = 0; k < _numRows; k++) {
    for(let j = 0; j < _numCols; j++){
      let x = left + j*(colGap);
      let y = top + k*(rowGap);
      stroke(0,0,255);
      strokeWeight(2.0);
      circle(x,y,ptSize);
    }
  }
 }

function setup() {
  createCanvas(630, 630);
  background(209);
  pointGrid(20, 20, 2, 10, 10);
}

function draw() {
}

Thanks @svan. Great example.
Actually my question is more of conceptual nature, about designing the inheritance chain. As Iā€™m working Iā€™m starting to think that perhaps the best is to keep the ā€œstorageā€ inside the grid class. But Iā€™m not sure yet : )
Anyway thanks for your time :slight_smile:

cheers

I donā€™t know if it will help you or not, but it is possible to use the code that I posted to display an array of objects with a unique id assigned to each object. When using mousePressed() the id may be retrieved.

1 Like

I think you are overthinking.

No ā€œextendsā€ required.

Just make a class Point to store the data. You can (but donā€™t have to) make a class Grid to work with the points.

1 Like

Thanks @Chrisir I think you are right, as I mentioned above. Overthinking I am.

Iā€™m of same opinion as @Chrisirā€™s.

That is, have a Point class plus a Grid class to manage the instances of Point.

I did the same for this sketch ā€œSelf Avoiding Walk IIā€:

In its subfolder ā€œmodules/ā€ there are 3 JS files (plus 3 CoffeeScript files :coffee: ):

  1. https://Self-Avoiding-Walk-II-CoffeeScript.Glitch.me/modules/grid.js
  2. https://Self-Avoiding-Walk-II-CoffeeScript.Glitch.me/modules/spot.js
  3. https://Self-Avoiding-Walk-II-CoffeeScript.Glitch.me/modules/step.js

In file ā€œgrid.jsā€ I have a class Grid that inside its method createGrid() 2 arrays are created:

  1. a 2d array grid[][] of Spot objects.
  2. and a 1d array path[] of also Spot objects.

Basically the singleton Grid class manages all instances of the Spot class.

And in turn, each Spot instance has 4 instances of class Step inside its 1d array options[].

Plus a temporary 1d array dirs[] which collects each Step that hasnā€™t been tried.

In short, I think that kind of hierarchy of classes is pretty organized and works very well. :factory_worker:

Thanks @GoToLoop. Iā€™ll look later into your code. And Iā€™m of same opinion as @Chrisir too. Thanks for the code examples.