The Case for Deconstruction - 16 Apr 2014
Often times we build and we build and we build to no end. One of the main tools programmers use is abstraction, and it is abused often. It’s easy to bandy the word abstraction about and make it seem like what you are doing is useful, but our goal as developers is problem solving. When you take abstraction too far, you end up on the opposite end of where you started. You went too far past your problem to another problem 10 steps past the current one.
Abstraction isn’t just about code reusability it’s about breaking down the problem you are solving into pieces you can easily examine and solve. We ought to deconstruct our problem into smaller parts and then abstract them into a form simple enough we can think and reason about without losing the essence or logic of the problem. Code reuse is a side affect of breaking a problem into pieces and figuring out that some pieces look the same. It should not be a goal from the beginning.
Design patterns are an example of this idea of abstracting too early while problem solving. Beginning programmers can easily misuse the idea of design patterns by assuming their problem fits into the abstraction of the pattern. They then hack around the design pattern to fit their problem, when instead they should deconstruct their problem first and see if the pieces fit into the design pattern. Design patterns should be used as a guide to deconstruct your problem.
When you come at a problem only from a ‘high level’ view point, you more often than not end up with lots of code hacked in place to fit into the structure you masterplanned at the beginning of the project. Deconstruction is the perfect way to start a project, and it’s a better way to use abstraction. Deconstruction is an idea that fits into almost any problem solving strategy, and is super useful for more than just programming.