1.6 KiB
+++ title = "Things I Learnt The Hard Way - Thinking Data Flow Beats Patterns" date = 2019-06-26
[taxonomies] tags = ["en-au", "books", "things i learnt", "data flow", "design patterns"] +++
When you're trying to find a solution to your problem, think on the way the data will flow through your code.
Instead of focusing on design patterns, a better way is to think the way the data will flow -- and be transformed -- on your code.
For example, the user will input a number. You'll get this number and find the respective record on the database. This is a transformation -- no, it's not "I'll get the number and receive a complete different thing based upon it", you're actually transforming the number into a record, using the database as a transformation.
(Yes, I know, it's not that clear at the first glance, but you have to think that they are the same data with different representations.)
Most of the time I did that, I managed to come with more clear design for my applications. I didn't even think about how many functions/classes it would be needed to do these kind of transformations, that was something I came up after I could see the data flow.
In a way, this way of thinking gets things more clear 'cause you have a list of steps of transformations you need to do, so you can write them one after another, which prevents a lot of bad code in the future.
{{ chapters(prev_chapter_link="/books/things-i-learnt/patterns-not-solutions", prev_chapter_title="Design Patters Are Used to Name Solution, Not Find Them", next_chapter_link="/books/things-i-learnt/magical-number-seven", next_chapter_title="The Magic Number Seven, Plus Or Minus Two") }}