I want to reinforce OOP skills while also learning frameworks and libraries.
I built a constructor function that build a new d3-based boxplot every time it is invoked (with new data, obviously).
Can someone take a look and let me know if I am using OOP correctly? I feel like I know the basic rules but don’t necessarily understand (read: remember) all the fundamentals so code can seem a little band-aided together.
Feedback would be useful - thanks!!
Code: https://github.com/SabahatPK/Data4Pakistan_Boxplots
Output: https://data4pakistan-boxplots.netlify.com/
I don’t know much about d3, but I do know OOP (or at least I think so 
)
Your code looks fine more or less, but really your use-case doesn’t really need or require any specific approach like OOP or functional, since all your doing is creating a graph from some inputs. Essentially using a class here is just to use a class, there isn’t any need to use a class to re-use code in any way or form. You could of done the same thing but just inside of a single function, and it would of ended up being more or less the same amount of code.
Some notes, both of which require es6, but it will make your code cleaner and more concise, which is especially useful for OOP, but not a requirement:
- You could use the es6
class syntax instead of the traditional prototype approach. (here’s the docs) They end up being basically the same, but the class approach is syntax sugar, and matches other language’s OOP syntax.
- You could use es6 arrow functions instead of relying on
let vis = this, and function().
1 Like
Thanks @bradtaniguchi !
Yeah, this might be overkill but my idea was to set up the framework in anticipation of adding more charts (i.e. seperate x-y planes).
But also, even though I just have 1 chart (or one set of axes), I am drawing several different boxplots. If I didn’t do this in an OOP way - and I wanted to show all boxplots on one set of axes - wouldn’t non-OOP way be cumbersome? (Each boxplot requires about 80 lines of code so if I was to put all of that in 1 file, 4 boxplots would require 320 lines of code).
Also- thanks for the ES6 suggestions!!
Without any knowledge of d3 its hard for me to point at any place you could optimize if you plan on adding other charts.
The main thing OOP would provide to you would probably be inheritance. One of the most common examples of inheritance is the shapes example. (here is an example in an SO post, so its kinda relevant) I bring this example up because its very similar to your use-case of d3 charts that could share different properties.
You point to the line considerations for each chart, but OOP isn’t the only pattern/approach to handle DRY code. You could use the factory pattern to build your chart instances, instead of trying to wrap each chart with helper code.
Finally, like most libraries d3 already has some concepts of OOP built in, so the last thing you want to do is fall into the inner platform effect where you create a bunch of classes to emulate what d3 already does. It would take a long while to “catch up” to d3’s complexity, but always be aware of it
1 Like