[HN Gopher] Abstractions, repetition and discovery (2015)
       ___________________________________________________________________
        
       Abstractions, repetition and discovery (2015)
        
       Author : alexzeitler
       Score  : 14 points
       Date   : 2024-01-31 22:23 UTC (3 days ago)
        
 (HTM) web link (beyond-code.com)
 (TXT) w3m dump (beyond-code.com)
        
       | whstl wrote:
       | Nice, simple, article.
       | 
       | IMO, the main issue with DRY and other simplistic guidelines like
       | the "rule of three" is that it lacks nuance regarding the "why"
       | and the "what" of abstractions.
       | 
       | Putting repeated code in a single code or breaking up classes or
       | methods into multiple due to the number of lines doesn't make for
       | a good abstraction, sometimes it's just an indirection that's not
       | really an abstraction.
       | 
       | I find that the concept of "abstraction levels" is a good
       | guideline as to where to separate the code. The example given
       | here is nice: have the business-related configuration in one
       | level with the rows, and rendering code itself (that knows
       | nothing about business part) in a deeper layer.
        
         | throwbadubadu wrote:
         | Yes, though further what to abstract when can only be mastered
         | with a lot of experience, or attempted. Attempts are not bad if
         | a dev/team doesn't lack the courage to reflect and undo them.
         | You see you abstraction becoming leaky? Stop right here, don't
         | do it! You see that abstraction has little value, hides intent,
         | is confusing everybody? Remove it again!!
         | 
         | Rarely done, instead people just cargo cult on, do it for
         | consistency even if they don't like it, or are too lazy or
         | afraid to tear something down again.
        
       ___________________________________________________________________
       (page generated 2024-02-03 23:01 UTC)