4 ms·

Abstractions, repetition and discovery (2015)

• deleted 3y ago
  [deleted]
• whstl 3y ago
  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 3y ago
    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.
  • corytheboyd 3y ago
    > breaking up classes or methods into multiple due to the number of lines doesn't make for a good abstraction One of my biggest peeves right here. In particular, Ruby code seems to attract this. It’s usually more annoying to read the chain of 30 method calls than it is to read the 60 lines of sequential code.