|
Initially there was machine code (well, manual wiring of computers). Then there was assembly, and that worked. Then there were Fortran and Lisp and Algol, and somehow we still needed more languages and methodologies. GOTO was fine, until it wasn't. Then we had structured programming and things were better. Every language and methodology has had its pros and cons, and in general the trend has been towards "better" (by some dimension in a large, multi-dimensional space) languages and methods. Heavy classes were an improvement over what existed before them, not because they were heavy classes, but because what was before them was still (often) unstructured code. Light classes, moving things up a level so that, for instance, your graphical object doesn't draw itself, but instead knows enough to inform the drawing class how to draw it, is better in one particular regard: same object can be rendered in any system by updating the layer above it. So instead of updating 100 drawn objects, you now update 1 drawing object. That doesn't make heavy classes "wrong", they were fine at their time (probably more performant, and almost certainly an improvement in some ways over what existed before them). But light classes with some degree of abstraction is often better (too much is still a problem, damn you <person I inherited this project from>). Better, in this case: shorter code, fewer "moving" parts, easier to reason about, easier to manipulate. It is potentially less performant (depending on language and design choices), but that's not a guarantee. |