The right way to abstract

The right way to abstract

Start by implementing the problem in the concrete, not in the abstract. Don't try to guess what interfaces you will need. Discover them.

Only after implementing the problem in the concrete, go on to decoupling. Ask yourself: "What do I need to decouple to make it better, to allow it to deal with change as the data or business changes?".

Leaving the code in the concrete is also an option. Don't force abstractions when they are not necessary. Prefer duplication over the wrong abstraction because duplication is cheaper to deal with.


The Wrong Abstraction


Fix wrong abstractions

In the long run, it's better to fix wrong abstractions ASAP than to add more code and make everything more complicated.

Your goal is to remove the abstraction and conditionals, and to reduce each caller to only the code it needs. Here's how:

  1. Re-introduce duplication by inlining the abstracted code back into every caller
  2. Within each caller, use the parameters being passed to determine the subset of the inlined code that this caller executes
  3. Delete the parts that aren't needed for this particular caller

Once done, you can start anew, re-isolating duplication and re-extracting abstractions.


DRY is not a silver bullet

"Don’t repeat yourself" (DRY) is usually good advice, but you have to get the abstractions right. Otherwise they quickly become unmaintainable.

Here's how it usually plays out:

  1. You write a cool abstraction
  2. Time passes
  3. A new requirement appears for which that abstraction is almost perfect
  4. Programmer B gets tasked to implement it. They feel honor-bound to retain the abstraction, so they alter the code to take a parameter, and then add logic to conditionally do the right thing based on the value of the parameter

Loop these steps a couple of times and you quickly get an unmaintainable mess.



Wrong abstractions

If you find yourself passing parameters and adding conditional paths through shared code, the abstraction is wrong. It's no longer right for the codebase.

Wrong abstractions are no longer common abstractions; they are series of conditions mixed with vaguely related ideas. This makes them:

  • hard to understand,
  • easy to break, and
  • hard to modify to implement new features.


Deepstash helps you become inspired, wiser and productive, through bite-sized ideas from the best articles, books and videos out there.



Waiting around often means you’re not happy with any of the options, because they’re not right for who you are. So, when you find yourself stuck between possibilities, think about what you really want. 

For example, if you’re unsure about a career change, ask yourself what it is that appeals to you about your current position and the one you’re debating.



4 Steps That'll Help You Cut Through the BS and Make a Hard Decision Faster

Increase Productivity instead of working overtime ...

The more you work, the less effective and productive you become over both the short and long term .

It’s important for us not to overwork ourselves and get enough sleep to maintain a high level of productivity.



7 Things You Need To Stop Doing To Be More Productive, Backed By Science

1. The user is an idiot

The user is not an expert. My doc doesn't require me to know the difference between low-density and high-density lipoproteions. 

Don't assume user should know what kind of browser they use or what is the best flow to use the app. 

But yes, no matter how much you think of it, sometimes the user demand feature that seem pointless and he can have difficulties with functions that seem to be self-explanatory.


4 Mistakes I Made as a Programmer, but I Had To Become a CTO To See Them