4 changed files with 38 additions and 2 deletions
@ -0,0 +1,35 @@
|
||||
+++ |
||||
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. |
||||
|
||||
<!-- more --> |
||||
|
||||
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/integration-tests", next_chapter_title="Unit Tests Are Good, Integration Tests Are Gooder") }} |
||||
Loading…
Reference in new issue