Javascript classes, but more a design question

[vkbr]

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');

[svan]

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() {
}

[vkbr]

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

cheers

[svan]

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.

[Chrisir]

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.

[vkbr]

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

[GoToLoop]

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”:

Self Avoiding Walk Ii Coffeescript

In its subfolder “modules/” there are 3 JS files (plus 3 CoffeeScript files ):

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.

[vkbr]

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