4

I've been looking at a javascript library for drawing graphs, Dygraph, source on github.

It has several enormous classes, such as here and here.

Personally, I don't think justifications for large classes are valid, since it goes against principles of OOP, such as the single responsibility rule. In this day and age, even phones have plenty of power, so except for the most fine-grained objects, it seems like bad practice. But even then, javascript often uses boxing anyway.

Now, I don't really know what javascript pre-compiling does besides shortening symbol names and removing whitespace, but perhaps it makes large classes even less significant in helping performance?

In short, my question is, if the above code was refactored to abide with the single responsibility rule, what sort of performance degradation might be expected? I know there's a lot of code there that could be analysed, but perhaps there are some rule-of-thumbs that code statistic gurus could apply? (I know I've seen lint engines that do these kinds of estimations)

Edit: my opinion is that it is bad practice and should be avoided unless critical to performance. I am just giving the authors the benefit of the doubt

Jodes
  • 839
  • 6
  • 12
  • related: [Are there any OO-principles that are practically applicable for Javascript?](http://programmers.stackexchange.com/questions/180585/are-there-any-oo-principles-that-are-practically-applicable-for-javascript) – gnat Aug 14 '16 at 14:46
  • Well, JS isn't an OO language to start, although it supports some features where you can sorta approximate OO. Did you try asking the framework authors? – Andy Aug 14 '16 at 14:59
  • 1
    Waiting for M$ to make c# run in edge so I can forget JS forever – Ewan Aug 14 '16 at 15:05
  • 1
    @AnJS is very much object-oriented. It is based on prototypical inheritance instead of classical inheritance (classes and interfaces). ES6 adds classes and interfaces, to some extent. – Brandon Aug 14 '16 at 15:27
  • It sounds like you're talking about minifying, not compiling, which is only likely to really help if network speeds is the issue – Dan Oberlam Aug 14 '16 at 23:59
  • @Ewan Are you referring to WebAssembly? That would make me love web development again. – Andy Aug 15 '16 at 00:27

1 Answers1

11

I completely disagree with the assumption that performance requirements in an environment with limited resources ever justified large classes. That simply isn't how it works.

Large classes don't run faster or slower. They're just larger. They are the result of thinking about coding in a different way than 'in the small'. Procedural programming crammed into modules can perform well or poorly just as small focused classes can perform well or poorly.

For a while there was a perception that performance wasn't something OOP was good at. This proved to be untrue as programmers trained in performance tuning learned to write real OOP code rather than treat classes as a fancy module.

Nowadays it's really just a stylistic choice. Big classes are bad not because the computer can't handle them. They're bad because I can't handle them. Well organized and focused code is easier to debug and refactor. But be warned, it is possible to make classes that are too small. It just doesn't happen very often.

Classes should be as small as possible, but no smaller.

But that's just for me. The computer, honestly, doesn't care.

candied_orange
  • 102,279
  • 24
  • 197
  • 315