Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is the single most important trick for factoring out shitty code. I cannot believe how many times reification collapsed complexity in our code base, or how not using it was the source of bugs.

If you have cascading ifs, there is a good chance there is a huge set of ifs for every place this type system is missing. Meaning, if you wanted to add another "case" to a feature, you are modifying cascading ifs in 5-10 places, not even just one.

Wrapping up all of this code into an implementation of an interface, that is "hooked in" at each contact point allows you to add a cohesive new use case by generating a new implementation of an interface, instead of "forgetting 2 places in the code" and causing massive bugs or issues because of it.

It of course, also makes it easier to test!



So to reify a type involves making an abstraction, which is odd because reify seems the inverse of making an abstraction...


The abstraction already existed in your mental model. You're reifying it by making it something the code can refer to/reflect on/pass around.


The only difficulty is naming the abstraction :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: